diff --git a/.openpublishing.publish.config.json b/.openpublishing.publish.config.json
index 469538cd59..469c22cfdc 100644
--- a/.openpublishing.publish.config.json
+++ b/.openpublishing.publish.config.json
@@ -52,7 +52,7 @@
"Conceptual": "Content"
}
},
- {
+ {
"docset_name": "mdop",
"build_output_subfolder": "mdop",
"locale": "en-us",
diff --git a/devices/surface-hub/TOC.md b/devices/surface-hub/TOC.md
index 65f42da6b5..57c833cdd0 100644
--- a/devices/surface-hub/TOC.md
+++ b/devices/surface-hub/TOC.md
@@ -20,6 +20,7 @@
#### [Accessibility](accessibility-surface-hub.md)
#### [Change the Surface Hub device account](change-surface-hub-device-account.md)
#### [Device reset](device-reset-suface-hub.md)
+#### [End a Surface Hub meeting with I'm Done](i-am-done-finishing-your-surface-hub-meeting.md)
#### [Install apps on your Surface Hub](install-apps-on-surface-hub.md)
#### [Manage settings with a local admin account](manage-settings-with-local-admin-account-surface-hub.md)
#### [Manage settings with an MDM provider](manage-settings-with-mdm-for-surface-hub.md)
diff --git a/devices/surface-hub/i-am-done-finishing-your-surface-hub-meeting.md b/devices/surface-hub/i-am-done-finishing-your-surface-hub-meeting.md
new file mode 100644
index 0000000000..137667385b
--- /dev/null
+++ b/devices/surface-hub/i-am-done-finishing-your-surface-hub-meeting.md
@@ -0,0 +1,87 @@
+---
+title: I am done - ending a Surface Hub meeting
+description: To end a Surface Hub meeting, tap I am Done. Surface Hub cleans up the application state, operating system state, and the user interface so that Surface Hub is ready for the next meeting.
+keywords: I am Done, end Surface Hub meeting, finish Surface Hub meeting, clean up Surface Hub meeting
+author: TrudyHa
+---
+
+# End a Surface Hub meeting with I'm Done
+Surface Hub is a collaboration device designed to be used simultaneously and sequentially by multiple people. At the end of a Surface Hub meeting, one of the attendees can tap or click **I'm Done** to end the meeting. Tapping **I'm Done** tells Surface Hub to clean up info from the current meeting, so that it will be ready for the next meeting. When a meeting attendee taps **I'm Done**, Surface Hub cleans up, or resets, these states.
+- Applications
+- Operating system
+- User interface
+
+This topic explains what **I'm Done** resets for each of these states.
+
+## Applications
+When you start apps on Surface Hub, they are stored in memory and data is stored at the application level. Data is available to all users during that session (or meeting) until date is removed or overwritten. When **I'm done** is selected, Surface Hub application state is cleared out by closing applications, deleting browser history, resetting applications, and removing Skype logs.
+
+### Close applications
+Surface Hub closes all visible windows, including Win32 and Universal Windows Platform (UWP) applications. The application close stage uses the multitasking view to query the visible windows. Win32 windows that do not close within a certain timeframe are closed using **TerminateProcess**.
+
+### Delete browser history
+Surface Hub uses Delete Browser History (DBH) in Edge to clear Edge history and cached data. This is similar to how a user can clear out their browser history manually, but **I'm Done** also ensures that application states are cleared and data is removed before the next session, or meeting, starts.
+
+### Reset applications
+**I'm Done** resets the state of each application that is installed on the Surface Hub. Resetting an application clears all background tasks, application data, notifications, and user consent dialogs. Applications are returned to their first-run state for the next people that use Surface Hub.
+
+### Remove Skype logs
+Skype does not store personally-identifiable information on Surface Hub. Information is stored in the Skype service to meet existing Skype for Business guidance. Local Skype logging information is the only data removed when **I'm Done** is selected. This includes Unified Communications Client Platform (UCCP) logs and media logs.
+
+## Operating System
+The operating system hosts a variety of information about the state of the sessions that needs to be cleared after each Surface Hub meeting.
+### File System
+Meeting attendees have access to a limited set of directories on the Surface Hub. When **I'm Done** is selected, Surface Hub clears these directories:
+- Music
+- Videos
+- Documents
+- Pictures
+- Downloads
+
+Surface Hub also clears these directories, since many applications often write to them:
+- Desktop
+- Favorites
+- Recent
+- Public Documents
+- Public Music
+- Public Videos
+- Public Downloads
+
+### Credentials
+User credentials that are stored in **TokenBroker**, **PasswordVault**, or **Credential Manager** are cleared when you tap I’m done.
+
+## User interface
+User interface (UI) settings are returned to their default values when **I'm Done** is selected.
+
+### UI items
+- Reset Quick Actions to default state
+- Clear Toast notifications
+- Reset volume levels
+- Reset Cortana relaunch count
+- Reset sidebar width
+- Reset tablet mode layout
+
+### Accessibility
+Accessibility features and apps are returned to default settings when **I'm Done** is selected.
+- Filter keys
+- High contrast
+- Stickey keys
+- Toggle keys
+- Mouse keys
+- Magnifier
+- Narrator
+
+### Clipboard
+The clipboard is cleared to remove data that was copied to the clipboard during the session.
+
+## Frequently asked questions
+**What happens if I forget to tap I'm Done at the end of a meeting, and someone else uses the Surface Hub later?**
+When you don't tap **I"m Done** at the end of your meeting, Surface Hub enters a Resume state. This is similar to leaving content on a whiteboard in a meeting room, and forgetting to erase the whiteboard. When you return to the meeting room, that content will still be on the whiteboard unless someone erarses it. With Surface Hub, meeting content is still available if an attendee doesn't tap **I'm Done**. However, Surface Hub removes all meeting data during daily maintenance. Any meeting that wasn't ended with **I'm Done** will be cleaned up during maintenance.
+
+**Are documents recoverable?**
+Removing files from the hard drive when **I'm Done** is selected is just like any other file deletion from a hard disk drive. 3rd-party software might be able to recover data from the hard disk drive, but file recovery is not a supported feature on Surface Hub.
+
+**Do the clean-up actions from I'm Done comply with the US Department of Defense clearing and sanitizing standard: DoD 5220.22-M?**
+No. Currently, the clean-up actions from **I'm Done** do not comply with this standard.
+
+
\ No newline at end of file
diff --git a/devices/surface/TOC.md b/devices/surface/TOC.md
index 663ec20dc4..f7e3191aa7 100644
--- a/devices/surface/TOC.md
+++ b/devices/surface/TOC.md
@@ -6,6 +6,7 @@
## [Ethernet adapters and Surface deployment](ethernet-adapters-and-surface-device-deployment.md)
## [Manage Surface Dock firmware updates](manage-surface-dock-firmware-updates.md)
## [Manage Surface driver and firmware updates](manage-surface-pro-3-firmware-updates.md)
+## [Manage Surface UEFI settings](manage-surface-uefi-settings.md)
## [Surface Data Eraser](microsoft-surface-data-eraser.md)
## [Surface Deployment Accelerator](microsoft-surface-deployment-accelerator.md)
### [Step by step: Surface Deployment Accelerator](step-by-step-surface-deployment-accelerator.md)
diff --git a/devices/surface/advanced-uefi-security-features-for-surface.md b/devices/surface/advanced-uefi-security-features-for-surface.md
index e274220bee..9eb6cc703e 100644
--- a/devices/surface/advanced-uefi-security-features-for-surface.md
+++ b/devices/surface/advanced-uefi-security-features-for-surface.md
@@ -6,7 +6,7 @@ keywords: ["Surface, Surface Pro 3, security, features, configure, hardware, dev
ms.prod: W10
ms.mktglfcycl: manage
ms.sitesec: library
-author: heatherpoulsen
+author: miladCA
---
# Advanced UEFI security features for Surface
@@ -24,9 +24,7 @@ Before you can configure the advanced security features of your Surface device,
## Manually configure additional security settings
-**Note** To enter firmware setup on a Surface device, begin with the device powered off, press and hold the **Volume Up** button, then press and release the **Power** button, then release the **Volume Up** button after the device has begun to boot.
-
-
+>**Note:** To enter firmware setup on a Surface device, begin with the device powered off, press and hold the **Volume Up** button, then press and release the **Power** button, then release the **Volume Up** button after the device has begun to boot.
After the v3.11.760.0 UEFI update is installed on a Surface device, an additional UEFI menu named **Advanced Device Security** becomes available. If you click this menu, the following options are displayed:
@@ -57,9 +55,8 @@ As an IT professional with administrative privileges, you can automate the confi
**Sample scripts**
-**Note** The UEFI password used in the sample scripts below is presented in clear text. We strongly recommend saving the scripts in a protected location and running them in a controlled environment.
+>**Note**: The UEFI password used in the sample scripts below is presented in clear text. We strongly recommend saving the scripts in a protected location and running them in a controlled environment.
-
Show all configurable options:
diff --git a/devices/surface/customize-the-oobe-for-surface-deployments.md b/devices/surface/customize-the-oobe-for-surface-deployments.md
index 73466d6d64..1985b76438 100644
--- a/devices/surface/customize-the-oobe-for-surface-deployments.md
+++ b/devices/surface/customize-the-oobe-for-surface-deployments.md
@@ -6,31 +6,26 @@ keywords: ["deploy, customize, automate, deployment, network, Pen, pair, boot"]
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
-author: heatherpoulsen
+author: jobotto
---
# Customize the OOBE for Surface deployments
-This article will walk you through the process of customizing the Surface out-of-box experience for end users in your organization.
+This article walks you through the process of customizing the Surface out-of-box experience for end users in your organization.
It is common practice in a Windows deployment to customize the user experience for the first startup of deployed computers — the out-of-box experience, or OOBE.
-**Note**
-OOBE is also often used to describe the phase, or configuration pass, of Windows setup during which the user experience is displayed. For more information about the OOBE phase of setup, see [How Configuration Passes Work](http://msdn.microsoft.com/library/windows/hardware/dn898581(v=vs.85).aspx).
-
-
+>**Note:** OOBE is also often used to describe the phase, or configuration pass, of Windows setup during which the user experience is displayed. For more information about the OOBE phase of setup, see [How Configuration Passes Work](http://msdn.microsoft.com/library/windows/hardware/dn898581.aspx).
In some scenarios, you may want to provide complete automation to ensure that at the end of a deployment, computers are ready for use without any interaction from the user. In other scenarios, you may want to leave key elements of the experience for users to perform necessary actions or select between important choices. For administrators deploying to Surface devices, each of these scenarios presents a unique challenge to overcome.
This article provides a summary of the scenarios where a deployment might require additional steps. It also provides the required information to ensure that the desired experience is achieved on any newly deployed Surface device. This article is intended for administrators who are familiar with the deployment process, as well as concepts such as answer files and [reference images](http://go.microsoft.com/fwlink/p/?LinkID=618042).
-**Note**
-Although the OOBE phase of setup is still run during a deployment with an automated deployment solution such as the [Microsoft Deployment Toolkit (MDT)](http://go.microsoft.com/fwlink/p/?LinkId=618117) or System Center Configuration Manager Operating System Deployment (OSD), it is automated by the settings supplied in the Deployment Wizard and task sequence. For more information see:
-
-- [Deploy Windows 10 with the Microsoft Deployment Toolkit](http://technet.microsoft.com/en-us/itpro/windows/deploy/deploy-windows-10-with-the-microsoft-deployment-toolkit)
-
-- [Deploy Windows 10 with System Center 2012 R2 Configuration Manager](http://technet.microsoft.com/en-us/itpro/windows/deploy/deploy-windows-10-with-system-center-2012-r2-configuration-manager)
+>**Note:** Although the OOBE phase of setup is still run during a deployment with an automated deployment solution such as the [Microsoft Deployment Toolkit (MDT)](http://go.microsoft.com/fwlink/p/?LinkId=618117) or System Center Configuration Manager Operating System Deployment (OSD), it is automated by the settings supplied in the Deployment Wizard and task sequence. For more information see:
+- [Deploy Windows 10 with the Microsoft Deployment Toolkit](http://technet.microsoft.com/en-us/itpro/windows/deploy/deploy-windows-10-with-the-microsoft-deployment-toolkit)
+
+- [Deploy Windows 10 with System Center 2012 R2 Configuration Manager](http://technet.microsoft.com/en-us/itpro/windows/deploy/deploy-windows-10-with-system-center-2012-r2-configuration-manager)
@@ -53,8 +48,7 @@ To provide the factory Surface Pen pairing experience in OOBE, you must copy fou
- %windir%\\system32\\oobe\\info\\default\\1033\\PenError\_en-US.png
- %windir%\\system32\\oobe\\info\\default\\1033\\PenSuccess\_en-US.png
-**Note**
-You should copy the files from a factory image for the same model Surface device that you intend to deploy to. For example, you should use the files from a Surface Pro 3 to deploy to Surface Pro 3, and the files from Surface Book to deploy Surface Book, but you should not use the files from a Surface Pro 3 to deploy Surface Book or Surface Pro 4.
+>**Note:** You should copy the files from a factory image for the same model Surface device that you intend to deploy to. For example, you should use the files from a Surface Pro 3 to deploy to Surface Pro 3, and the files from Surface Book to deploy Surface Book, but you should not use the files from a Surface Pro 3 to deploy Surface Book or Surface Pro 4.
diff --git a/devices/surface/deploy-the-latest-firmware-and-drivers-for-surface-devices.md b/devices/surface/deploy-the-latest-firmware-and-drivers-for-surface-devices.md
index d5de7a0bb0..61d56fa1b9 100644
--- a/devices/surface/deploy-the-latest-firmware-and-drivers-for-surface-devices.md
+++ b/devices/surface/deploy-the-latest-firmware-and-drivers-for-surface-devices.md
@@ -6,7 +6,7 @@ keywords: ["update Surface, newest, latest, download, firmware, driver, tablet,
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
-author: heatherpoulsen
+author: jobotto
---
# Download the latest firmware and drivers for Surface devices
@@ -26,14 +26,12 @@ Driver and firmware updates for Surface devices are released in one of two ways:
Installation files for administrative tools, drivers for accessories, and updates for Windows are also available for some devices and are detailed here in this article.
-**Note**
-To simplify the process of locating drivers for your device, downloads for Surface devices have been reorganized to separate pages for each model. Bookmark the Microsoft Download Center page for your device from the links provided on this page. Many of the filenames contain a placeholder denoted with *xxxxxx*, which identifies the current version number or date of the file.
-
+>**Note:** To simplify the process of locating drivers for your device, downloads for Surface devices have been reorganized to separate pages for each model. Bookmark the Microsoft Download Center page for your device from the links provided on this page. Many of the filenames contain a placeholder denoted with *xxxxxx*, which identifies the current version number or date of the file.
Recent additions to the downloads for Surface devices provide you with options to install Windows 10 on your Surface devices and update LTE devices with the latest Windows 10 drivers and firmware.
-**Note** A battery charge of 40% or greater is required before you install firmware to a Surface device. See [Microsoft Support article KB2909710](http://go.microsoft.com/fwlink/p/?LinkId=618106) for more information.
+>**Note:** A battery charge of 40% or greater is required before you install firmware to a Surface device. See [Microsoft Support article KB2909710](http://go.microsoft.com/fwlink/p/?LinkId=618106) for more information.
diff --git a/devices/surface/enable-peap-eap-fast-and-cisco-leap-on-surface-devices.md b/devices/surface/enable-peap-eap-fast-and-cisco-leap-on-surface-devices.md
index 6a6c9f753c..df0f2600d3 100644
--- a/devices/surface/enable-peap-eap-fast-and-cisco-leap-on-surface-devices.md
+++ b/devices/surface/enable-peap-eap-fast-and-cisco-leap-on-surface-devices.md
@@ -6,7 +6,7 @@ keywords: ["network", "wireless", "device", "deploy", "authenticaion", "protocol
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
-author: heatherpoulsen
+author: miladCA
---
# Enable PEAP, EAP-FAST, and Cisco LEAP on Surface devices
diff --git a/devices/surface/ethernet-adapters-and-surface-device-deployment.md b/devices/surface/ethernet-adapters-and-surface-device-deployment.md
index 14c36f3fdb..fb580c032f 100644
--- a/devices/surface/ethernet-adapters-and-surface-device-deployment.md
+++ b/devices/surface/ethernet-adapters-and-surface-device-deployment.md
@@ -6,7 +6,7 @@ keywords: ["ethernet, deploy, removable, network, connectivity, boot, firmware,
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
-author: heatherpoulsen
+author: jobotto
---
# Ethernet adapters and Surface deployment
@@ -53,7 +53,7 @@ To boot a Surface device from an alternative boot device, follow these steps:
3. Press and release the **Power** button.
4. After the system begins to boot from the USB stick or Ethernet adapter, release the **Volume Down** button.
-**Note** In addition to an Ethernet adapter, a keyboard must also be connected to the Surface device to enter the preinstallation environment and navigate the deployment wizard.
+>**Note:** In addition to an Ethernet adapter, a keyboard must also be connected to the Surface device to enter the preinstallation environment and navigate the deployment wizard.
diff --git a/devices/surface/images/manage-surface-uefi-fig2.png b/devices/surface/images/manage-surface-uefi-fig2.png
new file mode 100644
index 0000000000..6d8e4b41c8
Binary files /dev/null and b/devices/surface/images/manage-surface-uefi-fig2.png differ
diff --git a/devices/surface/images/manage-surface-uefi-fig3.png b/devices/surface/images/manage-surface-uefi-fig3.png
new file mode 100644
index 0000000000..4ae63c2a49
Binary files /dev/null and b/devices/surface/images/manage-surface-uefi-fig3.png differ
diff --git a/devices/surface/images/manage-surface-uefi-fig4.png b/devices/surface/images/manage-surface-uefi-fig4.png
new file mode 100644
index 0000000000..67866fcbf0
Binary files /dev/null and b/devices/surface/images/manage-surface-uefi-fig4.png differ
diff --git a/devices/surface/images/manage-surface-uefi-fig5.png b/devices/surface/images/manage-surface-uefi-fig5.png
new file mode 100644
index 0000000000..eae3212f76
Binary files /dev/null and b/devices/surface/images/manage-surface-uefi-fig5.png differ
diff --git a/devices/surface/images/manage-surface-uefi-fig6.png b/devices/surface/images/manage-surface-uefi-fig6.png
new file mode 100644
index 0000000000..a06c845a9c
Binary files /dev/null and b/devices/surface/images/manage-surface-uefi-fig6.png differ
diff --git a/devices/surface/images/manage-surface-uefi-fig7.png b/devices/surface/images/manage-surface-uefi-fig7.png
new file mode 100644
index 0000000000..9af6d1beed
Binary files /dev/null and b/devices/surface/images/manage-surface-uefi-fig7.png differ
diff --git a/devices/surface/images/manage-surface-uefi-fig8.png b/devices/surface/images/manage-surface-uefi-fig8.png
new file mode 100644
index 0000000000..d8c078cf59
Binary files /dev/null and b/devices/surface/images/manage-surface-uefi-fig8.png differ
diff --git a/devices/surface/images/manage-surface-uefi-figure-1.png b/devices/surface/images/manage-surface-uefi-figure-1.png
new file mode 100644
index 0000000000..b87279bdd5
Binary files /dev/null and b/devices/surface/images/manage-surface-uefi-figure-1.png differ
diff --git a/devices/surface/index.md b/devices/surface/index.md
index fb08705db4..2a2598a5cd 100644
--- a/devices/surface/index.md
+++ b/devices/surface/index.md
@@ -15,6 +15,9 @@ author: heatherpoulsen
This library provides guidance to help you deploy Windows on Surface devices, keep those devices up to date, and easily manage and support Surface devices in your organization.
+
+For more information on planning for, deploying, and managing Surface devices in your organization, see the [Surface TechCenter](https://technet.microsoft.com/en-us/windows/surface).
+
## In this section
@@ -32,15 +35,15 @@ This library provides guidance to help you deploy Windows on Surface devices, ke
[Advanced UEFI security features for Surface](advanced-uefi-security-features-for-surface.md) |
-This article describes how to install and configure the v3.11.760.0 UEFI update to enable additional security options for Surface Pro 3 devices. |
+Find out how to install and configure the v3.11.760.0 UEFI update to enable additional security options for Surface Pro 3 devices. |
[Customize the OOBE for Surface deployments](customize-the-oobe-for-surface-deployments.md) |
-This article will walk you through the process of customizing the Surface out-of-box experience for end users in your organization. |
+Walk through the process of customizing the Surface out-of-box experience for end users in your organization. |
[Download the latest firmware and drivers for Surface devices](deploy-the-latest-firmware-and-drivers-for-surface-devices.md) |
-This article provides a list of the available downloads for Surface devices and links to download the drivers and firmware for your device. |
+Get a list of the available downloads for Surface devices and links to download the drivers and firmware for your device. |
[Enable PEAP, EAP-FAST, and Cisco LEAP on Surface devices](enable-peap-eap-fast-and-cisco-leap-on-surface-devices.md) |
@@ -48,7 +51,7 @@ This library provides guidance to help you deploy Windows on Surface devices, ke
[Ethernet adapters and Surface deployment](ethernet-adapters-and-surface-device-deployment.md) |
-This article provides guidance and answers to help you perform a network deployment to Surface devices. |
+Get guidance and answers to help you perform a network deployment to Surface devices. |
[Manage Surface Dock firmware updates](manage-surface-dock-firmware-updates.md) |
@@ -56,23 +59,27 @@ This library provides guidance to help you deploy Windows on Surface devices, ke
[Manage Surface driver and firmware updates](manage-surface-pro-3-firmware-updates.md) |
-This article describes the available options to manage firmware and driver updates for Surface devices. |
+Explore the available options to manage firmware and driver updates for Surface devices. |
+[Manage Surface UEFI settings](manage-surface-uefi-settings.md) |
+Use Surface UEFI settings to enable or disable devices, configure security settings, and adjust Surface device boot settings. |
+
+
[Surface Data Eraser](microsoft-surface-data-eraser.md) |
Find out how the Microsoft Surface Data Eraser tool can help you securely wipe data from your Surface devices. |
-
-[Surface Deployment Accelerator](microsoft-surface-deployment-accelerator.md) |
-Microsoft Surface Deployment Accelerator provides a quick and simple deployment mechanism for organizations to reimage Surface devices. |
-
+[Surface Deployment Accelerator](microsoft-surface-deployment-accelerator.md) |
+See how Microsoft Surface Deployment Accelerator provides a quick and simple deployment mechanism for organizations to reimage Surface devices. |
+
+
[Surface Diagnostic Toolkit](surface-diagnostic-toolkit.md) |
Find out how you can use the Microsoft Surface Diagnostic Toolkit to test the hardware of your Surface device. |
-
+
[Surface Dock Updater](surface-dock-updater.md) |
-This article provides a detailed walkthrough of Microsoft Surface Dock Updater. |
+Get a detailed walkthrough of Microsoft Surface Dock Updater. |
diff --git a/devices/surface/manage-surface-dock-firmware-updates.md b/devices/surface/manage-surface-dock-firmware-updates.md
index be1d2e63f1..758f8027ea 100644
--- a/devices/surface/manage-surface-dock-firmware-updates.md
+++ b/devices/surface/manage-surface-dock-firmware-updates.md
@@ -5,7 +5,7 @@ ms.assetid: 86DFC0C0-C842-4CD1-A2D7-4425471FFE3F
ms.prod: W10
ms.mktglfcycl: manage
ms.sitesec: library
-author: heatherpoulsen
+author: jobotto
---
# Manage Surface Dock firmware updates
@@ -13,16 +13,13 @@ author: heatherpoulsen
Read about the different methods you can use to manage the process of Surface Dock firmware updates.
-The Surface Dock provides external connectivity to Surface devices through a single cable connection that includes Power, Ethernet, Audio, USB 3.0, and DisplayPort. The numerous connections provided by the Surface Dock are enabled by a smart chipset within the Surface Dock device. Like a Surface device’s chipset, the chipset that is built into the Surface Dock is controlled by firmware.
+The Surface Dock provides external connectivity to Surface devices through a single cable connection that includes Power, Ethernet, Audio, USB 3.0, and DisplayPort. The numerous connections provided by the Surface Dock are enabled by a smart chipset within the Surface Dock device. Like a Surface device’s chipset, the chipset that is built into the Surface Dock is controlled by firmware. For more information about the Surface Dock, see the [Surface Dock demonstration](https://technet.microsoft.com/en-us/mt697552) video.
Like the firmware for Surface devices, firmware for Surface Dock is also contained within a downloaded driver that is visible in Device Manager. This driver stages the firmware update files on the Surface device. When a Surface Dock is connected and the driver is loaded, the newer version of the firmware staged by the driver is detected and firmware files are copied to the Surface Dock. The Surface Dock then begins a two-phase process to apply the firmware internally. Each phase requires the Surface Dock to be disconnected from the Surface device before the firmware is applied. The driver copies the firmware into the dock, but only applies it when the user disconnects the Surface device from the Surface Dock. This ensures that there are no disruptions because the firmware is only applied when the user leaves their desk with the device.
-**Note**
-You can learn more about the firmware update process for Surface devices and how firmware is updated through driver installation at the following links:
-
-- [How to manage and update your drivers and firmware for Surface](http://go.microsoft.com/fwlink/p/?LinkId=785353) from Microsoft Mechanics
-
-- [Windows Update Makes Surface Better](http://go.microsoft.com/fwlink/p/?LinkId=785354)on the Microsoft Devices Blog
+>**Note:** You can learn more about the firmware update process for Surface devices and how firmware is updated through driver installation at the following links:
+- [How to manage and update Surface drivers and firmware](https://technet.microsoft.com/en-us/mt697551) from Microsoft Mechanics
+- [Windows Update Makes Surface Better](http://go.microsoft.com/fwlink/p/?LinkId=785354) on the Microsoft Devices Blog
@@ -70,8 +67,7 @@ There are three methods you can use to update the firmware of the Surface Dock:
Windows Update is the method that most users will use. The drivers for the Surface Dock are downloaded automatically from Windows Update and the dock update process is initiated without additional user interaction. The two-phase dock update process described earlier occurs in the background as the user connects and disconnects the Surface Dock during normal use.
-**Note**
-The driver version that is displayed in Device Manager may be different from the firmware version that the Surface Dock is using.
+>**Note:** The driver version that is displayed in Device Manager may be different from the firmware version that the Surface Dock is using.
@@ -82,10 +78,8 @@ This method is used mostly in environments where Surface device drivers and firm
For more information about how to deploy MSI packages see [Create and deploy an application with System Center Configuration Manager](http://go.microsoft.com/fwlink/p/?LinkId=785355).
-**Note**
-When drivers are installed through Windows Update or the MSI package, registry keys are added that indicate the version of firmware installed on the Surface Dock and contained within the Surface Dock driver. These registry keys can be found in:
-
-**HLKM\\Software\\Microsoft\\Windows NT\\CurrentVersion\\WUDF\\Services\\SurfaceDockFwUpdate\\Parameters**
+>**Note:** When drivers are installed through Windows Update or the MSI package, registry keys are added that indicate the version of firmware installed on the Surface Dock and contained within the Surface Dock driver. These registry keys can be found in:
+ **HLKM\\Software\\Microsoft\\Windows NT\\CurrentVersion\\WUDF\\Services\\SurfaceDockFwUpdate\\Parameters**
Firmware status is displayed for both the main chipset (displayed as **Component10**) and the DisplayPort chipset (displayed as **Component20**). For each chipset there are four keys, where *xx* is **10** or **20** corresponding to each chipset:
@@ -97,7 +91,7 @@ Firmware status is displayed for both the main chipset (displayed as **Component
- **Component*xx*FirmwareUpdateStatusRejectReason** – This key changes as the firmware update is processed. It should result in 0 after the successful installation of Surface Dock firmware.
-These registry keys are not present unless you have installed updated Surface Dock drivers through Windows Update or MSI deployment.
+>**Note:** These registry keys are not present unless you have installed updated Surface Dock drivers through Windows Update or MSI deployment.
diff --git a/devices/surface/manage-surface-pro-3-firmware-updates.md b/devices/surface/manage-surface-pro-3-firmware-updates.md
index 7a8b380b8b..fac455f9ac 100644
--- a/devices/surface/manage-surface-pro-3-firmware-updates.md
+++ b/devices/surface/manage-surface-pro-3-firmware-updates.md
@@ -6,7 +6,7 @@ keywords: ["Surface, Surface Pro 3, firmware, update, device, manage, deploy, dr
ms.prod: W10
ms.mktglfcycl: manage
ms.sitesec: library
-author: heatherpoulsen
+author: jobotto
---
# Manage Surface driver and firmware updates
diff --git a/devices/surface/manage-surface-uefi-settings.md b/devices/surface/manage-surface-uefi-settings.md
new file mode 100644
index 0000000000..44428903c1
--- /dev/null
+++ b/devices/surface/manage-surface-uefi-settings.md
@@ -0,0 +1,138 @@
+---
+title: Manage Surface UEFI settings (Surface)
+description: Use Surface UEFI settings to enable or disable devices or components, configure security settings, and adjust Surface device boot settings.
+keywords: firmware, security, features, configure, hardware
+ms.prod: w10
+ms.mktglfcycl: manage
+ms.sitesec: library
+ms.pagetype: devices, surface
+author: miladCA
+---
+
+#Manage Surface UEFI settings
+
+Current and future generations of Surface devices, including Surface Pro 4 and Surface Book, use a unique UEFI firmware engineered by Microsoft specifically for these devices. This firmware allows for significantly greater control of the device’s operation over firmware versions in earlier generation Surface devices, including the support for touch, mouse, and keyboard operation. By using the Surface UEFI settings you can easily enable or disable internal devices or components, configure security to protect UEFI settings from being changed, and adjust the Surface device boot settings.
+
+>**Note:** Surface Pro 3, Surface 3, Surface Pro 2, Surface 2, Surface Pro, and Surface do not use the Surface UEFI and instead use firmware provided by third-party manufacturers, such as AMI.
+
+You can enter the Surface UEFI settings on your Surface device by pressing the **Volume Up** button and the **Power** button simultaneously. Hold the **Volume Up** button until the Surface logo is displayed, which indicates that the device has begun to boot.
+
+##PC information
+
+On the **PC information** page, detailed information about your Surface device is provided:
+
+- **Model** – Your Surface device’s model will be displayed here, such as Surface Book or Surface Pro 4. The exact configuration of your device is not shown, (such as processor, disk size, or memory size).
+- **UUID** – This Universally Unique Identification number is specific to your device and is used to identify the device during deployment or management.
+
+- **Serial Number** – This number is used to identify this specific Surface device for asset tagging and support scenarios.
+- **Asset Tag** – The asset tag is assigned to the Surface device with the [Asset Tag Tool](https://www.microsoft.com/en-us/download/details.aspx?id=44076).
+
+You will also find detailed information about the firmware of your Surface device. Surface devices have several internal components that each run different versions of firmware. The firmware version of each of the following devices is displayed on the **PC information** page (as shown in Figure 1):
+
+- System UEFI
+
+- SAM Controller
+
+- Intel Management Engine
+
+- System Embedded Controller
+
+- Touch Firmware
+
+*Figure 1. System information and firmware version information*
+
+
+
+You can find up-to-date information about the latest firmware version for your Surface device in the [Surface Update History](https://www.microsoft.com/surface/en-us/support/install-update-activate/surface-update-history) for your device.
+
+##Security
+
+On the **Security** page of Surface UEFI settings, you can set a password to protect UEFI settings. This password must be entered when you boot the Surface device to UEFI. The password can contain the following characters (as shown in Figure 2):
+
+- Uppercase letters: A-Z
+
+- Lowercase letters: a-z
+
+- Numbers: 1-0
+
+- Special characters: !@#$%^&*()?<>{}[]-_=+|.,;:’`”
+
+The password must be at least 6 characters and is case sensitive.
+
+*Figure 2. Add a password to protect Surface UEFI settings*
+
+
+
+On the **Security** page you can also change the configuration of Secure Boot on your Surface device. Secure Boot technology prevents unauthorized boot code from booting on your Surface device, which protects against bootkit and rootkit-type malware infections. You can disable Secure Boot to allow your Surface device to boot third-party operating systems or bootable media. You can also configure Secure Boot to work with third-party certificates, as shown in Figure 3. Read more about [Secure Boot](https://msdn.microsoft.com/windows/hardware/commercialize/manufacture/desktop/secure-boot-overview) in the TechNet Library.
+
+*Figure 3. Configure Secure Boot*
+
+
+
+You can also enable or disable the Trusted Platform Module (TPM) device on the **Security** page, as shown in Figure 4. The TPM is used to authenticate encryption for your device’s data with BitLocker. Read more about [BitLocker](https://technet.microsoft.com/en-us/itpro/windows/keep-secure/bitlocker-overview) in the TechNet Library.
+
+*Figure 4. Configure Surface UEFI security settings*
+
+
+
+##Devices
+
+On the **Devices** page you can enable or disable specific devices and components of your Surface device. Devices that you can enable or disable on this page include:
+
+- Docking and USB Ports
+
+- MicroSD or SD Card Slot
+
+- Rear Camera
+
+- Front Camera
+
+- Infrared (IR) Camera
+
+- Wi-Fi and Bluetooth
+
+- Onboard Audio (Speakers and Microphone)
+
+Each device is listed with a slider button that you can move to **On** (enabled) or **Off** (disabled) position, as shown in Figure 5.
+
+*Figure 5. Enable and disable specific devices*
+
+
+
+##Boot configuration
+
+On the **Boot Configuration** page, you can change the order of your boot devices and/or enable or disable boot of the following devices:
+
+- Windows Boot Manager
+
+- USB Storage
+
+- PXE Network
+
+- Internal Storage
+
+You can boot from a specific device immediately, or you can swipe left on that device’s entry in the list using the touchscreen. You can also boot immediately to a USB device or USB Ethernet adapter when the Surface device is powered off by pressing the **Volume Down** button and the **Power** button simultaneously.
+
+For the specified boot order to take effect, you must set the **Enable Alternate Boot Sequence** option to **On**, as shown in Figure 6.
+
+*Figure 6. Configure the boot order for your Surface device*
+
+
+
+You can also turn on and off IPv6 support for PXE with the **Enable IPv6 for PXE Network Boot** option, for example when performing a Windows deployment using PXE where the PXE server is configured for IPv4 only.
+
+##About
+
+The **About** page displays regulatory information, such as compliance with FCC rules, as shown in Figure 7.
+
+*Figure 7. Regulatory information is displayed on the About page*
+
+
+
+##Exit
+
+Use the **Restart Now** button on the **Exit** page to exit UEFI settings, as shown in Figure 8.
+
+*Figure 8. Click Restart Now to exit Surface UEFI and restart the device*
+
+
diff --git a/devices/surface/microsoft-surface-data-eraser.md b/devices/surface/microsoft-surface-data-eraser.md
index bf0348511d..e35e41bbf8 100644
--- a/devices/surface/microsoft-surface-data-eraser.md
+++ b/devices/surface/microsoft-surface-data-eraser.md
@@ -6,7 +6,7 @@ keywords: ["tool", "USB", "data", "erase"]
ms.prod: W10
ms.mktglfcycl: manage
ms.sitesec: library
-author: heatherpoulsen
+author: miladCA
---
# Microsoft Surface Data Eraser
@@ -40,15 +40,10 @@ Some scenarios where Microsoft Surface Data Eraser can be helpful include:
- Standard practice when performing reimaging for devices used with sensitive data
-**Note**
-Third-party devices, Surface devices running Windows RT (including Surface and Surface 2), and Surface Pro are not compatible with Microsoft Surface Data Eraser.
+>**Note:** Third-party devices, Surface devices running Windows RT (including Surface and Surface 2), and Surface Pro are not compatible with Microsoft Surface Data Eraser.
-
+>**Note:** Because the ability to boot to USB is required to run Microsoft Surface Data Eraser, if the device is not configured to boot from USB or if the device is unable to boot or POST successfully, the Microsoft Surface Data Eraser tool will not function.
-**Note**
-Because the ability to boot to USB is required to run Microsoft Surface Data Eraser, if the device is not configured to boot from USB or if the device is unable to boot or POST successfully, the Microsoft Surface Data Eraser tool will not function.
-
-
## How to create a Microsoft Surface Data Eraser USB stick
@@ -74,12 +69,8 @@ After the creation tool is installed, follow these steps to create a Microsoft S
Figure 1. Start the Microsoft Surface Data Eraser tool
4. Select the USB drive of your choice from the **USB Thumb Drive Selection** page as shown in Figure 2, and then click **Start** to begin the USB creation process. The drive you select will be formatted and any existing data on this drive will be lost.
-
- **Note**
- If the Start button is disabled, check that your removable drive has a total capacity of at least 4 GB.
-
-
-
+ >**Note:** If the Start button is disabled, check that your removable drive has a total capacity of at least 4 GB.
+
Figure 2. USB thumb drive selection
diff --git a/devices/surface/microsoft-surface-deployment-accelerator.md b/devices/surface/microsoft-surface-deployment-accelerator.md
index 7b79663642..e38d23d94b 100644
--- a/devices/surface/microsoft-surface-deployment-accelerator.md
+++ b/devices/surface/microsoft-surface-deployment-accelerator.md
@@ -6,7 +6,7 @@ keywords: ["deploy", "install", "tool"]
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
-author: heatherpoulsen
+author: miladCA
---
# Microsoft Surface Deployment Accelerator
@@ -20,7 +20,7 @@ Microsoft Surface Deployment Accelerator is built on the powerful suite of deplo
You can find more information about how to deploy to Surface devices, including step-by-step walkthroughs of customized deployment solution implementation, on the Deploy page of the [Surface TechCenter](http://go.microsoft.com/fwlink/p/?LinkId=691693).
-### Download Microsoft Surface Deployment Accelerator
+**Download Microsoft Surface Deployment Accelerator**
You can download the installation files for Microsoft Surface Deployment Accelerator from the Microsoft Download Center. To download the installation files:
@@ -60,8 +60,7 @@ When the Microsoft Surface Deployment Accelerator completes, you can use the dep
You can modify the task sequence in the MDT Deployment Workbench to [include your own apps](http://go.microsoft.com/fwlink/p/?linkid=691700), or to [pause the automated installation routine](http://go.microsoft.com/fwlink/p/?linkid=691701). While the installation is paused, you can make changes to customize your reference image. After the image is captured, you can configure a deployment task sequence and distribute this custom configuration by using the same network boot capabilities as before.
-**Note**
-With Microsoft Surface Deployment Accelerator v1.9.0258, Surface Pro 3, Surface Pro 4, and Surface Book are supported for Windows 10 deployment, and Surface Pro 3 is supported for Windows 8.1 deployment.
+>**Note:** With Microsoft Surface Deployment Accelerator v1.9.0258, Surface Pro 3, Surface Pro 4, and Surface Book are supported for Windows 10 deployment, and Surface Pro 3 is supported for Windows 8.1 deployment.
@@ -76,8 +75,7 @@ Figure 2. Specify a local source for Surface driver and app files
You can find a full list of available driver downloads at [Download the latest firmware and drivers for Surface devices](deploy-the-latest-firmware-and-drivers-for-surface-devices.md)
-**Note**
-Downloaded files do not need to be extracted. The downloaded files can be left as .zip files as long as they are stored in one folder.
+>**Note:** Downloaded files do not need to be extracted. The downloaded files can be left as .zip files as long as they are stored in one folder.
diff --git a/devices/surface/step-by-step-surface-deployment-accelerator.md b/devices/surface/step-by-step-surface-deployment-accelerator.md
index 37fa2adb25..b04c37e9b5 100644
--- a/devices/surface/step-by-step-surface-deployment-accelerator.md
+++ b/devices/surface/step-by-step-surface-deployment-accelerator.md
@@ -6,7 +6,7 @@ keywords: ["deploy, configure"]
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
-author: heatherpoulsen
+author: miladCA
---
# Step by step: Surface Deployment Accelerator
@@ -37,8 +37,7 @@ The tool installs in the Surface Deployment Accelerator program group, as shown
Figure 2. The Surface Deployment Accelerator program group and icon
-**Note**
-At this point the tool has not yet prepared any deployment environment or downloaded any materials from the Internet.
+>**Note:** At this point the tool has not yet prepared any deployment environment or downloaded any materials from the Internet.
@@ -47,8 +46,7 @@ At this point the tool has not yet prepared any deployment environment or downlo
The following steps show how you create a deployment share for Windows 10 that supports Surface Pro 3, Surface Pro 4, Surface Book, the Surface Firmware Tool, and the Surface Asset Tag Tool. As you follow the steps below, make the selections that are applicable for your organization. For example, you could choose to deploy Windows 10 to Surface Book only, without any of the Surface apps.
-**Note**
-SDA lets you create deployment shares for both Windows 8.1 and Windows 10 deployments, but you can only create a single deployment share at a time. Therefore, to create both Windows 8.1 and Windows 10 deployment shares, you will need to run the tool twice.
+>**Note:** SDA lets you create deployment shares for both Windows 8.1 and Windows 10 deployments, but you can only create a single deployment share at a time. Therefore, to create both Windows 8.1 and Windows 10 deployment shares, you will need to run the tool twice.
@@ -116,8 +114,7 @@ SDA lets you create deployment shares for both Windows 8.1 and Windows 10 depl
If you are unable to connect to the Internet with your deployment server, or if you want to download the Surface drivers and apps separately, you can specify a local source for the driver an app files at the time of deployment share creation. On the **Configure** page of the SDA wizard, select the **Copy from a Local Directory** check box, as shown in Figure 6. The **Download from the Internet** check box will be automatically deselected. Enter the folder location where you have placed the driver and app files in the **Local Path** field, as shown in Figure 6.
-**Note**
-All of the downloaded driver and applications files must be located in the same folder. The driver and app files do not need to be extracted from the downloaded .zip files.
+>**Note:** All of the downloaded driver and applications files must be located in the same folder. The driver and app files do not need to be extracted from the downloaded .zip files.
@@ -125,8 +122,7 @@ All of the downloaded driver and applications files must be located in the same
Figure 6. Specify the Surface driver and app files from a local path
-**Note**
-The **Copy from a Local Directory** check box is only available in SDA version 1.90.0221 or later.
+>**Note:** The **Copy from a Local Directory** check box is only available in SDA version 1.90.0221 or later.
@@ -134,8 +130,7 @@ The **Copy from a Local Directory** check box is only available in SDA version 1
You can use USB media to perform an SDA deployment if your Surface device is unable to boot from the network. For example, if you do not have a Microsoft Surface Ethernet Adapter or Microsoft Surface dock to facilitate network boot (PXE boot). The USB drive produced by following these steps includes a complete copy of the SDA deployment share and can be run on a Surface device without a network connection.
-**Note**
-The offline media files for the complete SDA deployment share are approximately 9 GB in size. Your USB drive must be at least 9 GB in size. A 16 GB USB drive is recommended.
+>**Note:** The offline media files for the complete SDA deployment share are approximately 9 GB in size. Your USB drive must be at least 9 GB in size. A 16 GB USB drive is recommended.
@@ -149,8 +144,7 @@ Before you can create bootable media files within the MDT Deployment Workbench o
4. **clean** – Removes all configuration from your USB drive.
- **Warning**
- This step will remove all information from your drive. Verify that your USB drive does not contain any needed data before you perform the **clean** command.
+ >**Warning:** This step will remove all information from your drive. Verify that your USB drive does not contain any needed data before you perform the **clean** command.
@@ -168,8 +162,7 @@ Before you can create bootable media files within the MDT Deployment Workbench o
Figure 7. Use DiskPart to prepare a USB drive for boot
- **Note**
- You can format your USB drive with FAT32 from Disk Management, but you must still use DiskPart to set the partition as active for the drive to boot properly.
+ >**Note:** You can format your USB drive with FAT32 from Disk Management, but you must still use DiskPart to set the partition as active for the drive to boot properly.
@@ -276,8 +269,7 @@ When you run the task sequence, you will be prompted to provide the following in
- A product key, if one is required
- **Note**
- If you are deploying the same version of Windows as the version that came on your device, no product key is required.
+ >**Note:** If you are deploying the same version of Windows as the version that came on your device, no product key is required.
@@ -293,8 +285,7 @@ The **2 – Create Windows Reference Image** task sequence is used to perform a
Like the **1 – Deploy Microsoft Surface** task sequence, the **2 – Create Windows Reference Image** task sequence performs a deployment of the unaltered Windows image directly from the installation media. Creation of a reference image should always be performed on a virtual machine. Using a virtual machine as your reference system helps to ensure that the resulting image is compatible with different hardware configurations.
-**Note**
-Using a virtual machine when you create a reference image for Windows deployment is a recommended practice for performing Windows deployments with Microsoft deployment tools including the Microsoft Deployment Toolkit and System Center Configuration Manager. These Microsoft deployment technologies use the hardware agnostic images produced from a virtual machine and a collection of managed drivers to deploy to different configurations of hardware. For more information see [Deploy a Windows 10 image using MDT 2013 Update 1](http://technet.microsoft.com/en-us/itpro/windows/deploy/deploy-a-windows-10-image-using-mdt).
+>**Note:** Using a virtual machine when you create a reference image for Windows deployment is a recommended practice for performing Windows deployments with Microsoft deployment tools including the Microsoft Deployment Toolkit and System Center Configuration Manager. These Microsoft deployment technologies use the hardware agnostic images produced from a virtual machine and a collection of managed drivers to deploy to different configurations of hardware. For more information see [Deploy a Windows 10 image using MDT 2013 Update 1](http://technet.microsoft.com/en-us/itpro/windows/deploy/deploy-a-windows-10-image-using-mdt).
diff --git a/devices/surface/surface-diagnostic-toolkit.md b/devices/surface/surface-diagnostic-toolkit.md
index 972b8ebe93..61e867468f 100644
--- a/devices/surface/surface-diagnostic-toolkit.md
+++ b/devices/surface/surface-diagnostic-toolkit.md
@@ -6,7 +6,7 @@ keywords: ["hardware, device, tool, test, component"]
ms.prod: W8
ms.mktglfcycl: manage
ms.sitesec: library
-author: heatherpoulsen
+author: miladCA
---
# Microsoft Surface Diagnostic Toolkit
@@ -16,8 +16,7 @@ Find out how you can use the Microsoft Surface Diagnostic Toolkit to test the ha
The [Microsoft Surface Diagnostic Toolkit](http://go.microsoft.com/fwlink/p/?LinkId=618121) is a small, portable diagnostic tool that runs through a suite of tests to diagnose the hardware of Surface devices. The Microsoft Surface Diagnostic Toolkit executable file is less than 3 MB, which allows it to be distributed through email. It does not require installation, so it can be run directly from a USB stick or over the network. The Microsoft Surface Diagnostic Toolkit walks you through several tests of individual components including the touchscreen, cameras, and sensors.
-**Note**
-A Surface device must boot into Windows to run the Microsoft Surface Diagnostic Toolkit. The Microsoft Surface Diagnostic Toolkit will run only on the following Surface devices:
+>**Note:** A Surface device must boot into Windows to run the Microsoft Surface Diagnostic Toolkit. The Microsoft Surface Diagnostic Toolkit will run only on the following Surface devices:
- Surface Book
@@ -33,12 +32,7 @@ A Surface device must boot into Windows to run the Microsoft Surface Diagnostic
- Surface Pro
-
-
-**Note**
-Security software and built-in security measures in many email applications and services will block executable files that are transferred through email. To email the Surface Diagnostic Toolkit, attach the .zip archive file as downloaded from the Surface Tools for IT page without extracting it first. You can also create a custom .zip archive that contains the .exe file. (For example, if you want to localize the text as described in the [Localization](#localization) section of this article.)
-
-
+>**Note:** Security software and built-in security measures in many email applications and services will block executable files that are transferred through email. To email the Surface Diagnostic Toolkit, attach the .zip archive file as downloaded from the Surface Tools for IT page without extracting it first. You can also create a custom .zip archive that contains the .exe file. (For example, if you want to localize the text as described in the [Localization](#localization) section of this article.)
Running the Microsoft Surface Diagnostic Toolkit is a hands-on activity. The test sequence includes several tests that require you to perform actions or observe the outcome of the test, and then click the applicable **Pass** or **Fail** button. Some tests require connectivity to external devices, like an external display. Other tests use the built in Windows troubleshooters. At the end of testing, a visual report of the test results is displayed and you are given the option to save a log file or copy the results to the clipboard.
@@ -56,8 +50,7 @@ To run a full set of tests with the Microsoft Surface Diagnostic Toolkit, you sh
- External speakers or headphones
-**Note**
-The Microsoft Surface Diagnostic Toolkit tests verify only the hardware of a Surface device and do not test or resolve issues with the operating system or software.
+>**Note:** The Microsoft Surface Diagnostic Toolkit tests verify only the hardware of a Surface device and do not test or resolve issues with the operating system or software.
@@ -122,8 +115,7 @@ These files and logs are stored in a .zip file saved by the Microsoft Surface Di
### Type Cover test
-**Note**
-A Surface Type Cover is required for this test.
+>**Note:** A Surface Type Cover is required for this test.
@@ -131,8 +123,7 @@ If a Surface Type Cover is not detected, the test prompts you to connect the Typ
### Integrated keyboard test
-**Note**
-This test is only applicable to Surface Book and requires that the Surface Book be docked to the keyboard.
+>**Note:** This test is only applicable to Surface Book and requires that the Surface Book be docked to the keyboard.
@@ -140,8 +131,7 @@ This test is essentially the same as the Type Cover test, except the integrated
### Canvas mode battery test
-**Note**
-This test is only applicable to Surface Book.
+>**Note:** This test is only applicable to Surface Book.
@@ -149,8 +139,7 @@ Depending on which mode Surface Book is in, different batteries are used to powe
### Clipboard mode battery test
-**Note**
-This test is only applicable to Surface Book.
+>**Note:** This test is only applicable to Surface Book.
@@ -158,8 +147,7 @@ Disconnect the Surface Book from the keyboard to work in clipboard mode. In clip
### Laptop mode battery test
-**Note**
-This test is only applicable to Surface Book.
+>**Note:** This test is only applicable to Surface Book.
@@ -171,8 +159,7 @@ In this test the battery is discharged for a few seconds and tested for health a
### Discrete graphics (dGPU) test
-**Note**
-This test is only applicable to Surface Book models with a discrete graphics processor.
+>**Note:** This test is only applicable to Surface Book models with a discrete graphics processor.
@@ -180,8 +167,7 @@ This test will query the device information of current hardware to check for the
### Discrete graphics (dGPU) fan test
-**Note**
-This test is only applicable to Surface Book models with a discrete graphics processor.
+>**Note:** This test is only applicable to Surface Book models with a discrete graphics processor.
@@ -189,8 +175,7 @@ The discrete graphics processor in the Surface Book includes a separate cooling
### Muscle wire test
-**Note**
-This test is only applicable to Surface Book.
+>**Note:** This test is only applicable to Surface Book.
@@ -198,8 +183,7 @@ To disconnect the Surface Book from the keyboard, software must instruct the mus
### Dead pixel and display artifacts tests
-**Note**
-Before you run this test, be sure to clean the screen of dust or smudges.
+>**Note:** Before you run this test, be sure to clean the screen of dust or smudges.
@@ -219,8 +203,7 @@ The Surface touchscreen should detect input across the entire screen of the devi
### Digitizer pen test
-**Note**
-A Microsoft Surface Pen is required for this test.
+>**Note:** A Microsoft Surface Pen is required for this test.
@@ -240,8 +223,7 @@ This test prompts you to use the volume rocker to turn the volume all the way up
### Micro SD or SD slot test
-**Note**
-This test requires a micro SD or SD card that is compatible with the slot in your Surface device.
+>**Note:** This test requires a micro SD or SD card that is compatible with the slot in your Surface device.
@@ -253,8 +235,7 @@ This test displays the **Recording** tab of the Sound item in Control Panel. The
### Video out test
-**Note**
-This test requires an external display with the applicable connection for your Surface device.
+>**Note:** This test requires an external display with the applicable connection for your Surface device.
@@ -262,8 +243,7 @@ Surface devices provide a Mini DisplayPort connection for connecting to an exter
### Bluetooth test
-**Note**
-This test requires a Bluetooth device. The device must be set to pairing mode or made discoverable to perform this test.
+>**Note:** This test requires a Bluetooth device. The device must be set to pairing mode or made discoverable to perform this test.
@@ -275,8 +255,7 @@ Use this test to verify that the cameras on your Surface device are operating pr
### Speaker test
-**Note**
-Headphones or external speakers are required to test the headphone jack in this test.
+>**Note:** Headphones or external speakers are required to test the headphone jack in this test.
@@ -284,8 +263,7 @@ This test plays audio over left and right channels respectively, both for the in
### Network test
-**Note**
-Connect the Surface device to a Wi-Fi network before you run this test. Connections that are made during the test are removed when the test is completed.
+>**Note:** Connect the Surface device to a Wi-Fi network before you run this test. Connections that are made during the test are removed when the test is completed.
@@ -317,8 +295,7 @@ The ambient light sensor is used to automatically adjust screen brightness relat
### Device orientation test
-**Note**
-Before you run this test, disable rotation lock from the Action Center if enabled.
+>**Note:** Before you run this test, disable rotation lock from the Action Center if enabled.
@@ -330,8 +307,7 @@ This test cycles the screen through brightness levels from 0 percent to 100 perc
### System assessment
-**Note**
-The Surface device must be connected to AC power before you can run this test.
+>**Note:** The Surface device must be connected to AC power before you can run this test.
@@ -350,8 +326,7 @@ If your Surface device has encountered an error that caused the device to fail o
You can run the Microsoft Surface Diagnostic Toolkit from the command line or as part of a script. The tool supports the following arguments:
-**Note**
-Many of the tests performed by the Microsoft Surface Diagnostic Toolkit require technician interaction. The Microsoft Surface Diagnostic Toolkit cannot run unattended.
+>**Note:** Many of the tests performed by the Microsoft Surface Diagnostic Toolkit require technician interaction. The Microsoft Surface Diagnostic Toolkit cannot run unattended.
@@ -506,8 +481,7 @@ By default, the Microsoft Surface Diagnostic Toolkit is available in English onl
6. Save the SurfaceDiagnosticTool\_v1.0.60.0.locale file.
-**Note**
-The SurfaceDiganosticTool\_v1.0.60.0.locale file must be located in the same folder and have the same name other than the file extension as the Microsoft Surface Diagnostic Toolkit executable file to use the custom prompt text. The SurfaceDiganosticTool\_v1.0.60.0.locale is an .xml file and must use UTF-8 encoding.
+>**Note:** The SurfaceDiganosticTool\_v1.0.60.0.locale file must be located in the same folder and have the same name other than the file extension as the Microsoft Surface Diagnostic Toolkit executable file to use the custom prompt text. The SurfaceDiganosticTool\_v1.0.60.0.locale is an .xml file and must use UTF-8 encoding.
diff --git a/devices/surface/surface-dock-updater.md b/devices/surface/surface-dock-updater.md
index 6cee308250..38115ae721 100644
--- a/devices/surface/surface-dock-updater.md
+++ b/devices/surface/surface-dock-updater.md
@@ -5,7 +5,7 @@ ms.assetid: 1FEFF277-F7D1-4CB4-8898-FDFE8CBE1D5C
ms.prod: W10
ms.mktglfcycl: manage
ms.sitesec: library
-author: heatherpoulsen
+author: jobotto
---
# Microsoft Surface Dock Updater
@@ -17,8 +17,7 @@ The [Microsoft Surface Dock Updater](http://go.microsoft.com/fwlink/p/?LinkId=61
When you run the Microsoft Surface Dock Updater installer you will be prompted to accept an End User License Agreement (EULA).
-**Note**
-Updating Surface Dock firmware requires connectivity to the Surface Dock, available only on Surface Pro 3, Surface Pro 4, and Surface Book devices. A Surface Pro 3, Surface Pro 4, or Surface Book is required to successfully install Microsoft Surface Dock Updater.
+>**Note:** Updating Surface Dock firmware requires connectivity to the Surface Dock, available only on Surface Pro 3, Surface Pro 4, and Surface Book devices. A Surface Pro 3, Surface Pro 4, or Surface Book is required to successfully install Microsoft Surface Dock Updater.
## Update a Surface Dock with Microsoft Surface Dock Updater
@@ -73,8 +72,7 @@ To update a Surface Dock with Microsoft Surface Dock Updater, follow these steps
9. If you want to update multiple Surface Docks in one sitting, you can click the **Update another Surface Dock** button to begin the process on the next Surface Dock.
- **Note**
- The LED in the Ethernet port of the dock will blink while the update is in progress. Please wait until the LED stops blinking before you unplug your Surface Dock from power.
+ >**Note:** The LED in the Ethernet port of the dock will blink while the update is in progress. Please wait until the LED stops blinking before you unplug your Surface Dock from power.
@@ -96,11 +94,12 @@ Microsoft Surface Dock Updater logs its progress into the Event Log, as shown in
| 12102 | Event in the DisplayPort chipset firmware update process |
| 12105 | Error |
-
-
Figure 8. Surface Dock Updater events in Event Viewer
+
+
+
## Related topics
diff --git a/windows/deploy/activate-forest-by-proxy-vamt.md b/windows/deploy/activate-forest-by-proxy-vamt.md
index 03cd03b3ee..f178e14406 100644
--- a/windows/deploy/activate-forest-by-proxy-vamt.md
+++ b/windows/deploy/activate-forest-by-proxy-vamt.md
@@ -5,10 +5,12 @@ ms.assetid: 6475fc87-a6f7-4fa8-b0aa-de19f2dea7e5
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Activate by Proxy an Active Directory Forest
+
You can use the Volume Activation Management Tool (VAMT) Active Directory-Based Activation (ADBA) function to activate by proxy an Active Directory (AD) forest for an isolated workgroup that does not have Internet access. ADBA enables certain volume products to inherit activation from the domain.
**Important**
@@ -20,47 +22,30 @@ In a typical proxy-activation scenario, the VAMT host computer distributes a pro
For workgroups that are isolated from any larger network, you can still perform an AD forest activation. This requires installing a second instance of VAMT on a computer in the isolated group and using removable media to transfer activation data between that computer and another VAMT host computer that has Internet access. You can also activate by proxy a KMS Host key (CSVLK) in the core network if you do not want the host computer to connect to Microsoft over the Internet.
## Requirements
+
Before performing proxy activation, ensure that the network and the VAMT installation meet the following requirements:
- There is an instance of VAMT that is installed on a computer that has Internet access. If you are performing proxy activation for an isolated workgroup, you must also have VAMT installed on one of the computers in the workgroup.
-
- VAMT has administrative permissions to the Active Directory domain.
**To perform an Active Directory forest proxy activation**
1. Open VAMT.
-
2. In the left-side pane, click the **Active Directory-Based Activation** node.
-
3. In the right-side **Actions** pane, click **Proxy activate forest** to open the **Install Product Key** dialog box.
-
4. In the **Install Product Key** dialog box, select the KMS Host key (CSVLK) that you want to activate.
-
-5. If you want to rename the ADBA object, enter a new Active Directory-Based Activation Object name.
-
- **Important**
- If you want to rename the ADBA object, you must do it now. After you click **Install Key**, the name cannot be changed.
-
+5. If you want to rename the ADBA object, enter a new Active Directory-Based Activation Object name. If you want to rename the ADBA object, you must do it now. After you click **Install Key**, the name cannot be changed.
6. Enter the name of the file where you want to save the offline installation ID, or browse to the file location and then click **Open**. If you are activating an AD forest in an isolated workgroup, save the .cilx file to a removable media device.
-
-7. Click **Install Key**.
-
- VAMT displays the **Activating Active Directory** dialog box until it completes the requested action. The activated object and the date that it was created appear in the **Active Directory-Based Activation** node in the center pane.
-
+7. Click **Install Key**. VAMT displays the **Activating Active Directory** dialog box until it completes the requested action. The activated object and the date that it was created appear in the **Active Directory-Based Activation** node in the center pane.
9. Insert the removable media into the VAMT host that has Internet access. Make sure that you are on the root node, and that the **Volume Activation Management Tool** view is displayed in the center pane.
-
10. In the right-side **Actions** pane, click **Acquire confirmation IDs for CILX** to open the **Acquire confirmation IDs for file** dialog box.
-
11. In the **Acquire confirmation IDs for file** dialog box, browse to where the .cilx file you exported from the isolated workgroup host computer is located. Select the file, and then click **Open**. VAMT displays an **Acquiring Confirmation IDs** message while it contacts Microsoft and acquires the CIDs.
-
12. When the CID collection process is complete, VAMT displays a **Volume Activation Management Tool** message that shows how many confirmation IDs were successfully acquired, and the name of the file to which the IDs were saved. Click **OK** to close the message.
-
13. Remove the storage device that contains the .cilx file from the Internet-connected VAMT host computer and insert it into the VAMT host computer in the isolated workgroup.
-
14. Open VAMT and then click the **Active Directory-Based Activation** node in the left-side pane.
-
15. In the right-side **Actions** pane, click **Apply confirmation ID to Active Directory domain**, browse to the .cilx file and then click **Open**.
VAMT displays the **Activating Active Directory** dialog box until it completes the requested action. The activated object and the date that it was created appear in the **Active Directory-Based Activation** node in the center pane.
## Related topics
-- [Add and Remove Computers](add-remove-computers-vamt.md)
\ No newline at end of file
+
+- [Add and Remove Computers](add-remove-computers-vamt.md)
diff --git a/windows/deploy/activate-forest-vamt.md b/windows/deploy/activate-forest-vamt.md
index 65c4159dc4..267e03be9c 100644
--- a/windows/deploy/activate-forest-vamt.md
+++ b/windows/deploy/activate-forest-vamt.md
@@ -5,46 +5,41 @@ ms.assetid: 9b5bc193-799b-4aa5-9d3e-0e495f7195d3
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Activate an Active Directory Forest Online
+
You can use the Volume Activation Management Tool (VAMT) Active Directory-Based Activation (ADBA) function to activate an Active Directory (AD) forest over the Internet. ADBA enables certain products to inherit activation from the domain.
**Important**
ADBA is only applicable to Generic Volume License Keys (GVLKs) and KMS Host keys (CSVLKs). To use ADBA, one or more KMS Host keys (CSVLKs) must be installed on the AD forest, and client keys (GVLKs) must be installed on the client products.
## Requirements
+
Before performing online activation, ensure that the network and the VAMT installation meet the following requirements:
-
- VAMT is installed on a host computer that has Internet access.
-
- VAMT has administrative permissions to the Active Directory domain.
-
- The KMS Host key (CSVLK) you intend to use is added to VAMT in the **Product Keys** node.
-
**To perform an online Active Directory forest activation**
1. Open VAMT.
-
2. In the left-side pane, click the **Active Directory-Based Activation** node.
-
3. In the right-side **Actions** pane, click **Online activate forest** to open the **Install Product Key** dialog box.
-
4. In the **Install Product Key** dialog box, select the KMS Host key (CSVLK) that you want to apply to the AD forest.
-
5. If required, enter a new Active Directory-Based Activation Object name
**Important**
If you want to rename the ADBA object, you must do it now. After you click **Install Key**, the name cannot be changed.
6. Click **Install Key**.
-
7. VAMT displays the **Activating Active Directory** dialog box until it completes the requested action.
The activated object and the date that is was created appear in the **Active Directory-Based Activation** node in the center pane.
## Related topics
+
- [Scenario 1: Online Activation](scenario-online-activation-vamt.md)
-- [Add and Remove Computers](add-remove-computers-vamt.md)
\ No newline at end of file
+- [Add and Remove Computers](add-remove-computers-vamt.md)
diff --git a/windows/deploy/activate-using-active-directory-based-activation-client.md b/windows/deploy/activate-using-active-directory-based-activation-client.md
index 54dfb802e3..15ae96825a 100644
--- a/windows/deploy/activate-using-active-directory-based-activation-client.md
+++ b/windows/deploy/activate-using-active-directory-based-activation-client.md
@@ -2,16 +2,16 @@
title: Activate using Active Directory-based activation (Windows 10)
description: Active Directory-based activation is implemented as a role service that relies on AD DS to store activation objects.
ms.assetid: 08cce6b7-7b5b-42cf-b100-66c363a846af
-keywords: ["vamt", "volume activation", "activation", "windows activation"]
+keywords: vamt, volume activation, activation, windows activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: CFaw
---
# Activate using Active Directory-based activation
**Applies to**
-
- Windows 10
- Windows 8.1
- Windows 8
@@ -21,98 +21,76 @@ author: CFaw
- Windows Server 2008 R2
**Looking for retail activation?**
-
- [Get Help Activating Microsoft Windows](http://go.microsoft.com/fwlink/p/?LinkId=618644)
Active Directory-based activation is implemented as a role service that relies on AD DS to store activation objects. Active Directory-based activation requires that the forest schema be updated by adprep.exe on a computer running Windows Server 2012 R2 or Windows Server 2012, but after the schema is updated, older domain controllers can still activate clients.
-
Any domain-joined computers running Windows 10, Windows 8.1, Windows 8, Windows Server 2012 R2, or Windows Server 2012 with a GVLK will be activated automatically and transparently. They will stay activated as long as they remain members of the domain and maintain periodic contact with a domain controller. Activation takes place after the Licensing service starts. When this service starts, the computer contacts AD DS automatically, receives the activation object, and is activated without user intervention.
-
To allow computers with GVLKs to activate themselves, use the Volume Activation Tools console in Windows Server 2012 R2 or the VAMT in earlier versions of Windows Server to create an object in the AD DS forest. You create this activation object by submitting a KMS host key to Microsoft, as shown in Figure 10.
-
The process proceeds as follows:
-
1. Perform one of the following tasks:
-
- Install the Volume Activation Services server role on a domain controller running Windows Server 2012 R2, and add a KMS host key by using the Volume Activation Tools Wizard.
-
- Extend the domain to the Windows Server 2012 R2 schema level, and add a KMS host key by using the VAMT.
-
2. Microsoft verifies the KMS host key, and an activation object is created.
-
3. Client computers are activated by receiving the activation object from a domain controller during startup.
-
+
**Figure 10**. The Active Directory-based activation flow
-
+
For environments in which all computers are running Windows 10, Windows 8.1, Windows 8, Windows Server 2012 R2, or Windows Server 2012 R2, and they are joined to a domain, Active Directory-based activation is the best option for activating all client computers and servers, and you may be able to remove any KMS hosts from your environment.
-
If an environment will continue to contain earlier volume licensing operating systems and applications or if you have workgroup computers outside the domain, you need to maintain a KMS host to maintain activation status for earlier volume licensing editions of Windows and Office.
-
Clients that are activated with Active Directory-based activation will maintain their activated state for up to 180 days since the last contact with the domain, but they will periodically attempt to reactivate before then and at the end of the 180day period. By default, this reactivation event occurs every seven days.
-
When a reactivation event occurs, the client queries AD DS for the activation object. Client computers examine the activation object and compare it to the local edition as defined by the GVLK. If the object and GVLK match, reactivation occurs. If the AD DS object cannot be retrieved, client computers use KMS activation. If the computer is removed from the domain, when the computer or the Software Protection service is restarted, the operating system will change the status from activated to not activated, and the computer will try to activate with KMS.
-
## Step-by-step configuration: Active Directory-based activation
**Note**
You must be a member of the local Administrators group on all computers mentioned in these steps. You also need to be a member of the Enterprise Administrators group, because setting up Active Directory-based activation changes forest-wide settings.
-
**To configure Active Directory-based activation on Windows Server 2012 R2, complete the following steps:**
-
1. Use an account with Domain Administrator and Enterprise Administrator credentials to sign in to a domain controller.
-
2. Launch Server Manager.
-
3. Add the Volume Activation Services role, as shown in Figure 11.
-
+
**Figure 11**. Adding the Volume Activation Services role
-
+
4. Click the link to launch the Volume Activation Tools (Figure 12).
-
+
**Figure 12**. Launching the Volume Activation Tools
-
+
5. Select the **Active Directory-Based Activation** option (Figure 13).
-
+
**Figure 13**. Selecting Active Directory-Based Activation
-
+
6. Enter your KMS host key and (optionally) a display name (Figure 14).
-
+
**Figure 14**. Entering your KMS host key
-
+
7. Activate your KMS host key by phone or online (Figure 15).
-
+
**Figure 15**. Choosing how to activate your product
-
+
8. After activating the key, click **Commit**, and then click **Close**.
## Verifying the configuration of Active Directory-based activation
+
To verify your Active Directory-based activation configuration, complete the following steps:
-
1. After you configure Active Directory-based activation, start a computer that is running an edition of Windows that is configured by volume licensing.
-
2. If the computer has been previously configured with a MAK key, replace the MAK key with the GVLK by running the **slmgr.vbs /ipk** command and specifying the GLVK as the new product key.
-
3. If the computer is not joined to your domain, join it to the domain.
-
4. Sign in to the computer.
-
5. Open Windows Explorer, right-click **Computer**, and then click **Properties**.
-
6. Scroll down to the **Windows activation** section, and verify that this client has been activated.
**Note**
If you are using both KMS and Active Directory-based activation, it may be difficult to see whether a client has been activated by KMS or by Active Directory-based activation. Consider disabling KMS during the test, or make sure that you are using a client computer that has not already been activated by KMS. The **slmrg.vbs /dlv** command also indicates whether KMS has been used.
## See also
-- [Volume Activation for Windows 10](volume-activation-windows-10.md)
\ No newline at end of file
+- [Volume Activation for Windows 10](volume-activation-windows-10.md)
diff --git a/windows/deploy/activate-using-key-management-service-vamt.md b/windows/deploy/activate-using-key-management-service-vamt.md
index 2bf225376d..4c5d735436 100644
--- a/windows/deploy/activate-using-key-management-service-vamt.md
+++ b/windows/deploy/activate-using-key-management-service-vamt.md
@@ -2,16 +2,17 @@
title: Activate using Key Management Service (Windows 10)
ms.assetid: f2417bfe-7d25-4e82-bc07-de316caa8dac
description:
-keywords: ["vamt", "volume activation", "activation", "windows activation"]
+keywords: vamt, volume activation, activation, windows activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Activate using Key Management Service
-**Applies to**
+**Applies to**
- Windows 10
- Windows 8.1
- Windows 8
@@ -25,29 +26,25 @@ author: jdeckerMS
- [Get Help Activating Microsoft Windows](http://go.microsoft.com/fwlink/p/?LinkId=618644)
There are three possible scenarios for volume activation of Windows 10 or Windows Server 2012 R2 by using a Key Management Service (KMS) host:
-
- Host KMS on a computer running Windows 10
-
- Host KMS on a computer running Windows Server 2012 R2
-
- Host KMS on a computer running an earlier version of Windows
+Check out [Windows 10 Volume Activation Tips](https://blogs.technet.microsoft.com/askcore/2015/09/15/windows-10-volume-activation-tips/).
+
## Key Management Service in Windows 10
+
Installing a KMS host key on a computer running Windows 10 allows you to activate other computers running Windows 10 against this KMS host and earlier versions of the client operating system, such as Windows 8.1 or Windows 7.
-
Clients locate the KMS server by using resource records in DNS, so some configuration of DNS may be required. This scenario can be beneficial if your organization uses volume activation for clients and MAK-based activation for a smaller number of servers.
-
To enable KMS functionality, a KMS key is installed on a KMS host; then, the host is activated over the Internet or by phone using Microsoft’s activation services.
**Configure KMS in Windows 10**
1. Open an elevated command prompt.
-
2. Enter one of the following commands.
- To install a KMS key, type **slmgr.vbs /ipk <KmsKey>**.
- To activate online, type **slmgr.vbs /ato**.
- To activate by using the telephone, type **slui.exe 4**.
-
3. After activating the KMS key, restart the Software Protection Service.
For more information, see the information for Windows 7 in [Deploy KMS Activation](http://go.microsoft.com/fwlink/p/?LinkId=717032).
@@ -61,95 +58,83 @@ You cannot install a client KMS key into the KMS in Windows Server.
This scenario is commonly used in larger organizations that do not find the overhead of using a server a burden.
**Note**
+
If you receive error 0xC004F015 when trying to activate Windows 10 Enterprise, see [KB 3086418](http://go.microsoft.com/fwlink/p/?LinkId=620687).
**Configure KMS in Windows Server 2012 R2**
1. Sign in to a computer running Windows Server 2012 R2 with an account that has local administrative credentials.
-
2. Launch Server Manager.
-
3. Add the Volume Activation Services role, as shown in Figure 4.
-
- **Figure 4**. Adding the Volume Activation Services role in Server Manager
-
+
+ **Figure 4**. Adding the Volume Activation Services role in Server Manager\
+
4. When the role installation is complete, click the link to launch the Volume Activation Tools (Figure 5).
-
+
**Figure 5**. Launching the Volume Activation Tools
-5. Select the **Key Management Service (KMS)** option, and specify the computer that will act as the KMS host (Figure 6).
-
+ 5. Select the **Key Management Service (KMS)** option, and specify the computer that will act as the KMS host (Figure 6).
This can be the same computer on which you installed the role or another computer. For example, it can be a client computer running Windows 10.
-
- 
-
+
+ 
+
**Figure 6**. Configuring the computer as a KMS host
-
+
6. Install your KMS host key by typing it in the text box, and then click **Commit** (Figure 7).
-
+
**Figure 7**. Installing your KMS host key
-
+
7. If asked to confirm replacement of an existing key, click **Yes**.
-
8. After the product key is installed, you must activate it. Click **Next** (Figure 8).
-
+
**Figure 8**. Activating the software
-The KMS key can be activated online or by phone. See Figure 9.
+ The KMS key can be activated online or by phone. See Figure 9.
-
+ 
-**Figure 9**. Choosing to activate online
+ **Figure 9**. Choosing to activate online
Now that the KMS host is configured, it will begin to listen for activation requests. However, it will not activate clients successfully until the activation threshold is met.
## Verifying the configuration of Key Management Service
-You can verify KMS volume activation from the KMS host server or from the client computer. KMS volume activation requires a minimum threshold of 25 computers before activation requests will be processed. The verification process described here will increment the activation count each time a client computer contacts the KMS host, but unless the activation threshold is reached, the verification will take the form of an error message rather than a confirmation message.
+You can verify KMS volume activation from the KMS host server or from the client computer. KMS volume activation requires a minimum threshold of 25 computers before activation requests will be processed. The verification process described here will increment the activation count each time a client computer contacts the KMS host, but unless the activation threshold is reached, the verification will take the form of an error message rather than a confirmation message.
**Note**
+
If you configured Active Directory-based activation before configuring KMS activation, you must use a client computer that will not first try to activate itself by using Active Directory-based activation. You could use a workgroup computer that is not joined to a domain or a computer running Windows 7 or Windows Server 2008 R2.
To verify that KMS volume activation works, complete the following steps:
1. On the KMS host, open the event log and confirm that DNS publishing is successful.
-
2. On a client computer, open a Command Prompt window, type **Slmgr.vbs /ato**, and then press ENTER.
The **/ato** command causes the operating system to attempt activation by using whichever key has been installed in the operating system. The response should show the license state and detailed Windows version information.
-
3. On a client computer or the KMS host, open an elevated Command Prompt window, type **Slmgr /dlv**, and then press ENTER.
+
The **/dlv** command displays the detailed licensing information. The response should return an error that states that the KMS activation count is too low. This confirms that KMS is functioning correctly, even though the client has not been activated.
For more information about the use and syntax of slmgr.vbs, see [Slmgr.vbs Options](http://go.microsoft.com/fwlink/p/?LinkId=733639).
## Key Management Service in earlier versions of Windows
+
If you have already established a KMS infrastructure in your organization for an earlier version of Windows, you may want to continue using that infrastructure to activate computers running Windows 10 or Windows Server 2012 R2. Your existing KMS host must be running Windows 7 or later. To upgrade your KMS host, complete the following steps:
1. Download and install the correct update for your current KMS host operating system. Restart the computer as directed.
-
2. Request a new KMS host key from the Volume Licensing Service Center.
-
3. Install the new KMS host key on your KMS host.
-
4. Activate the new KMS host key by running the slmrg.vbs script.
For detailed instructions, see [Update that enables Windows 8.1 and Windows 8 KMS hosts to activate a later version of Windows](http://go.microsoft.com/fwlink/p/?LinkId=618265) and [Update that enables Windows 7 and Windows Server 2008 R2 KMS hosts to activate Windows 10](http://go.microsoft.com/fwlink/p/?LinkId=626590).
## See also
- [Volume Activation for Windows 10](volume-activation-windows-10.md)
-
-
-
-
-
-
-
diff --git a/windows/deploy/activate-windows-10-clients-vamt.md b/windows/deploy/activate-windows-10-clients-vamt.md
index 584155bc6f..91b743947e 100644
--- a/windows/deploy/activate-windows-10-clients-vamt.md
+++ b/windows/deploy/activate-windows-10-clients-vamt.md
@@ -2,16 +2,17 @@
title: Activate clients running Windows 10 (Windows 10)
description: After you have configured Key Management Service (KMS) or Active Directory-based activation on your network, activating a client running Windows 10 is easy.
ms.assetid: 39446e49-ad7c-48dc-9f18-f85a11ded643
-keywords: ["vamt", "volume activation", "activation", "windows activation"]
+keywords: vamt, volume activation, activation, windows activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Activate clients running Windows 10
-**Applies to**
+**Applies to**
- Windows 10
- Windows 8.1
- Windows 8
@@ -25,82 +26,79 @@ author: jdeckerMS
- [Get Help Activating Microsoft Windows](http://go.microsoft.com/fwlink/p/?LinkId=618644)
After you have configured Key Management Service (KMS) or Active Directory-based activation on your network, activating a client running Windows 10 is easy. If the computer has been configured with a Generic Volume License Key (GVLK), neither IT nor the user need take any action. It just works.
-
Enterprise edition images and installation media should already be configured with the GVLK. When the client computer starts, the Licensing service examines the current licensing condition of the computer.
-
If activation or reactivation is required, the following sequence occurs:
-
1. If the computer is a member of a domain, it asks a domain controller for a volume activation object. If Active Directory-based activation is configured, the domain controller returns the object. If the object matches the edition of the software that is installed and the computer has a matching GVLK, the computer is activated (or reactivated), and it will not need to be activated again for 180 days, although the operating system will attempt reactivation at much shorter, regular intervals.
-
2. If the computer is not a member of a domain or if the volume activation object is not available, the computer will issue a DNS query to attempt to locate a KMS server. If a KMS server can be contacted, activation occurs if the KMS has a key that matches the computer’s GVLK.
-
3. The computer tries to activate against Microsoft servers if it is configured with a MAK.
If the client is not able to activate itself successfully, it will periodically try again. The frequency of the retry attempts depends on the current licensing state and whether the client computer has been successfully activated in the past. For example, if the client computer had been previously activated by Active Directory-based activation, it will periodically try to contact the domain controller at each restart.
## How Key Management Service works
+
KMS uses a client–server topology. KMS client computers can locate KMS host computers by using DNS or a static configuration. KMS clients contact the KMS host by using RPCs carried over TCP/IP.
### Key Management Service activation thresholds
+
You can activate physical computers and virtual machines by contacting a KMS host. To qualify for KMS activation, there must be a minimum number of qualifying computers (called the activation threshold). KMS clients will be activated only after this threshold has been met. Each KMS host counts the number of computers that have requested activation until the threshold is met.
A KMS host responds to each valid activation request from a KMS client with the count of how many computers have already contacted the KMS host for activation. Client computers that receive a count below the activation threshold are not activated. For example, if the first two computers that contact the KMS host are running Windows 10, the first receives an activation count of 1, and the second receives an activation count of 2. If the next computer is a virtual machine on a computer running Windows 10, it receives an activation count of 3, and so on. None of these computers will be activated, because computers running Windows 10, like other client operating system versions, must receive an activation count of 25 or more.
-
When KMS clients are waiting for the KMS to reach the activation threshold, they will connect to the KMS host every two hours to get the current activation count. They will be activated when the threshold is met.
In our example, if the next computer that contacts the KMS host is running Windows Server 2012 R2, it receives an activation count of 4, because activation counts are cumulative. If a computer running Windows Server 2012 R2 receives an activation count that is 5 or more, it is activated. If a computer running Windows 10 receives an activation count of 25 or more, it is activated.
### Activation count cache
+
To track the activation threshold, the KMS host keeps a record of the KMS clients that request activation. The KMS host gives each KMS client a client ID designation, and the KMS host saves each client ID in a table. By default, each activation request remains in the table for up to 30 days. When a client renews its activation, the cached client ID is removed from the table, a new record is created, and the 30day period begins again. If a KMS client computer does not renew its activation within 30 days, the KMS host removes the corresponding client ID from the table and reduces the activation count by one.
-
However, the KMS host only caches twice the number of client IDs that are required to meet the activation threshold. Therefore, only the 50 most recent client IDs are kept in the table, and a client ID could be removed much sooner than 30 days.
-
The total size of the cache is set by the type of client computer that is attempting to activate. If a KMS host receives activation requests only from servers, the cache will hold only 10 client IDs (twice the required 5). If a client computer running Windows 10 contacts that KMS host, KMS increases the cache size to 50 to accommodate the higher threshold. KMS never reduces the cache size.
### Key Management Service connectivity
+
KMS activation requires TCP/IP connectivity. By default, KMS hosts and clients use DNS to publish and find the KMS. The default settings can be used, which require little or no administrative action, or KMS hosts and client computers can be manually configured based on network configuration and security requirements.
### Key Management Service activation renewal
+
KMS activations are valid for 180 days (the *activation validity interval*). To remain activated, KMS client computers must renew their activation by connecting to the KMS host at least once every 180 days. By default, KMS client computers attempt to renew their activation every 7 days. If KMS activation fails, the client computer retries every two hours. After a client computer’s activation is renewed, the activation validity interval begins again.
### Publication of the Key Management Service
+
The KMS uses service (SRV) resource records in DNS to store and communicate the locations of KMS hosts. KMS hosts use the DNS dynamic update protocol, if available, to publish the KMS service (SRV) resource records. If dynamic update is not available or the KMS host does not have rights to publish the resource records, the DNS records must be published manually, or you must configure client computers to connect to specific KMS hosts.
### Client discovery of the Key Management Service
+
By default, KMS client computers query DNS for KMS information. The first time a KMS client computer queries DNS for KMS information, it randomly chooses a KMS host from the list of service (SRV) resource records that DNS returns. The address of a DNS server that contains the service (SRV) resource records can be listed as a suffixed entry on KMS client computers, which allows one DNS server to advertise the service (SRV) resource records for KMS, and KMS client computers with other primary DNS servers to find it.
-
Priority and weight parameters can be added to the DnsDomainPublishList registry value for KMS. Establishing KMS host priority groupings and weighting within each group allows you to specify which KMS host the client computers should try first and balances traffic among multiple KMS hosts. Only Windows 10, Windows 8.1, Windows 8, Windows 7, Windows Server 2012 R2, Windows Server 2012, and Windows Server 2008 R2 provide these priority and weight parameters.
-
If the KMS host that a client computer selects does not respond, the KMS client computer removes that KMS host from its list of service (SRV) resource records and randomly selects another KMS host from the list. When a KMS host responds, the KMS client computer caches the name of the KMS host and uses it for subsequent activation and renewal attempts. If the cached KMS host does not respond on a subsequent renewal, the KMS client computer discovers a new KMS host by querying DNS for KMS service (SRV) resource records.
-
By default, client computers connect to the KMS host for activation by using anonymous RPCs through TCP port 1688. (You can change the default port.) After establishing a TCP session with the KMS host, the client computer sends a single request packet. The KMS host responds with the activation count. If the count meets or exceeds the activation threshold for that operating system, the client computer is activated and the session is closed. The KMS client computer uses this same process for renewal requests. 250 bytes are used for communication each way.
### Domain Name System server configuration
-The default KMS automatic publishing feature requires the service (SRV) resource record and support for DNS dynamic update protocol. KMS client computer default behavior and the KMS service (SRV) resource record publishing are supported on a DNS server that is running Microsoft software or any other DNS server that supports service (SRV) resource records (per Internet Engineering Task Force \[IETF\] Request for Comments \[RFC\] 2782) and dynamic updates (per IETF RFC 2136). For example, Berkeley Internet Domain Name versions 8.x and 9.x support service (SRV) resource records and dynamic update.
+The default KMS automatic publishing feature requires the service (SRV) resource record and support for DNS dynamic update protocol. KMS client computer default behavior and the KMS service (SRV) resource record publishing are supported on a DNS server that is running Microsoft software or any other DNS server that supports service (SRV) resource records (per Internet Engineering Task Force \[IETF\] Request for Comments \[RFC\] 2782) and dynamic updates (per IETF RFC 2136). For example, Berkeley Internet Domain Name versions 8.x and 9.x support service (SRV) resource records and dynamic update.
The KMS host must be configured so that it has the credentials needed to create and update the following resource records on the DNS servers: service (SRV), IPv4 host (A), and IPv6 host (AAAA), or the records need to be created manually. The recommended solution for giving the KMS host the needed credentials is to create a security group in AD DS, then add all KMS hosts to that group. On a DNS server that is running Microsoft software, ensure that this security group is given full control over the \_VLMCS.\_TCP record in each DNS domain that will contain the KMS service (SRV) resource records.
### Activating the first Key Management Service host
+
KMS hosts on the network need to install a KMS key, and then be activated with Microsoft. Installation of a KMS key enables the KMS on the KMS host. After installing the KMS key, complete the activation of the KMS host by telephone or online. Beyond this initial activation, a KMS host does not communicate any information to Microsoft. KMS keys are only installed on KMS hosts, never on individual KMS client computers.
### Activating subsequent Key Management Service hosts
+
Each KMS key can be installed on up to six KMS hosts. These hosts can be physical computers or virtual machines. After activating a KMS host, the same host can be reactivated up to nine times with the same key. If the organization needs more than six KMS hosts, you can request additional activations for your organization’s KMS key by calling a Microsoft Volume [Licensing Activation Center](http://go.microsoft.com/fwlink/p/?LinkID=618264) to request an exception.
## How Multiple Activation Key works
+
A MAK is used for one-time activation with Microsoft’s hosted activation services. Each MAK has a predetermined number of allowed activations. This number is based on volume licensing agreements, and it might not match the organization’s exact license count. Each activation that uses a MAK with the Microsoft hosted activation service counts toward the activation limit.
You can activate computers by using a MAK in two ways:
-
- **MAK independent activation**. Each computer independently connects and is activated with Microsoft over the Internet or by telephone. MAK independent activation is best suited to computers within an organization that do not maintain a connection to the corporate network. MAK independent activation is shown in Figure 16.
-
+
**Figure 16**. MAK independent activation
-
- **MAK proxy activation**. MAK proxy activation enables a centralized activation request on behalf of multiple computers with one connection to Microsoft. You configure MAK proxy activation by using the VAMT. MAK proxy activation is appropriate for environments in which security concerns restrict direct access to the Internet or the corporate network. It is also suited for development and test labs that lack this connectivity. MAK proxy activation with the VAMT is shown in Figure 17.
-
+
**Figure 17**. MAK proxy activation with the VAMT
A MAK is recommended for computers that rarely or never connect to the corporate network and for environments in which the number of computers that require activation does not meet the KMS activation threshold.
@@ -108,21 +106,16 @@ A MAK is recommended for computers that rarely or never connect to the corporate
You can use a MAK for individual computers or with an image that can be duplicated or installed by using Microsoft deployment solutions. You can also use a MAK on a computer that was originally configured to use KMS activation. This is useful for moving a computer off the core network to a disconnected environment.
### Multiple Activation Key architecture and activation
-MAK independent activation installs a MAK product key on a client computer. The key instructs that computer to activate itself with Microsoft servers over the Internet.
+MAK independent activation installs a MAK product key on a client computer. The key instructs that computer to activate itself with Microsoft servers over the Internet.
In MAK proxy activation, the VAMT installs a MAK product key on a client computer, obtains the installation ID from the target computer, sends the installation ID to Microsoft on behalf of the client, and obtains a confirmation ID. The tool then activates the client computer by installing the confirmation ID.
## Activating as a standard user
+
Windows 10, Windows 8.1, Windows 8, Windows 7, Windows Server 2012 R2, Windows Server 2012, and Windows Server 2008 R2 do not require administrator privileges for activation, but this change does not allow standard user accounts to remove computers running Windows 7 or Windows Server 2008 R2 from the activated state. An administrator account is still required for other activation- or license-related tasks, such as “rearm.”
## See also
+
- [Volume Activation for Windows 10](volume-activation-windows-10.md)
-
-
-
-
-
-
-
diff --git a/windows/deploy/active-directory-based-activation-overview.md b/windows/deploy/active-directory-based-activation-overview.md
index fc73f66ca1..7f47592aa7 100644
--- a/windows/deploy/active-directory-based-activation-overview.md
+++ b/windows/deploy/active-directory-based-activation-overview.md
@@ -5,28 +5,23 @@ ms.assetid: c1dac3bd-6a86-4c45-83dd-421e63a398c0
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: CFaw
---
# Active Directory-Based Activation Overview
+
Active Directory-Based Activation (ADBA) enables enterprises to activate computers through a connection to their domain. Many companies have computers at offsite locations that use products that are registered to the company. Previously these computers needed to either use a retail key or a Multiple Activation Key (MAK), or physically connect to the network in order to activate their products by using Key Management Services (KMS). ADBA provides a way to activate these products if the computers can join the company’s domain. When the user joins their computer to the domain, the ADBA object automatically activates Windows installed on their computer, as long as the computer has a Generic Volume License Key (GVLK) installed. No single physical computer is required to act as the activation object, because it is distributed throughout the domain.
## Active Directory-Based Activation Scenarios
+
VAMT enables IT Professionals to manage and activate the Active Directory-Based Activation object. Activation can be performed by using a scenario such as the following:
-
- Online activation: To activate an ADBA forest online, the user selects the **Online activate forest** function, selects a KMS Host key (CSVLK) to use, and gives the Active Directory-Based Activation Object a name.
-
- Proxy activation: For a proxy activation, the user first selects the **Proxy activate forest** function, selects a KMS Host key (CSVLK) to use, gives the Active Directory-Based Activation Object a name, and provides a file name to save the CILx file that contains the Installation ID. Next, the user takes that file to a computer that is running VAMT with an Internet connection and then selects the **Acquire confirmation IDs for CILX** function on the VAMT landing page, and provides the original CILx file. When VAMT has loaded the Confirmation IDs into the original CILx file, the user takes this file back to the original VAMT instance, where the user completes the proxy activation process by selecting the **Apply confirmation ID to Active Directory domain** function.
## Related topics
+
- [How to Activate an Active Directory Forest Online](http://go.microsoft.com/fwlink/p/?LinkId=246565)
- [How to Proxy Activate an Active Directory Forest](http://go.microsoft.com/fwlink/p/?LinkId=246566)
-
-
-
-
-
-
-
diff --git a/windows/deploy/add-manage-products-vamt.md b/windows/deploy/add-manage-products-vamt.md
index 6bc5b1b8a8..6bbbfaf218 100644
--- a/windows/deploy/add-manage-products-vamt.md
+++ b/windows/deploy/add-manage-products-vamt.md
@@ -5,10 +5,12 @@ ms.assetid: a48fbc23-917d-40f7-985c-e49702c05e51
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Add and Manage Products
+
This section describes how to add client computers into the Volume Activation Management Tool (VAMT). After the computers are added, you can manage the products that are installed on your network.
## In this Section
@@ -18,14 +20,6 @@ This section describes how to add client computers into the Volume Activation Ma
|[Add and Remove Computers](add-remove-computers-vamt.md) |Describes how to add client computers to VAMT. |
|[Update Product Status](update-product-status-vamt.md) |Describes how to update the status of product license. |
|[Remove Products](remove-products-vamt.md) |Describes how to remove a product from the product list. |
-
-
-
-
-
-
-
-
diff --git a/windows/deploy/add-remove-computers-vamt.md b/windows/deploy/add-remove-computers-vamt.md
index 426401e5ff..eae34332f2 100644
--- a/windows/deploy/add-remove-computers-vamt.md
+++ b/windows/deploy/add-remove-computers-vamt.md
@@ -6,70 +6,53 @@ ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: jdeckerMS
+ms.pagetype: activation
---
# Add and Remove Computers
+
You can add computers that have any of the supported Windows or Office products installed to a Volume Activation Management Tool (VAMT) database by using the **Discover products** function. You can search for computers in an Active Directory domain, by individual computer name or IP address, in a workgroup, or by a general LDAP query. You can remove computers from a VAMT database by using the **Delete** function. After you add the computers, you can add the products that are installed on the computers by running the **Update license status** function.
Before adding computers, ensure that the Windows Management Instrumentation (WMI) firewall exception required by VAMT has been enabled on all target computers. For more information see [Configure Client Computers](configure-client-computers-vamt.md).
## To add computers to a VAMT database
+
1. Open VAMT.
-
2. Click **Discover products** in the **Actions** menu in the right-side pane to open the **Discover Products** dialog box.
-
3. In the **Discover products** dialog box, click **Search for computers in the Active Directory** to display the search options, then click the search option you want to use. You can search for computers in an Active Directory domain, by individual computer name or IP address, in a workgroup, or by a general LDAP query.
-
- To search for computers in an Active Directory domain, click **Search for computers in the Active Directory**, then under **Domain Filter Criteria**, in the list of domain names click the name of the domain you want to search. You can narrow the search further by typing a name in the **Filter by computer name** field to search for a specific computer within the domain. This filter supports the asterisk (\*) wildcard. For example, typing "a\*" will display only computer names that start with the letter "a".
-
- To search by individual computer name or IP address, click **Manually enter name or IP address**, then enter the full name or IP address in the **One or more computer names or IP addresses separated by commas** text box. Separate multiple entries with a comma. Note that VAMT supports both IPv4 and IPV6 addressing.
-
- To search for computers in a workgroup, click **Search for computers in the workgroup**, then under **Workgroup Filter Criteria**, in the list of workgroup names click the name of the workgroup you want to search. You can narrow the search further by typing a name in the **Filter by computer name** field to search for a specific computer within the workgroup. This filter supports the asterisk (\*) wildcard. For example, typing "a\*" will display only computer names that start with the letter "a".
-
- To search for computers by using a general LDAP query, click **Search with LDAP query** and enter your query in the text box provided. VAMT will validate only the LDAP query syntax, but will otherwise run the query without further checks.
-
4. Click **Search**.
-
5. VAMT searches for the specified computers and adds them to the VAMT database. During the search, VAMT displays the **Finding computers** message shown below.
-
To cancel the search, click **Cancel**. When the search is complete the names of the newly-discovered computers appear in the product list view in the center pane.
-
+
**Important**
This step adds only the computers to the VAMT database, and not the products that are installed on the computers. To add the products, you need to run the **Update license status** function.
-
+
## To add products to VAMT
+
1. In the **Products** list, select the computers that need to have their product information added to the VAMT database.
-
2. You can use the **Filter** function to narrow your search for computers by clicking **Filter** in the right-side pane to open the **Filter Products** dialog box.
-
3. In the **Filter Products** dialog box, you can filter the list by computer name, product name, product key type, license status, or by any combination of these options.
-
- To filter the list by computer name, enter a name in the **Computer Name** box.
-
- To filter the list by Product Name, Product Key Type, or License Status, click the list you want to use for the filter and select an option. If necessary, click **clear all filters** to create a new filter.
-
4. Click **Filter**. VAMT displays the filtered list in the center pane.
-
5. In the right-side **Actions** pane, click **Update license status** and then click a credential option. Choose **Alternate Credentials** only if you are updating products that require administrator credentials different from the ones you used to log into the computer. If you are supplying alternate credentials, in the **Windows Security** dialog box type the appropriate user name and password and click **OK**.
-
6. VAMT displays the **Collecting product information** dialog box while it collects the licensing status of all supported products on the selected computers. When the process is finished, the updated licensing status of each product will appear in the product list view in the center pane.
**Note**
If a computer has more than one supported product installed, VAMT adds an entry for each product. The entry appears under the appropriate product heading.
-
+
## To remove computers from a VAMT database
+
You can delete a computer by clicking on it in the product list view, and then clicking **Delete** in the **Selected Item** menu in the right-hand pane. In the **Confirm Delete Selected Products** dialog box that appears, click **Yes** to delete the computer. If a computer has multiple products listed, you must delete each product to completely remove the computer from the VAMT database.
## Related topics
+
- [Add and Manage Products](add-manage-products-vamt.md)
-
-
-
-
-
-
-
diff --git a/windows/deploy/add-remove-product-key-vamt.md b/windows/deploy/add-remove-product-key-vamt.md
index c237513201..5776806c20 100644
--- a/windows/deploy/add-remove-product-key-vamt.md
+++ b/windows/deploy/add-remove-product-key-vamt.md
@@ -5,30 +5,30 @@ ms.assetid: feac32bb-fb96-4802-81b8-c69220dcfcce
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Add and Remove a Product Key
+
Before you can use a Multiple Activation Key (MAK), retail, or KMS Host key (CSVLK) product key, you must first add it to the Volume Activation Management Tool (VAMT) database.
## To Add a Product Key
+
1. Open VAMT.
-
2. In the left-side pane, right-click the **Product Keys** node to open the **Actions** menu.
-
3. Click **Add product keys** to open the **Add Product Keys** dialog box.
-
4. In the **Add Product Keys** dialog box, select from one of the following methods to add product keys:
-
- To add product keys manually, click **Enter product key(s) separated by line breaks**, enter one or more product keys separated by line breaks, and click **Add Key(s)**.
-
- To import a Comma Separated Values (CSV) file containing a list of product keys, click **Select a product key file to import**, browse to the file location, click **Open** to import the file, and then click **Add Key(s)**.
**Note**
If you are activating a large number of products with a MAK, you should refresh the activation count of the MAK, to ensure that the MAK can support the required number of activations. In the product key list in the center pane, select the MAK and click **Refresh product key data online** in the right-side pane to contact Microsoft and retrieve the number of remaining activations for the MAK. This step requires Internet access. You can only retrieve the remaining activation count for MAKs.
## Remove a Product Key
+
- To remove a product key from the list, simply select the key in the list and click **Delete** on the **Selected Items** menu in the right-side pane. Click **Yes** to confirm deletion of the product key. Removing a product key from the VAMT database will not affect the activation state of any products or computers on the network.
## Related topics
-- [Manage Product Keys](manage-product-keys-vamt.md)
\ No newline at end of file
+
+- [Manage Product Keys](manage-product-keys-vamt.md)
diff --git a/windows/deploy/appendix-information-sent-to-microsoft-during-activation-client.md b/windows/deploy/appendix-information-sent-to-microsoft-during-activation-client.md
index 69204429e8..8a21466ddb 100644
--- a/windows/deploy/appendix-information-sent-to-microsoft-during-activation-client.md
+++ b/windows/deploy/appendix-information-sent-to-microsoft-during-activation-client.md
@@ -2,16 +2,15 @@
title: Appendix Information sent to Microsoft during activation (Windows 10)
ms.assetid: 4bfff495-07d0-4385-86e3-7a077cbd64b8
description:
-keywords: ["vamt", "volume activation", "activation", "windows activation"]
+keywords: vamt, volume activation, activation, windows activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
-
# Appendix: Information sent to Microsoft during activation
**Applies to**
-
- Windows 10
- Windows 8.1
- Windows 8
@@ -27,60 +26,39 @@ author: jdeckerMS
When you activate a computer running Windows 10, the following information is sent to Microsoft:
- The Microsoft product code (a five-digit code that identifies the Windows product you are activating)
-
- A channel ID or site code that identifies how the Windows product was originally obtained
For example, a channel ID or site code identifies whether the product was originally purchased from a retail store, obtained as an evaluation copy, obtained through a volume licensing program, or preinstalled by a computer manufacturer.
-
+
- The date of installation and whether the installation was successful
-
- Information that helps confirm that your Windows product key has not been altered
-
- Computer make and model
-
- Version information for the operating system and software
-
- Region and language settings
-
- A unique number called a *globally unique identifier*, which is assigned to your computer
-
- Product key (hashed) and product ID
-
- BIOS name, revision number, and revision date
-
- Volume serial number (hashed) of the hard disk drive
-
- The result of the activation check
This includes error codes and the following information about any activation exploits and related malicious or unauthorized software that was found or disabled:
-
+
- The activation exploit’s identifier
-
- The activation exploit’s current state, such as cleaned or quarantined
-
- Computer manufacturer’s identification
-
- The activation exploit’s file name and hash in addition to a hash of related software components that may indicate the presence of an activation exploit
-
- The name and a hash of the contents of your computer’s startup instructions file
-
- If your Windows license is on a subscription basis, information about how your subscription works
Standard computer information is also sent, but your computer’s IP address is only retained temporarily.
## Use of information
-Microsoft uses the information to confirm that you have a licensed copy of the software. Microsoft does not use the information to contact individual consumers.
+Microsoft uses the information to confirm that you have a licensed copy of the software. Microsoft does not use the information to contact individual consumers.
For additional details, see [Windows 10 Privacy Statement](http://go.microsoft.com/fwlink/p/?LinkId=619879).
## See also
+
- [Volume Activation for Windows 10](volume-activation-windows-10.md)
-
-
-
-
-
-
-
diff --git a/windows/deploy/assign-applications-using-roles-in-mdt-2013.md b/windows/deploy/assign-applications-using-roles-in-mdt-2013.md
index a93346b78f..dab995bb1e 100644
--- a/windows/deploy/assign-applications-using-roles-in-mdt-2013.md
+++ b/windows/deploy/assign-applications-using-roles-in-mdt-2013.md
@@ -2,29 +2,24 @@
title: Assign applications using roles in MDT (Windows 10)
description: This topic will show you how to add applications to a role in the MDT database and then assign that role to a computer.
ms.assetid: d82902e4-de9c-4bc4-afe0-41d649b83ce7
-keywords: ["settings, database, deploy"]
+keywords: settings, database, deploy
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: mdt
author: mtniehaus
---
# Assign applications using roles in MDT
-
This topic will show you how to add applications to a role in the MDT database and then assign that role to a computer. For the purposes of this topic, the application we are adding is Adobe Reader XI. In addition to using computer-specific entries in the database, you can use roles in MDT to group settings together.
## Create and assign a role entry in the database
-
1. On MDT01, using Deployment Workbench, in the MDT Production deployment share, expand **Advanced Configuration** and then expand **Database**.
-
2. In the **Database** node, right-click **Role**, select **New**, and create a role entry with the following settings:
-
1. Role name: Standard PC
-
2. Applications / Lite Touch Applications:
-
3. Install - Adobe Reader XI - x86
@@ -33,13 +28,9 @@ Figure 12. The Standard PC role with the application added
## Associate the role with a computer in the database
-
After creating the role, you can associate it with one or more computer entries.
-
1. Using Deployment Workbench, expand **MDT Production**, expand **Advanced Configuration**, expand **Database**, and select **Computers**.
-
2. In the **Computers** node, double-click the **PC00075** entry, and add the following setting:
-
- Roles: Standard PC
@@ -48,17 +39,13 @@ Figure 13. The Standard PC role added to PC00075 (having ID 1 in the database).
## Verify database access in the MDT simulation environment
-
When the database is populated, you can use the MDT simulation environment to simulate a deployment. The applications are not installed, but you can see which applications would be installed if you did a full deployment of the computer.
-
1. On PC0001, log on as **CONTOSO\\MDT\_BA**.
-
2. Modify the C:\\MDT\\CustomSettings.ini file to look like the following:
``` syntax
[Settings]
Priority=CSettings, CRoles, RApplications, Default
-
[Default]
_SMSTSORGNAME=Contoso
OSInstall=Y
@@ -90,7 +77,6 @@ When the database is populated, you can use the MDT simulation environment to si
SkipCapture=YES
SkipFinalSummary=NO
EventService=http://MDT01:9800
-
[CSettings]
SQLServer=MDT01
Instance=SQLEXPRESS
@@ -100,7 +86,6 @@ When the database is populated, you can use the MDT simulation environment to si
Table=ComputerSettings
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR
-
[CRoles]
SQLServer=MDT01
Instance=SQLEXPRESS
@@ -110,7 +95,6 @@ When the database is populated, you can use the MDT simulation environment to si
Table=ComputerRoles
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR
-
[RApplications]
SQLServer=MDT01
Instance=SQLEXPRESS
@@ -127,6 +111,7 @@ When the database is populated, you can use the MDT simulation environment to si
``` syntax
Set-Location C:\MDT
.\Gather.ps1
+
```
@@ -135,26 +120,12 @@ Figure 14. ZTIGather.log displaying the application GUID belonging to the Adobe
## Related topics
-
[Set up MDT for BitLocker](set-up-mdt-2013-for-bitlocker.md)
-
[Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
-
[Configure MDT for UserExit scripts](configure-mdt-2013-for-userexit-scripts.md)
-
[Simulate a Windows 10 deployment in a test environment](simulate-a-windows-10-deployment-in-a-test-environment.md)
-
[Use the MDT database to stage Windows 10 deployment information](use-the-mdt-database-to-stage-windows-10-deployment-information.md)
-
[Use web services in MDT](use-web-services-in-mdt-2013.md)
-
[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt-2013.md)
-
-
-
-
-
-
-
diff --git a/windows/deploy/build-a-distributed-environment-for-windows-10-deployment.md b/windows/deploy/build-a-distributed-environment-for-windows-10-deployment.md
index 481c3d0c86..32a354ad0e 100644
--- a/windows/deploy/build-a-distributed-environment-for-windows-10-deployment.md
+++ b/windows/deploy/build-a-distributed-environment-for-windows-10-deployment.md
@@ -2,18 +2,17 @@
title: Build a distributed environment for Windows 10 deployment (Windows 10)
description: In this topic, you will learn how to replicate your Windows 10 deployment shares to facilitate the deployment of Windows 10 in remote or branch locations.
ms.assetid: a6cd5657-6a16-4fff-bfb4-44760902d00c
-keywords: ["replication, replicate, deploy, configure, remote"]
+keywords: replication, replicate, deploy, configure, remote
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: mdt
author: mtniehaus
---
# Build a distributed environment for Windows 10 deployment
-
**Applies to**
-
- Windows 10
In this topic, you will learn how to replicate your Windows 10 deployment shares to facilitate the deployment of Windows 10 in remote or branch locations. If you work in a distributed environment, replicating the deployment shares is an important part of the deployment solution. With images reaching 5 GB in size or more, you can't deploy machines in a remote office over the wire. You need to replicate the content, so that the clients can do local deployments.
@@ -26,14 +25,11 @@ Figure 1. The machines used in this topic.
## Replicate deployment shares
-
Replicating the content between MDT01 (New York) and MDT02 (Stockholm) can be done in a number of different ways. The most common content replication solutions with Microsoft Deployment Toolkit (MDT) 2013 use either the Linked Deployment Shares (LDS) feature or Distributed File System Replication (DFS-R). Some organizations have used a simple robocopy script for replication of the content.
**Note**
Robocopy has options that allow for synchronization between folders. It has a simple reporting function; it supports transmission retry; and, by default, it will only copy/remove files from the source that are newer than files on the target.
-
-
### Linked deployment shares in MDT 2013 Update 2
LDS is a built-in feature in MDT for replicating content. However, LDS works best with strong connections such as LAN connections with low latency. For most WAN links, DFS-R is the better option.
@@ -44,19 +40,13 @@ DFS-R is not only very fast and reliable, but it also offers central monitoring,
## Set up Distributed File System Replication (DFS-R) for replication
-
Setting up DFS-R for replication is a quick and straightforward process. You prepare the deployment servers and then create a replication group. To complete the setup, you configure some replication settings.
### Prepare MDT01 for replication
-
1. On MDT01, using Server Manager, click **Add roles and features**.
-
2. On the **Select installation type** page, select **Role-based or feature-based installation**.
-
3. On the **Select destination server** page, select **MDT01.contoso.com** and click **Next**.
-
4. On the **Select server roles** page, expand **File and Storage Services (Installed)** and expand **File and iSCSI Services (Installed)**.
-
5. In the **Roles** list, select **DFS Replication**. In the **Add Roles and Features Wizard** dialog box, select **Add Features**, and then click **Next**.
@@ -64,43 +54,31 @@ Setting up DFS-R for replication is a quick and straightforward process. You pre
Figure 2. Adding the DFS Replication role to MDT01.
6. On the **Select features** page, accept the default settings, and click **Next**.
-
7. On the **Confirm installation selections** page, click **Install**.
-
8. On the **Installation progress** page, click **Close**.
### Prepare MDT02 for replication
1. On MDT02, using Server Manager, click **Add roles and features**.
-
2. On the **Select installation type** page, select **Role-based or feature-based installation**.
-
3. On the **Select destination server** page, select **MDT02.contoso.com** and click **Next**.
-
4. On the **Select server roles** page, expand **File and Storage Services (Installed)** and expand **File and iSCSI Services (Installed)**.
-
5. In the **Roles** list, select **DFS Replication**. In the **Add Roles and Features Wizard** dialog box, select **Add Features**, and then click **Next**.
-
6. On the **Select features** page, accept the default settings, and click **Next**.
-
7. On the **Confirm installation selections** page, click **Install**.
-
8. On the **Installation progress** page, click **Close**.
### Create the MDTProduction folder on MDT02
1. On MDT02, using File Explorer, create the **E:\\MDTProduction** folder.
-
2. Share the **E:\\MDTProduction** folder as **MDTProduction$**. Use the default permissions.
Figure 3. Sharing the **E:\\MDTProduction folder** on MDT02.
-
### Configure the deployment share
When you have multiple deployment servers sharing the same content, you need to configure the Bootstrap.ini file with information about which server to connect to based on where the client is located. In MDT, that can be done by using the DefaultGateway property.
-
1. On MDT01, using Notepad, navigate to the **E:\\MDTProduction\\Control** folder and modify the Boostrap.ini file to look like this:
``` syntax
@@ -118,14 +96,10 @@ When you have multiple deployment servers sharing the same content, you need to
UserID=MDT_BA
SkipBDDWelcome=YES
```
-
**Note**
The DeployRoot value needs to go into the Bootstrap.ini file, but you can use the same logic in the CustomSettings.ini file. For example, you can redirect the logs to the local deployment server (SLSHARE), or have the User State Migration Tool (USMT) migration store (UDDIR) local. To learn more about USMT, see [Refresh a Windows 7 computer with Windows 10](refresh-a-windows-7-computer-with-windows-10.md) and [Replace a Windows 7 computer with a Windows 10 computer](replace-a-windows-7-computer-with-a-windows-10-computer.md).
-
-
2. Save the Bootstrap.ini file.
-
3. Using the Deployment Workbench, right-click the **MDT Production** deployment share and select **Update Deployment Share**.
@@ -133,7 +107,6 @@ When you have multiple deployment servers sharing the same content, you need to
Figure 4. Updating the MDT Production deployment share.
4. Use the default settings for the Update Deployment Share Wizard.
-
5. After the update is complete, use the Windows Deployment Services console. In the **Boot Images** node, right-click the **MDT Production x64** boot image and select **Replace Image**.
@@ -141,20 +114,12 @@ When you have multiple deployment servers sharing the same content, you need to
Figure 5. Replacing the updated boot image in WDS.
6. Browse and select the **E:\\MDTProduction\\Boot\\LiteTouchPE\_x64.wim** boot image, and then complete Replace Boot Image Wizard using the default settings.
-
## Replicate the content
-
-
Once the MDT01 and MDT02 servers are prepared, you are ready to configure the actual replication.
-
### Create the replication group
-
1. On MDT01, using DFS Management, right-click **Replication**, and select **New Replication Group**.
-
2. On the **Replication Group Type** page, select **Multipurpose replication group**, and click **Next**.
-
3. On the **Name and Domain** page, assign the **MDTProduction** name, and click **Next**.
-
4. On the **Replication Group Members** page, click **Add**, add **MDT01** and **MDT02**, and then click **Next**.
@@ -162,15 +127,10 @@ Once the MDT01 and MDT02 servers are prepared, you are ready to configure the ac
Figure 6. Adding the Replication Group Members.
5. On the **Topology Selection** page, select the **Full mesh** option and click **Next**.
-
6. On the **Replication Group Schedule and Bandwidth** page, accept the default settings and click **Next**.
-
7. On the **Primary Member** page, select **MDT01** and click **Next**.
-
8. On the **Folders to Replicate** page, click **Add**, type in **E:\\MDTProduction** as the folder to replicate, click **OK**, and then click **Next**.
-
9. On the **Local Path of MDTProduction** on the **Other Members** page, select **MDT02**, and click **Edit**.
-
10. On the **Edit** page, select the **Enabled** option, type in **E:\\MDTProduction** as the local path of folder, select the **Make the selected replicated folder on this member read-only** check box, click **OK**, and then click **Next**.
@@ -178,23 +138,14 @@ Once the MDT01 and MDT02 servers are prepared, you are ready to configure the ac
Figure 7. Configure the MDT02 member.
11. On the **Review Settings and Create Replication Group** page, click **Create**.
-
12. On the **Confirmation** page, click **Close**.
-
### Configure replicated folders
-
1. On MDT01, using DFS Management, expand **Replication** and then select **MDTProduction**.
-
2. In the middle pane, right-click the **MDT01** member and select **Properties**.
-
3. On the **MDT01 (MDTProduction) Properties** page, configure the following and then click **OK**:
-
1. In the **Staging** tab, set the quota to **20480 MB**.
-
2. In the **Advanced** tab, set the quota to **8192 MB**.
-
In this scenario the size of the deployment share is known, but you might need to change the values for your environment. A good rule of thumb is to get the size of the 16 largest files and make sure they fit in the staging area. Here is a Windows PowerShell example that calculates the size of the 16 largest files in the E:\\MDTProduction deployment share:
-
``` syntax
(Get-ChildItem E:\MDTProduction -Recurse | Sort-Object Length -Descending | Select-Object -First 16 | Measure-Object -Property Length -Sum).Sum /1GB
```
@@ -204,34 +155,21 @@ Once the MDT01 and MDT02 servers are prepared, you are ready to configure the ac
Figure 8. Configure the Staging settings.
4. In the middle pane, right-click the **MDT02** member and select **Properties**.
-
5. On the **MDT02 (MDTProduction) Properties** page, configure the following and then click **OK**:
-
1. In the **Staging** tab, set the quota to **20480 MB**.
-
2. In the **Advanced** tab, set the quota to **8192 MB**.
**Note**
It will take some time for the replication configuration to be picked up by the replication members (MDT01 and MDT02). The time for the initial sync will depend on the WAN link speed between the sites. After that, delta changes are replicated quickly.
-
-
### Verify replication
-
1. On MDT02, wait until you start to see content appear in the **E:\\MDTProduction** folder.
-
2. Using DFS Management, expand **Replication**, right-click **MDTProduction**, and select **Create Diagnostics Report**.
-
3. In the Diagnostics Report Wizard, on the **Type of Diagnostics Report or Test** page, select **Health report** and click **Next**.
-
4. On the **Path and Name** page, accept the default settings and click **Next**.
-
5. On the **Members to Include** page, accept the default settings and click **Next**.
-
6. On the **Options** page, accept the default settings and click **Next**.
-
7. On the **Review Settings and Create Report** page, click **Create**.
-
8. Open the report in Internet Explorer, and if necessary, select the **Allow blocked content** option.
@@ -240,57 +178,37 @@ Figure 9. The DFS Replication Health Report.
## Configure Windows Deployment Services (WDS) in a remote site
-
Like you did in the previous topic for MDT01, you need to add the MDT Production Lite Touch x64 Boot image to Windows Deployment Services on MDT02. For the following steps, we assume that WDS has already been installed on MDT02.
-
1. On MDT02, using the WDS console, right-click **Boot Images** and select **Add Boot Image**.
-
2. Browse to the E:\\MDTProduction\\Boot\\LiteTouchPE\_x64.wim file and add the image with the default settings.
## Deploy the Windows 10 client to the remote site
-
Now you should have a solution ready for deploying the Windows 10 client to the remote site, Stockholm, connecting to the MDT Production deployment share replica on MDT02.
1. Create a virtual machine with the following settings:
-
1. Name: PC0006
-
2. Location: C:\\VMs
-
3. Generation: 2
-
4. Memory: 2048 MB
-
5. Hard disk: 60 GB (dynamic disk)
-
2. Start the PC0006 virtual machine, and press **Enter** to start the Pre-Boot Execution Environment (PXE) boot. The machine will now load the Windows PE boot image from the WDS server.
-
3. After Windows Preinstallation Environment (Windows PE) has booted, complete the Windows Deployment Wizard using the following settings:
-
1. Password: P@ssw0rd
-
2. Select a task sequence to execute on this computer:
-
1. Windows 10 Enterprise x64 RTM Custom Image
-
2. Computer Name: PC0006
-
3. Applications: Select the Install - Adobe Reader XI - x86 application
-
4. The setup will now start and do the following:
-
1. Install the Windows 10 Enterprise operating system.
-
2. Install the added application.
-
3. Update the operating system via your local Windows Server Update Services (WSUS) server.
## Related topics
-
[Get started with the Microsoft Deployment Toolkit (MDT)](get-started-with-the-microsoft-deployment-toolkit.md)
+
[Create a Windows 10 reference image](create-a-windows-10-reference-image.md)
[Deploy a Windows 10 image using MDT 2013 Update 2](deploy-a-windows-10-image-using-mdt.md)
@@ -300,12 +218,5 @@ Now you should have a solution ready for deploying the Windows 10 client to the
[Replace a Windows 7 computer with a Windows 10 computer](replace-a-windows-7-computer-with-a-windows-10-computer.md)
[Configure MDT settings](configure-mdt-2013-settings.md)
-
-
-
-
-
-
-
diff --git a/windows/deploy/configure-client-computers-vamt.md b/windows/deploy/configure-client-computers-vamt.md
index 0b64ceb406..b3618bac74 100644
--- a/windows/deploy/configure-client-computers-vamt.md
+++ b/windows/deploy/configure-client-computers-vamt.md
@@ -5,14 +5,15 @@ ms.assetid: a48176c9-b05c-4dd5-a9ef-83073e2370fc
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Configure Client Computers
+
To enable the Volume Activation Management Tool (VAMT) to function correctly, certain configuration changes are required on all client computers:
- An exception must be set in the client computer's firewall.
-
- A registry key must be created and set properly, for computers in a workgroup; otherwise, Windows® User Account Control (UAC) will not allow remote administrative operations.
Organizations where the VAMT will be widely used may benefit from making these changes inside the master image for Windows.
@@ -21,38 +22,29 @@ Organizations where the VAMT will be widely used may benefit from making these c
This procedure only applies to clients running Windows Vista or later. For clients running Windows XP Service Pack 1, see [Connecting Through Windows Firewall](http://go.microsoft.com/fwlink/p/?LinkId=182933).
## Configuring the Windows Firewall to allow VAMT access
+
Enable the VAMT to access client computers using the **Windows Firewall** Control Panel:
-
1. Open Control Panel and double-click **System and Security**.
-
2. Click **Windows Firewall**.
-
3. Click **Allow a program or feature through Windows Firewall**.
-
4. Click the **Change settings** option.
-
5. Select the **Windows Management Instrumentation (WMI)** checkbox.
-
6. Click **OK**.
**Warning**
By default, Windows Firewall Exceptions only apply to traffic originating on the local subnet. To expand the exception to apply to multiple subnets, you need to change the exception settings in the Windows Firewall with Advanced Security, as described below.
## Configure Windows Firewall to allow VAMT access across multiple subnets
+
Enable the VAMT to access client computers across multiple subnets using the **Windows Firewall with Advanced Security** Control Panel:
1. Open the Control Panel and double-click **Administrative Tools**.
-
2. Click **Windows Firewall with Advanced Security**.
-
3. Make your changes for each of the following three WMI items, for the applicable Network Profile (Domain, Public, Private):
-
- Windows Management Instrumentation (ASync-In)
-
- Windows Management Instrumentation (DCOM-In)
-
- Windows Management Instrumentation (WMI-In)
4. In the **Windows Firewall with Advanced Security** dialog box, select **Inbound Rules** from the left-hand panel.
@@ -60,55 +52,38 @@ Enable the VAMT to access client computers across multiple subnets using the **W
5. Right-click the desired rule and select **Properties** to open the **Properties** dialog box.
- On the **General** tab, select the **Allow the connection** checkbox.
-
- On the **Scope** tab, change the Remote IP Address setting from "Local Subnet" (default) to allow the specific access you need.
-
- On the **Advanced** tab, verify selection of all profiles that are applicable to the network (Domain or Private/Public).
In certain scenarios, only a limited set of TCP/IP ports are allowed through a hardware firewall. Administrators must ensure that WMI (which relies on RPC over TCP/IP) is allowed through these types of firewalls. By default, the WMI port is a dynamically allocated random port above 1024. The following Microsoft knowledge article discusses how administrators can limit the range of dynamically-allocated ports. This is useful if, for example, the hardware firewall only allows traffic in a certain range of ports.
-
For more info, see [How to configure RPC dynamic port allocation to work with firewalls](http://go.microsoft.com/fwlink/p/?LinkId=182911).
## Create a registry value for the VAMT to access workgroup-joined computer
+
**Caution**
This section contains information about how to modify the registry. Make sure to back up the registry before you modify it; in addition, ensure that you know how to restore the registry, if a problem occurs. For more information about how to back up, restore, and modify the registry, see [Windows registry information for advanced users](http://go.microsoft.com/fwlink/p/?LinkId=182912).
On the client computer, create the following registry key using regedit.exe.
1. Navigate to `HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system`
-
2. Enter the following details:
-
**Value Name: LocalAccountTokenFilterPolicy**
-
**Type: DWORD**
-
**Value Data: 1**
-
**Note**
To discover VAMT-manageable Windows computers in workgroups, you must enable network discovery on each client.
## Deployment options
+
There are several options for organizations to configure the WMI firewall exception for computers:
-
- **Image.** Add the configurations to the master Windows image deployed to all clients.
-
- **Group Policy.** If the clients are part of a domain, then all clients can be configured using Group Policy. The Group Policy setting for the WMI firewall exception is found in GPMC.MSC at: **Computer Configuration\\Windows Settings\\Security Settings\\Windows Firewall with Advanced Security\\Windows Firewall with Advanced Security\\Inbound Rules**.
-
- **Script.** Execute a script using Microsoft System Center Configuration Manager or a third-party remote script execution facility.
-
- **Manual.** Configure the WMI firewall exception individually on each client.
-
The above configurations will open an additional port through the Windows Firewall on target computers and should be performed on computers that are protected by a network firewall. In order to allow VAMT to query the up-to-date licensing status, the WMI exception must be maintained. We recommend administrators consult their network security policies and make clear decisions when creating the WMI exception.
## Related topics
+
- [Install and Configure VAMT](install-configure-vamt.md)
-
-
-
-
-
-
-
diff --git a/windows/deploy/configure-mdt-2013-for-userexit-scripts.md b/windows/deploy/configure-mdt-2013-for-userexit-scripts.md
index 69aaf853db..590f112414 100644
--- a/windows/deploy/configure-mdt-2013-for-userexit-scripts.md
+++ b/windows/deploy/configure-mdt-2013-for-userexit-scripts.md
@@ -2,21 +2,20 @@
title: Configure MDT for UserExit scripts (Windows 10)
description: In this topic, you will learn how to configure the MDT rules engine to use a UserExit script to generate computer names based on a prefix and the computer MAC Address.
ms.assetid: 29a421d1-12d2-414e-86dc-25b62f5238a7
-keywords: ["rules, script"]
+keywords: rules, script
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: mdt
author: mtniehaus
---
# Configure MDT for UserExit scripts
-
In this topic, you will learn how to configure the MDT rules engine to use a UserExit script to generate computer names based on a prefix and the computer MAC Address. MDT supports calling external VBScripts as part of the Gather process; these scripts are referred to as UserExit scripts. The script also removes the colons in the MAC Address.
## Configure the rules to call a UserExit script
-
You can call a UserExit by referencing the script in your rules. Then you can configure a property to be set to the result of a function of the VBScript. In this example, we have a VBScript named Setname.vbs (provided in the book sample files, in the UserExit folder).
``` syntax
@@ -32,7 +31,6 @@ The UserExit=Setname.vbs calls the script and then assigns the computer name to
## The Setname.vbs UserExit script
-
The Setname.vbs script takes the MAC Address passed from the rules. The script then does some string manipulation to add a prefix (PC) and remove the semicolons from the MAC Address.
``` syntax
@@ -48,17 +46,13 @@ Function SetName(sMac)
SetName = "PC" & re.Replace(sMac, "")
End Function
```
-
The first three lines of the script make up a header that all UserExit scripts have. The interesting part is the lines between Function and End Function. Those lines add a prefix (PC), remove the colons from the MAC Address, and return the value to the rules by setting the SetName value.
**Note**
The purpose of this sample is not to recommend that you use the MAC Address as a base for computer naming, but to show you how to take a variable from MDT, pass it to an external script, make some changes to it, and then return the new value to the deployment process.
-
-
## Related topics
-
[Set up MDT for BitLocker](set-up-mdt-2013-for-bitlocker.md)
[Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
@@ -72,12 +66,3 @@ The purpose of this sample is not to recommend that you use the MAC Address as a
[Use web services in MDT](use-web-services-in-mdt-2013.md)
[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt-2013.md)
-
-
-
-
-
-
-
-
-
diff --git a/windows/deploy/configure-mdt-2013-settings.md b/windows/deploy/configure-mdt-2013-settings.md
index 853cc6bf85..af41a8a1bb 100644
--- a/windows/deploy/configure-mdt-2013-settings.md
+++ b/windows/deploy/configure-mdt-2013-settings.md
@@ -2,18 +2,17 @@
title: Configure MDT settings (Windows 10)
description: One of the most powerful features in Microsoft Deployment Toolkit (MDT) 2013 is its extension capabilities; there is virtually no limitation to what you can do in terms of customization.
ms.assetid: d3e1280c-3d1b-4fad-8ac4-b65dc711f122
-keywords: ["customize, customization, deploy, features, tools"]
+keywords: customize, customization, deploy, features, tools
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: mdt
author: mtniehaus
---
# Configure MDT settings
-
One of the most powerful features in Microsoft Deployment Toolkit (MDT) 2013 is its extension capabilities; there is virtually no limitation to what you can do in terms of customization. In this topic, you learn about configuring customizations for your environment.
-
For the purposes of this topic, we will use four machines: DC01, MDT01, HV01, and PC0001. DC01 is a domain controller, MDT01 is a Windows Server 2012 R2 Standard server, and PC0001 is a Windows 10 Enterprise x64 client used for the MDT simulation environment. OR01 has Microsoft System Center 2012 R2 Orchestrator installed. MDT01, OR01, and PC0001 are members of the domain contoso.com for the fictitious Contoso Corporation. For more details on the setup for this topic, please see [Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-10-with-the-microsoft-deployment-toolkit.md#proof).
@@ -22,26 +21,17 @@ Figure 1. The machines used in this topic.
## In this section
-
- [Set up MDT for BitLocker](set-up-mdt-2013-for-bitlocker.md)
-
- [Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
-
- [Configure MDT for UserExit scripts](configure-mdt-2013-for-userexit-scripts.md)
-
- [Simulate a Windows 10 deployment in a test environment](simulate-a-windows-10-deployment-in-a-test-environment.md)
-
- [Use the MDT database to stage Windows 10 deployment information](use-the-mdt-database-to-stage-windows-10-deployment-information.md)
-
- [Assign applications using roles in MDT](assign-applications-using-roles-in-mdt-2013.md)
-
- [Use web services in MDT](use-web-services-in-mdt-2013.md)
-
- [Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt-2013.md)
## Related topics
-
[Get started with the Microsoft Deployment Toolkit (MDT)](get-started-with-the-microsoft-deployment-toolkit.md)
[Create a Windows 10 reference image](create-a-windows-10-reference-image.md)
@@ -53,12 +43,3 @@ Figure 1. The machines used in this topic.
[Refresh a Windows 7 computer with Windows 10](refresh-a-windows-7-computer-with-windows-10.md)
[Replace a Windows 7 computer with a Windows 10 computer](replace-a-windows-7-computer-with-a-windows-10-computer.md)
-
-
-
-
-
-
-
-
-
diff --git a/windows/deploy/configure-mdt-deployment-share-rules.md b/windows/deploy/configure-mdt-deployment-share-rules.md
index a600557e1a..908f92144b 100644
--- a/windows/deploy/configure-mdt-deployment-share-rules.md
+++ b/windows/deploy/configure-mdt-deployment-share-rules.md
@@ -2,34 +2,29 @@
title: Configure MDT deployment share rules (Windows 10)
description: In this topic, you will learn how to configure the MDT rules engine to reach out to other resources, including external scripts, databases, and web services, for additional information instead of storing settings directly in the rules engine.
ms.assetid: b5ce2360-33cc-4b14-b291-16f75797391b
-keywords: ["rules, configuration, automate, deploy"]
+keywords: rules, configuration, automate, deploy
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: mdt
author: mtniehaus
---
# Configure MDT deployment share rules
-
In this topic, you will learn how to configure the MDT rules engine to reach out to other resources, including external scripts, databases, and web services, for additional information instead of storing settings directly in the rules engine. The rules engine in MDT is powerful: most of the settings used for operating system deployments are retrieved and assigned via the rules engine. In its simplest form, the rules engine is the CustomSettings.ini text file.
## Assign settings
-
When using MDT, you can assign setting in three distinct ways:
-
- You can pre-stage the information before deployment.
-
- You can prompt the user or technician for information.
-
- You can have MDT generate the settings automatically.
In order illustrate these three options, let's look at some sample configurations.
## Sample configurations
-
Before adding the more advanced components like scripts, databases, and web services, consider the commonly used configurations below; they demonstrate the power of the rules engine.
### Set computer name by MAC Address
@@ -75,12 +70,10 @@ OSDComputerName=PC-%SerialNumber%
```
In this sample, you configure the rules to set the computer name to a prefix (PC-) and then the serial number. If the serial number of the machine is CND0370RJ7, the preceding configuration sets the computer name to PC-CND0370RJ7.
-
**Note**
+
Be careful when using the serial number to assign computer names. A serial number can contain more than 15 characters, but the Windows setup limits a computer name to 15 characters.
-
-
### Generate a limited computer name based on a serial number
To avoid assigning a computer name longer than 15 characters, you can configure the rules in more detail by adding VBScript functions, as follows:
@@ -112,7 +105,6 @@ MachineObjectOU=OU=Laptops,OU=Contoso,DC=contoso,DC=com
## Related topics
-
[Set up MDT for BitLocker](set-up-mdt-2013-for-bitlocker.md)
[Configure MDT for UserExit scripts](configure-mdt-2013-for-userexit-scripts.md)
@@ -126,12 +118,3 @@ MachineObjectOU=OU=Laptops,OU=Contoso,DC=contoso,DC=com
[Use web services in MDT](use-web-services-in-mdt-2013.md)
[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt-2013.md)
-
-
-
-
-
-
-
-
-
diff --git a/windows/deploy/create-a-windows-10-reference-image.md b/windows/deploy/create-a-windows-10-reference-image.md
index f501072a3f..f81f4eac9a 100644
--- a/windows/deploy/create-a-windows-10-reference-image.md
+++ b/windows/deploy/create-a-windows-10-reference-image.md
@@ -2,67 +2,50 @@
title: Create a Windows 10 reference image (Windows 10)
description: Creating a reference image is important because that image serves as the foundation for the devices in your organization.
ms.assetid: 9da2fb57-f2ff-4fce-a858-4ae4c237b5aa
-keywords: ["deploy, deployment, configure, customize, install, installation"]
+keywords: deploy, deployment, configure, customize, install, installation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: mdt
author: mtniehaus
---
# Create a Windows 10 reference image
-
**Applies to**
-
- Windows 10
Creating a reference image is important because that image serves as the foundation for the devices in your organization. In this topic, you will learn how to create a Windows 10 reference image using the Microsoft Deployment Toolkit (MDT) 2013 Update 2. You will create a deployment share, configure rules and settings, and import all the applications and operating system files required to build a Windows 10 reference image. After completing the steps outlined in this topic, you will have a Windows 10 reference image that can be used in your deployment solution.
-
For the purposes of this topic, we will use four machines: DC01, MDT01, HV01, and PC0001. DC01 is a domain controller, PC0001 is a Windows 10 Enterprise x64 client, and MDT01 is a Windows Server 2012 R2 standard server. HV01 is a Hyper-V host server, but HV01 could be replaced by PC0001 as long as PC0001 has enough memory and is capable of running Hyper-V. MDT01, HV01, and PC0001 are members of the domain contoso.com for the fictitious Contoso Corporation.
**Note**
For important details about the setup for the steps outlined in this article, please see [Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-10-with-the-microsoft-deployment-toolkit.md#proof).
-
-
Figure 1. The machines used in this topic.
## The reference image
-
The reference image described in this documentation is designed primarily for deployment to physical machines. However, the reference image is created on a virtual platform, before being automatically run through the System Preparation (Sysprep) tool process and captured to a Windows Imaging (WIM) file. The reasons for creating the reference image on a virtual platform are the following:
-
- You reduce development time and can use snapshots to test different configurations quickly.
-
- You rule out hardware issues. You simply get the best possible image, and if you have a problem, it's not likely to be hardware related.
-
- It ensures that you won't have unwanted applications that could be installed as part of a driver install but not removed by the Sysprep process.
-
- It's easy to move between lab, test, and production.
## Set up the MDT build lab deployment share
-
With Windows 10, there is no hard requirement to create reference images; however, to reduce the time needed for deployment, you may want to create a reference image that contains a few base applications as well as all of the latest updates. This section will show you how to create and configure the MDT Build Lab deployment share to create a Windows 10 reference image. Because reference images will be deployed only to virtual machines during the creation process and have specific settings (rules), you should always create a separate deployment share specifically for this process.
### Create the MDT build lab deployment share
- On MDT01, log on as Administrator in the CONTOSO domain using a password of **P@ssw0rd**.
-
- Using the Deployment Workbench, right-click **Deployment Shares** and select **New Deployment Share**.
-
- Use the following settings for the New Deployment Share Wizard:
-
- Deployment share path: E:\\MDTBuildLab
-
- Share name: MDTBuildLab$
-
- Deployment share description: MDT Build Lab
-
- <default>
-
- Verify that you can access the \\\\MDT01\\MDTBuildLab$ share.
@@ -72,9 +55,7 @@ Figure 2. The Deployment Workbench with the MDT Build Lab deployment share creat
### Configure permissions for the deployment share
In order to write the reference image back to the deployment share, you need to assign Modify permissions to the MDT Build Account (MDT\_BA) for the **Captures** subfolder in the **E:\\MDTBuildLab** folder
-
1. On MDT01, log on as **CONTOSO\\Administrator**.
-
2. Modify the NTFS permissions for the **E:\\MDTBuildLab\\Captures** folder by running the following command in an elevated Windows PowerShell prompt:
``` syntax
@@ -87,7 +68,6 @@ Figure 3. Permissions configured for the MDT\_BA user.
## Add the setup files
-
This section will show you how to populate the MDT 2013 Update 2 deployment share with the Windows 10 operating system source files, commonly referred to as setup files, which will be used to create a reference image. Setup files are used during the reference image creation process and are the foundation for the reference image.
### Add the Windows 10 installation files
@@ -96,27 +76,18 @@ MDT 2013 supports adding both full source Windows 10 DVDs (ISOs) and custom ima
**Note**
Due to the Windows limits on path length, we are purposely keeping the operating system destination directory short, using the folder name W10EX64RTM rather than a more descriptive name like Windows 10 Enterprise x64 RTM.
-
-
### Add Windows 10 Enterprise x64 (full source)
In these steps we assume that you have copied the content of a Windows 10 Enterprise x64 ISO to the **E:\\Downloads\\Windows 10 Enterprise x64** folder.
1. On MDT01, log on as **CONTOSO\\Administrator**.
-
2. Using the Deployment Workbench, expand the **Deployment Shares** node, and then expand **MDT Build Lab**.
-
3. Right-click the **Operating Systems** node, and create a new folder named **Windows 10**.
-
4. Expand the **Operating Systems** node, right-click the **Windows 10** folder, and select **Import Operating System**. Use the following settings for the Import Operating System Wizard:
-
5. Full set of source files
-
6. Source directory: E:\\Downloads\\Windows 10 Enterprise x64
-
7. Destination directory name: W10EX64RTM
-
8. After adding the operating system, in the **Operating Systems / Windows 10** folder, double-click the added operating system name in the **Operating System** node and change the name to the following: **Windows 10 Enterprise x64 RTM Default Image**
@@ -125,40 +96,27 @@ Figure 4. The imported Windows 10 operating system after renaming it.
## Add applications
-
Before you create an MDT task sequence, you need to add all of the applications and other sample scripts to the MDT Build Lab share.
The steps in this section use a strict naming standard for your MDT applications. You add the "Install - " prefix for typical application installations that run a setup installer of some kind, and you use the "Configure - " prefix when an application configures a setting in the operating system. You also add an " - x86", " - x64", or "- x86-x64" suffix to indicate the application's architecture (some applications have installers for both architectures). Using a script naming standard is always recommended when using MDT as it helps maintain order and consistency.
-
By storing configuration items as MDT applications, it is easy to move these objects between various solutions, or between test and production environments. In this topic's step-by-step sections, you will add the following applications:
- Install - Microsoft Office 2013 Pro Plus - x86
-
- Install - Microsoft Silverlight 5.0 - x64
-
- Install - Microsoft Visual C++ 2005 SP1 - x86
-
- Install - Microsoft Visual C++ 2005 SP1 - x64
-
- Install - Microsoft Visual C++ 2008 SP1 - x86
-
- Install - Microsoft Visual C++ 2008 SP1 - x64
-
- Install - Microsoft Visual C++ 2010 SP1 - x86
-
- Install - Microsoft Visual C++ 2010 SP1 - x64
-
- Install - Microsoft Visual C++ 2012 Update 4 - x86
-
- Install - Microsoft Visual C++ 2012 Update 4 - x64
In these examples, we assume that you downloaded the software in this list to the E:\\Downloads folder. The first application is added using the UI, but because MDT supports Windows PowerShell, you add the other applications using Windows PowerShell.
**Note**
All the Microsoft Visual C++ downloads can be found on [The latest supported Visual C++ downloads](http://go.microsoft.com/fwlink/p/?LinkId=619523).
-
-
### Create the install: Microsoft Office Professional Plus 2013 x86
You can customize Office 2013. In the volume license versions of Office 2013, there is an Office Customization Tool you can use to customize the Office installation. In these steps we assume you have copied the Office 2013 installation files to the E:\\Downloads\\Office2013 folder.
@@ -166,11 +124,8 @@ You can customize Office 2013. In the volume license versions of Office 2013, th
### Add the Microsoft Office Professional Plus 2013 x86 installation files
After adding the Microsoft Office Professional Plus 2013 x86 application, you then automate its setup by running the Office Customization Tool. In fact, MDT 2013 detects that you added the Office Professional Plus 2013 x86 application and creates a shortcut for doing this.
-
You also can customize the Office installation using a Config.xml file. But we recommend that you use the Office Customization Tool as described in the following steps, as it provides a much richer way of controlling Office 2013 settings.
-
1. Using the Deployment Workbench in the MDT Build Lab deployment share, expand the **Applications / Microsoft** node, and double-click **Install - Microsoft Office 2013 Pro Plus x86**.
-
2. In the **Office Products** tab, click **Office Customization Tool**, and click **OK** in the **Information** dialog box.
@@ -179,23 +134,14 @@ You also can customize the Office installation using a Config.xml file. But we r
**Note**
If you don't see the Office Products tab, verify that you are using a volume license version of Office. If you are deploying Office 365, you need to download the Admin folder from Microsoft.
-
-
3. In the Office Customization Tool dialog box, select the Create a new Setup customization file for the following product option, select the Microsoft Office Professional Plus 2013 (32-bit) product, and click OK.
-
4. Use the following settings to configure the Office 2013 setup to be fully unattended:
-
1. Install location and organization name
-
- Organization name: Contoso
-
2. Licensing and user interface
-
1. Select Use KMS client key
-
2. Select I accept the terms in the License Agreement.
-
3. Select Display level: None
@@ -203,44 +149,31 @@ You also can customize the Office installation using a Config.xml file. But we r
Figure 6. The licensing and user interface screen in the Microsoft Office Customization Tool
3. Modify Setup properties
-
- Add the **SETUP\_REBOOT** property and set the value to **Never**.
-
4. Modify user settings
-
- In the **Microsoft Office 2013** node, expand **Privacy**, select **Trust Center**, and enable the Disable Opt-in Wizard on first run setting.
-
5. From the **File** menu, select **Save**, and save the configuration as 0\_Office2013ProPlusx86.msp in the **E:\\MDTBuildLab\\Applications\\Install - Microsoft Office 2013 Pro Plus - x86\\Updates** folder.
**Note**
The reason for naming the file with a 0 (zero) at the beginning is that the Updates folder also handles Microsoft Office updates, and they are installed in alphabetical order. The Office 2013 setup works best if the customization file is installed before any updates.
-
-
6. Close the Office Customization Tool, click Yes in the dialog box, and in the **Install - Microsoft Office 2013 Pro Plus - x86 Properties** window, click **OK**.
### Connect to the deployment share using Windows PowerShell
If you need to add many applications, you can take advantage of the PowerShell support that MDT has. To start using PowerShell against the deployment share, you must first load the MDT PowerShell snap-in and then make the deployment share a PowerShell drive (PSDrive).
-
1. On MDT01, log on as **CONTOSO\\Administrator**.
-
2. Import the snap-in and create the PSDrive by running the following commands in an elevated PowerShell prompt:
-
``` syntax
Import-Topic "C:\Program Files\Microsoft Deployment Toolkit\bin\MicrosoftDeploymentToolkit.psd1"
-
New-PSDrive -Name "DS001" -PSProvider MDTProvider -Root "E:\MDTBuildLab"
```
### Create the install: Microsoft Visual C++ 2005 SP1 x86
In these steps we assume that you have downloaded Microsoft Visual C++ 2005 SP1 x86. You might need to modify the path to the source folder to reflect your current environment. In this example, the source path is set to E:\\Downloads\\VC++2005SP1x86.
-
1. On MDT01, log on as **CONTOSO\\Administrator**.
-
2. Create the application by running the following commands in an elevated PowerShell prompt:
-
``` syntax
$ApplicationName = "Install - Microsoft Visual C++ 2005 SP1 - x86"
$CommandLine = "vcredist_x86.exe /Q"
@@ -252,11 +185,8 @@ In these steps we assume that you have downloaded Microsoft Visual C++ 2005 SP1
### Create the install: Microsoft Visual C++ 2005 SP1 x64
In these steps we assume that you have downloaded Microsoft Visual C++ 2005 SP1 x64. You might need to modify the path to the source folder to reflect your current environment. In this example, the source path is set to E:\\Downloads\\VC++2005SP1x64.
-
1. On MDT01, log on as **CONTOSO\\Administrator**.
-
2. Create the application by running the following commands in an elevated PowerShell prompt:
-
``` syntax
$ApplicationName = "Install - Microsoft Visual C++ 2005 SP1 - x64"
$CommandLine = "vcredist_x64.exe /Q"
@@ -268,11 +198,8 @@ In these steps we assume that you have downloaded Microsoft Visual C++ 2005 SP1
### Create the install: Microsoft Visual C++ 2008 SP1 x86
In these steps we assume that you have downloaded Microsoft Visual C++ 2008 SP1 x86. You might need to modify the path to the source folder to reflect your current environment. In this example, the source path is set to E:\\Downloads\\VC++2008SP1x86.
-
1. On MDT01, log on as **CONTOSO\\Administrator**.
-
2. Create the application by running the following commands in an elevated PowerShell prompt:
-
``` syntax
$ApplicationName = "Install - Microsoft Visual C++ 2008 SP1 - x86"
$CommandLine = "vcredist_x86.exe /Q"
@@ -284,11 +211,8 @@ In these steps we assume that you have downloaded Microsoft Visual C++ 2008 SP1
### Create the install: Microsoft Visual C++ 2008 SP1 x64
In these steps we assume that you have downloaded Microsoft Visual C++ 2008 SP1 x64. You might need to modify the path to the source folder to reflect your current environment. In this example, the source path is set to E:\\Downloads\\VC++2008SP1x64.
-
1. On MDT01, log on as **CONTOSO\\Administrator**.
-
2. Create the application by running the following commands in an elevated PowerShell prompt:
-
``` syntax
$ApplicationName = "Install - Microsoft Visual C++ 2008 SP1 - x64"
$CommandLine = "vcredist_x64.exe /Q"
@@ -300,11 +224,8 @@ In these steps we assume that you have downloaded Microsoft Visual C++ 2008 SP1
### Create the install: Microsoft Visual C++ 2010 SP1 x86
In these steps we assume that you have downloaded Microsoft Visual C++ 2010 SP1 x86. You might need to modify the path to the source folder to reflect your current environment. In this example, the source path is set to E:\\Downloads\\VC++2010SP1x86.
-
1. On MDT01, log on as **CONTOSO\\Administrator**.
-
2. Create the application by running the following commands in an elevated PowerShell prompt:
-
``` syntax
$ApplicationName = "Install - Microsoft Visual C++ 2010 SP1 - x86"
$CommandLine = "vcredist_x86.exe /Q"
@@ -316,11 +237,8 @@ In these steps we assume that you have downloaded Microsoft Visual C++ 2010 SP1
### Create the install: Microsoft Visual C++ 2010 SP1 x64
In these steps we assume that you have downloaded Microsoft Visual C++ 2010 SP1 x64. You might need to modify the path to the source folder to reflect your current environment. In this example, the source path is set to E:\\Downloads\\VC++2010SP1x64.
-
1. On MDT01, log on as **CONTOSO\\Administrator**.
-
2. Create the application by running the following commands in an elevated PowerShell prompt:
-
``` syntax
$ApplicationName = "Install - Microsoft Visual C++ 2010 SP1 - x64"
$CommandLine = "vcredist_x64.exe /Q"
@@ -332,11 +250,8 @@ In these steps we assume that you have downloaded Microsoft Visual C++ 2010 SP1
### Create the install: Microsoft Visual C++ 2012 Update 4 x86
In these steps we assume that you have downloaded Microsoft Visual C++ 2012 Update 4 x86. You might need to modify the path to the source folder to reflect your current environment. In this example, the source path is set to E:\\Downloads\\VC++2012Ux86.
-
1. On MDT01, log on as **CONTOSO\\Administrator**.
-
2. Create the application by running the following commands in an elevated PowerShell prompt:
-
``` syntax
$ApplicationName = "Install - Microsoft Visual C++ 2012 Update 4 - x86"
$CommandLine = "vcredist_x86.exe /Q"
@@ -348,11 +263,8 @@ In these steps we assume that you have downloaded Microsoft Visual C++ 2012 Upda
### Create the install: Microsoft Visual C++ 2012 Update 4 x64
In these steps we assume that you have downloaded Microsoft Visual C++ 2012 Update 4 x64. You might need to modify the path to the source folder to reflect your current environment. In this example, the source path is set to E:\\Downloads\\VC++2012Ux64.
-
1. On MDT01, log on as **CONTOSO\\Administrator**.
-
2. Create the application by running the following commands in an elevated PowerShell prompt:
-
``` syntax
$ApplicationName = "Install - Microsoft Visual C++ 2012 Update 4 - x64"
$CommandLine = "vcredist_x64.exe /Q"
@@ -363,9 +275,7 @@ In these steps we assume that you have downloaded Microsoft Visual C++ 2012 Upda
## Create the reference image task sequence
-
In order to build and capture your Windows 10 reference image for deployment using MDT, you will create a task sequence. The task sequence will reference the operating system and applications that you previously imported into the MDT Build Lab deployment share to build a Windows 10 reference image.
-
After creating the task sequence, you configure it to enable patching against the Windows Server Update Services (WSUS) server. The Task Sequence Windows Update action supports getting updates directly from Microsoft Update, but you get more stable patching if you use a local WSUS server. WSUS also allows for an easy process of approving the patches that you are deploying.
### Drivers and the reference image
@@ -377,27 +287,16 @@ Because we use modern virtual platforms for creating our reference images, we do
To create a Windows 10 reference image task sequence, the process is as follows:
1. Using the Deployment Workbench in the MDT Build Lab deployment share, right-click **Task Sequences**, and create a new folder named **Windows 10**.
-
2. Expand the **Task Sequences** node, right-click the new **Windows 10** folder and select **New Task Sequence**. Use the following settings for the New Task Sequence Wizard:
-
1. Task sequence ID: REFW10X64-001
-
2. Task sequence name: Windows 10 Enterprise x64 RTM Default Image
-
3. Task sequence comments: Reference Build
-
4. Template: Standard Client Task Sequence
-
5. Select OS: Windows 10 Enterprise x64 RTM Default Image
-
6. Specify Product Key: Do not specify a product key at this time
-
7. Full Name: Contoso
-
8. Organization: Contoso
-
9. Internet Explorer home page: http://www.contoso.com
-
10. Admin Password: Do not specify an Administrator Password at this time
### Edit the Windows 10 task sequence
@@ -405,74 +304,46 @@ To create a Windows 10 reference image task sequence, the process is as follows
The steps below walk you through the process of editing the Windows 10 reference image task sequence to include the actions required to update the reference image with the latest updates from WSUS, install roles and features, and utilities, and install Microsoft Office 2013.
1. In the Task Sequences / Windows 10 folder, right-click the Windows 10 Enterprise x64 RTM Default Image task sequence, and select Properties.
-
2. On the **Task Sequence** tab, configure the Windows 10 Enterprise x64 RTM Default Image task sequence with the following settings:
-
1. State Restore. Enable the Windows Update (Pre-Application Installation) action.
-
**Note**
Enable an action by going to the Options tab and clearing the Disable this step check box.
-
-
2. State Restore. Enable the Windows Update (Post-Application Installation) action.
-
3. State Restore. Enable the Windows Update (Post-Application Installation) action. State Restore. After the **Tattoo** action, add a new **Group** action with the following setting:
-
- Name: Custom Tasks (Pre-Windows Update)
-
4. State Restore. After Windows Update (Post-Application Installation) action, rename Custom Tasks to Custom Tasks (Post-Windows Update).
-
**Note**
The reason for adding the applications after the Tattoo action but before running Windows Update is simply to save time during the deployment. This way we can add all applications that will upgrade some of the built-in components and avoid unnecessary updating.
-
-
5. State Restore / Custom Tasks (Pre-Windows Update). Add a new Install Roles and Features action with the following settings:
-
1. Name: Install - Microsoft NET Framework 3.5.1
-
2. Select the operating system for which roles are to be installed: Windows 8.1
-
3. Select the roles and features that should be installed: .NET Framework 3.5 (includes .NET 2.0 and 3.0)
-
+
**Important**
This is probably the most important step when creating a reference image. Many applications need the .NET Framework, and we strongly recommend having it available in the image. The one thing that makes this different from other components is that .NET Framework 3.5.1 is not included in the WIM file. It is installed from the **Sources\\SxS** folder on the media, and that makes it more difficult to add after the image has been deployed.
-
-
Figure 7. The task sequence after creating the Custom Tasks (Pre-Windows Update) group and adding the Install - Microsoft NET Framework 3.5.1 action.
6. State Restore - Custom Tasks (Pre-Windows Update). After the **Install - Microsoft NET Framework 3.5.1** action, add a new **Install Application** action with the following settings:
-
1. Name: Install - Microsoft Visual C++ 2005 SP1 - x86
-
2. Install a Single Application: Install - Microsoft Visual C++ 2005 SP1 - x86-x64
-
7. Repeat the previous step (add a new **Install Application**) to add the following applications:
-
1. Install - Microsoft Visual C++ 2005 SP1 - x64
-
2. Install - Microsoft Visual C++ 2008 SP1 - x86
-
3. Install - Microsoft Visual C++ 2008 SP1 - x64
-
4. Install - Microsoft Visual C++ 2010 SP1 - x86
-
5. Install - Microsoft Visual C++ 2010 SP1 - x64
-
6. Install - Microsoft Visual C++ 2012 Update 4 - x86
-
7. Install - Microsoft Visual C++ 2012 Update 4 - x64
-
8. Install - Microsoft Office 2013 Pro Plus - x86
-
8. After the Install - Microsoft Office 2013 Pro Plus - x86 action, add a new Restart computer action.
-
3. Click **OK**.
+
### Optional configuration: Add a suspend action
The goal when creating a reference image is of course to automate everything. But sometimes you have a special configuration or application setup that is too time-consuming to automate. If you need to do some manual configuration, you can add a little-known feature called Lite Touch Installation (LTI) Suspend. If you add the LTISuspend.wsf script as a custom action in the task sequence, it will suspend the task sequence until you click the Resume Task Sequence shortcut icon on the desktop. In addition to using the LTI Suspend feature for manual configuration or installation, you can also use it simply for verifying a reference image before you allow the task sequence to continue and use Sysprep and capture the virtual machine.
@@ -491,23 +362,15 @@ When using MDT, you don't need to edit the Unattend.xml file very often because
**Note**
You also can use the Unattend.xml to enable components in Windows 10, like the Telnet Client or Hyper-V client. Normally we prefer to do this via the Install Roles and Features action, or using Deployment Image Servicing and Management (DISM) command-line tools, because then we can add that as an application, being dynamic, having conditions, and so forth. Also, if you are adding packages via Unattend.xml, it is version specific, so Unattend.xml must match the exact version of the operating system you are servicing.
-
-
Follow these steps to configure Internet Explorer settings in Unattend.xml for the Windows 10 Enterprise x64 RTM Default Image task sequence:
1. Using the Deployment Workbench, right-click the **Windows 10 Enterprise x64 RTM Default Image** task sequence and select **Properties**.
-
2. In the **OS Info** tab, click **Edit Unattend.xml**. MDT now generates a catalog file. This will take a few minutes, and then Windows System Image Manager (Windows SIM) will start.
-
3. In Windows SIM, expand the **4 specialize** node in the **Answer File** pane and select the amd64\_Microsoft-Windows-IE-InternetExplorer\_neutral entry.
-
4. In the **amd64\_Microsoft-Windows-IE-InternetExplorer\_neutral properties** window (right-hand window), set the following values:
-
- DisableDevTools: true
-
5. Save the Unattend.xml file, and close Windows SIM.
-
6. On the Windows 10 Enterprise x64 RTM Default Image Properties, click **OK**.
@@ -516,19 +379,14 @@ Figure 10. Windows System Image Manager with the Windows 10 Unattend.xml.
## Configure the MDT deployment share rules
-
Understanding rules is critical to successfully using MDT. Rules are configured using the Rules tab of the deployment share's properties. The Rules tab is essentially a shortcut to edit the CustomSettings.ini file that exists in the E:\\MDTBuildLab\\Control folder. This section discusses how to configure the MDT deployment share rules as part of your Windows 10 Enterprise deployment.
### MDT deployment share rules overview
In MDT, there are always two rule files: the CustomSettings.ini file and the Bootstrap.ini file. You can add almost any rule to either; however, the Bootstrap.ini file is copied from the Control folder to the boot image, so the boot image needs to be updated every time you change that file.
-
For that reason, add only a minimal set of rules to Bootstrap.ini, such as which deployment server and share to connect to - the DEPLOYROOT value. Put the other rules in CustomSettings.ini because that file is updated immediately when you click OK. By taking the following steps, you will configure the rules for the MDT Build Lab deployment share:
-
1. Using the Deployment Workbench, right-click the **MDT Build Lab deployment share** and select **Properties**.
-
2. Select the **Rules** tab and modify using the following information:
-
``` syntax
[Settings]
Priority=Default
@@ -585,30 +443,19 @@ For that reason, add only a minimal set of rules to Bootstrap.ini, such as which
**Note**
For security reasons, you normally don't add the password to the Bootstrap.ini file; however, because this deployment share is for creating reference image builds only, and should not be published to the production network, it is acceptable to do so in this situation.
-
-
4. In the **Windows PE** tab, in the **Platform** drop-down list, select **x86**.
-
5. In the **Lite Touch Boot Image Settings** area, configure the following settings:
-
1. Image description: MDT Build Lab x86
-
2. ISO file name: MDT Build Lab x86.iso
-
6. In the **Windows PE** tab, in the **Platform** drop-down list, select **x64**.
-
7. In the **Lite Touch Boot Image Settings** area, configure the following settings:
-
1. Image description: MDT Build Lab x64
-
2. ISO file name: MDT Build Lab x64.iso
-
8. Click **OK**.
**Note**
In MDT, the x86 boot image can deploy both x86 and x64 operating systems (except on computers based on Unified Extensible Firmware Interface).
-
### Update the deployment share
@@ -616,14 +463,11 @@ In MDT, the x86 boot image can deploy both x86 and x64 operating systems (except
After the deployment share has been configured, it needs to be updated. This is the process when the Windows Windows PE boot images are created.
1. Using the Deployment Workbench, right-click the **MDT Build Lab deployment share** and select **Update Deployment Share**.
-
2. Use the default options for the Update Deployment Share Wizard.
**Note**
The update process will take 5 to 10 minutes.
-
-
### The rules explained
Now that the MDT Build Lab deployment share (the share used to create the reference images) has been configured, it is time to explain the various settings used in the Bootstrap.ini and CustomSettings.ini files.
@@ -634,9 +478,7 @@ The CustomSettings.ini file is normally stored on the server, in the Deployment
**Note**
The settings, or properties, that are used in the rules (CustomSettings.ini and Bootstrap.ini) are listed in the MDT documentation, in the Microsoft Deployment Toolkit Reference / Properties / Property Definition section.
-
-
### The Bootstrap.ini file
The Bootstrap.ini file is available via the deployment share's Properties dialog box, or via the E:\\MDTBuildLab\\Control folder on MDT01.
@@ -644,36 +486,27 @@ The Bootstrap.ini file is available via the deployment share's Properties dialog
``` syntax
[Settings]
Priority=Default
-
[Default]
DeployRoot=\\MDT01\MDTBuildLab$
UserDomain=CONTOSO
UserID=MDT_BA
UserPassword=P@ssw0rd
-
SkipBDDWelcome=YES
```
So, what are these settings?
-
- **Priority.** This determines the order in which different sections are read. This Bootstrap.ini has only one section, named \[Default\].
-
- **DeployRoot.** This is the location of the deployment share. Normally, this value is set by MDT, but you need to update the DeployRoot value if you move to another server or other share. If you don't specify a value, the Windows Deployment Wizard prompts you for a location.
-
- **UserDomain, UserID, and UserPassword.** These values are used for automatic log on to the deployment share. Again, if they are not specified, the wizard prompts you.
**Note**
Caution is advised. These values are stored in clear text on the boot image. Use them only for the MDT Build Lab deployment share and not for the MDT Production deployment share that you learn to create in the next topic.
-
-
- **SkipBDDWelcome.** Even if it is nice to be welcomed every time we start a deployment, we prefer to skip the initial welcome page of the Windows Deployment Wizard.
**Note**
All properties beginning with "Skip" control only whether to display that pane in the Windows Deployment Wizard. Most of the panes also require you to actually set one or more values.
-
-
### The CustomSettings.ini file
The CustomSettings.ini file, whose content you see on the Rules tab of the deployment share Properties dialog box, contains most of the properties used in the configuration.
@@ -710,109 +543,64 @@ SkipRoles=YES
SkipCapture=NO
SkipFinalSummary=YES
```
-
- **Priority.** Has the same function as in Bootstrap.ini. Priority determines the order in which different sections are read. This CustomSettings.ini has only one section, named \[Default\]. In general, if you have multiple sections that set the same value, the value from the first section (higher priority) wins. The rare exceptions are listed in the ZTIGather.xml file.
-
- **\_SMSTSORGNAME.** The organization name displayed in the task sequence progress bar window during deployment.
-
- **UserDataLocation.** Controls the settings for user state backup. You do not need to use when building and capturing a reference image.
-
- **DoCapture.** Configures the task sequence to run the System Preparation (Sysprep) tool and capture the image to a file when the operating system is installed.
-
- **OSInstall.** Must be set to Y or YES (the code actually just looks for the Y character) for the setup to proceed.
-
- **AdminPassword.** Sets the local Administrator account password.
-
- **TimeZoneName.** Establishes the time zone to use. Don't confuse this value with TimeZone, which is only for legacy operating systems (Windows 7 and Windows Server 2003).
**Note**
The easiest way to find the current time zone name on a Windows 10 machine is to run tzutil /g in a command prompt. You can also run tzutil /l to get a listing of all available time zone names.
-
-
- **JoinWorkgroup.** Configures Windows to join a workgroup.
-
- **HideShell.** Hides the Windows Shell during deployment. This is especially useful for Windows 8.1 deployments in which the deployment wizard will otherwise appear behind the tiles.
-
- **FinishAction.** Instructs MDT what to do when the task sequence is complete.
-
- **DoNotCreateExtraPartition.** Configures the task sequence not to create the extra partition for BitLocker. There is no need to do this for your reference image.
-
- **WSUSServer.** Specifies which Windows Server Update Services (WSUS) server (and port, if needed) to use during the deployment. Without this option MDT will use Microsoft Update directly, which will increase deployment time and limit your options of controlling which updates are applied.
-
- **SLSHARE.** Instructs MDT to copy the log files to a server share if something goes wrong during deployment, or when a deployment is successfully completed.
-
- **ApplyGPOPack.** Allows you to deploy local group policies created by Microsoft Security Compliance Manager (SCM).
-
- **SkipAdminPassword.** Skips the pane that asks for the Administrator password.
-
- **SkipProductKey.** Skips the pane that asks for the product key.
-
- **SkipComputerName.** Skips the Computer Name pane.
-
- **SkipDomainMemberShip.** Skips the Domain Membership pane. If set to Yes, you need to configure either the JoinWorkgroup value or the JoinDomain, DomainAdmin, DomainAdminDomain, and DomainAdminPassword properties.
-
- **SkipUserData.** Skips the pane for user state migration.
-
- **SkipLocaleSelection.** Skips the pane for selecting language and keyboard settings.
-
- **SkipTimeZone.** Skips the pane for setting the time zone.
-
- **SkipApplications.** Skips the Applications pane.
-
- **SkipBitLocker.** Skips the BitLocker pane.
-
- **SkipSummary.** Skips the initial Windows Deployment Wizard summary pane.
-
- **SkipRoles.** Skips the Install Roles and Features pane.
-
- **SkipCapture.** Skips the Capture pane.
-
- **SkipFinalSummary.** Skips the final Windows Deployment Wizard summary. Because you use FinishAction=Shutdown, you don't want the wizard to stop in the end so that you need to click OK before the machine shuts down.
## Build the Windows 10 reference image
-
Once you have created your task sequence, you are ready to create the Windows 10 reference image. This will be performed by launching the task sequence from a virtual machine which will then automatically perform the reference image creation and capture process.
-
This steps below outline the process used to boot a virtual machine using an ISO boot image created by MDT, and then execute the reference image task sequence image to create and capture the Windows 10 reference image.
1. Copy the E:\\MDTBuildLab\\Boot\\MDT Build Lab x86.iso on MDT01 to C:\\ISO on the Hyper-V host.
**Note**
Remember, in MDT you can use the x86 boot image to deploy both x86 and x64 operating system images. That's why you can use the x86 boot image instead of the x64 boot image.
-
-
2. Create a virtual machine with the following settings:
-
1. Name: REFW10X64-001
-
2. Location: C:\\VMs
-
3. Memory: 1024 MB
-
4. Network: External (The network that is connected to the same infrastructure as MDT01 is)
-
5. Hard disk: 60 GB (dynamic disk)
-
6. Image file: C:\\ISO\\MDT Build Lab x86.iso
-
3. Take a snapshot of the REFW10X64-001 virtual machine, and name it **Clean with MDT Build Lab x86 ISO**.
**Note**
Taking a snapshot is useful if you need to restart the process and want to make sure you can start clean.
-
-
4. Start the REFW10X64-001 virtual machine. After booting into Windows PE, complete the Windows Deployment Wizard using the following settings:
-
1. Select a task sequence to execute on this computer: Windows 10 Enterprise x64 RTM Default Image
-
2. Specify whether to capture an image: Capture an image of this reference computer
-
- Location: \\\\MDT01\\MDTBuildLab$\\Captures
-
3. File name: REFW10X64-001.wim
@@ -820,26 +608,18 @@ This steps below outline the process used to boot a virtual machine using an ISO
Figure 13. The Windows Deployment Wizard for the Windows 10 reference image.
5. The setup now starts and does the following:
-
1. Installs the Windows 10 Enterprise operating system.
-
2. Installs the added applications, roles, and features.
-
3. Updates the operating system via your local Windows Server Update Services (WSUS) server.
-
4. Stages Windows PE on the local disk.
-
5. Runs System Preparation (Sysprep) and reboots into Windows PE.
-
6. Captures the installation to a Windows Imaging (WIM) file.
-
7. Turns off the virtual machine.
After some time, you will have a Windows 10 Enterprise x64 image that is fully patched and has run through Sysprep, located in the E:\\MDTBuildLab\\Captures folder on your deployment server. The file name is REFW10X64-001.wim.
## Related topics
-
[Get started with the Microsoft Deployment Toolkit (MDT)](get-started-with-the-microsoft-deployment-toolkit.md)
[Deploy a Windows 10 image using MDT 2013 Update 2](deploy-a-windows-10-image-using-mdt.md)
@@ -851,12 +631,3 @@ After some time, you will have a Windows 10 Enterprise x64 image that is fully
[Replace a Windows 7 computer with a Windows 10 computer](replace-a-windows-7-computer-with-a-windows-10-computer.md)
[Configure MDT settings](configure-mdt-2013-settings.md)
-
-
-
-
-
-
-
-
-
diff --git a/windows/deploy/deploy-a-windows-10-image-using-mdt.md b/windows/deploy/deploy-a-windows-10-image-using-mdt.md
index 366d5f7b7c..23176dbd84 100644
--- a/windows/deploy/deploy-a-windows-10-image-using-mdt.md
+++ b/windows/deploy/deploy-a-windows-10-image-using-mdt.md
@@ -2,18 +2,17 @@
title: Deploy a Windows 10 image using MDT 2013 Update 2 (Windows 10)
description: This topic will show you how to take your reference image for Windows 10, and deploy that image to your environment using the Microsoft Deployment Toolkit (MDT), and MDT 2013 Update 2 specifically.
ms.assetid: 1d70a3d8-1b1d-4051-b656-c0393a93f83c
-keywords: ["deployment, automate, tools, configure"]
+keywords: [eployment, automate, tools, configure
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: mdt
author: mtniehaus
---
# Deploy a Windows 10 image using MDT 2013 Update 2
-
**Applies to**
-
- Windows 10
This topic will show you how to take your reference image for Windows 10, and deploy that image to your environment using the Microsoft Deployment Toolkit (MDT), and MDT 2013 Update 2 specifically. You will prepare for this by creating a MDT deployment share that is used solely for image deployment. Separating the processes of creating reference images from the processes used to deploy them in production allows greater control of on both processes. You will then configure the deployment share, create a new task sequence, add applications, add drivers, add rules, and configure Active Directory permissions for deployment.
@@ -22,147 +21,95 @@ For the purposes of this topic, we will use three machines: DC01, MDT01, and PC0
**Note**
For important details about the setup for the steps outlined in this article, please see [Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-10-with-the-microsoft-deployment-toolkit.md).
-
-
Figure 1. The machines used in this topic.
## Step 1: Configure Active Directory permissions
-
These steps will show you how to configure an Active Directory account with the permissions required to deploy a Windows 10 machine to the domain using MDT. These steps assume you have downloaded the sample [Set-OUPermissions.ps1 script](http://go.microsoft.com/fwlink/p/?LinkId=619362) and copied it to C:\\Setup\\Scripts on DC01. The account is used for Windows Preinstallation Environment (Windows PE) to connect to MDT01. In order for MDT to join machines into the contoso.com domain you need to create an account and configure permissions in Active Directory.
-
1. On DC01, using Active Directory User and Computers, browse to **contoso.com / Contoso / Service Accounts**.
-
2. Select the **Service Accounts** organizational unit (OU) and create the MDT\_JD account using the following settings:
-
1. Name: MDT\_JD
-
2. User logon name: MDT\_JD
-
3. Password: P@ssw0rd
-
4. User must change password at next logon: Clear
-
5. User cannot change password: Select
-
6. Password never expires: Select
-
3. In an elevated Windows PowerShell prompt (run as Administrator), run the following commands and press **Enter** after each command:
-
``` syntax
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force
Set-Location C:\Setup\Scripts
.\Set-OUPermissions.ps1 -Account MDT_JD
-TargetOU "OU=Workstations,OU=Computers,OU=Contoso"
```
-
4. The Set-OUPermissions.ps1 script allows the MDT\_JD user account permissions to manage computer accounts in the Contoso / Computers OU. Below you find a list of the permissions being granted:
-
1. Scope: This object and all descendant objects
-
1. Create Computer objects
-
2. Delete Computer objects
-
2. Scope: Descendant Computer objects
-
1. Read All Properties
-
2. Write All Properties
-
3. Read Permissions
-
4. Modify Permissions
-
5. Change Password
-
6. Reset Password
-
7. Validated write to DNS host name
-
8. Validated write to service principal name
## Step 2: Set up the MDT production deployment share
-
-When you are ready to deploy Windows 10 in a production environment, you will first create a new MDT deployment share. You should not use the same deployment share that you used to create the reference image for a production deployment. For guidance on creating a custom Windows 10 image, see [Create a Windows 10 reference image](create-a-windows-10-reference-image.md).
+When you are ready to deploy Windows 10 in a production environment, you will first create a new MDT deployment share. You should not use the same deployment share that you used to create the reference image for a production deployment. For guidance on creating a custom Windows 10 image, see
+[Create a Windows 10 reference image](create-a-windows-10-reference-image.md).
### Create the MDT production deployment share
The steps for creating the deployment share for production are the same as when you created the deployment share for creating the custom reference image:
-
1. On MDT01, log on as Administrator in the CONTOSO domain using a password of **P@ssw0rd.**
-
2. Using the Deployment Workbench, right-click **Deployment Shares** and select **New Deployment Share**.
-
3. On the **Path** page, in the **Deployment share path** text box, type **E:\\MDTProduction** and click **Next**.
-
4. On the **Share** page, in the **Share name** text box, type **MDTProduction$** and click **Next**.
-
5. On the **Descriptive Name** page, in the **Deployment share description** text box, type **MDT Production** and click **Next**.
-
6. On the **Options** page, accept the default settings and click **Next** twice, and then click **Finish**.
-
7. Using File Explorer, verify that you can access the **\\\\MDT01\\MDTProduction$** share.
## Step 3: Add a custom image
-
The next step is to add a reference image into the deployment share with the setup files required to successfully deploy Windows 10. When adding a custom image, you still need to copy setup files (an option in the wizard) because Windows 10 stores additional components in the Sources\\SxS folder which is outside the image and may be required when installing components.
### Add the Windows 10 Enterprise x64 RTM custom image
In these steps, we assume that you have completed the steps in the [Create a Windows 10 reference image](create-a-windows-10-reference-image.md) topic, so you have a Windows 10 reference image in the E:\\MDTBuildLab\\Captures folder on MDT01.
-
1. Using the Deployment Workbench, expand the **Deployment Shares** node, and then expand **MDT Production**; select the **Operating Systems** node, and create a folder named **Windows 10**.
-
2. Right-click the **Windows 10** folder and select **Import Operating System**.
-
3. On the **OS Type** page, select **Custom image file** and click **Next**.
-
4. On the **Image** page, in the **Source file** text box, browse to **E:\\MDTBuildLab\\Captures\\REFW10X64-001.wim** and click **Next**.
-
5. On the **Setup** page, select the **Copy Windows 7, Windows Server 2008 R2, or later setup files from the specified path** option; in the **Setup source directory** text box, browse to **E:\\MDTBuildLab\\Operating Systems\\W10EX64RTM** and click **Next**.
-
6. On the **Destination** page, in the **Destination directory name** text box, type **W10EX64RTM**, click **Next** twice, and then click **Finish**.
-
7. After adding the operating system, double-click the added operating system name in the **Operating Systems / Windows 10** node and change the name to match the following: **Windows 10 Enterprise x64 RTM Custom Image**.
**Note**
The reason for adding the setup files has changed since earlier versions of MDT. MDT 2010 used the setup files to install Windows. MDT uses DISM to apply the image; however, you still need the setup files because some components in roles and features are stored outside the main image.
-
-
Figure 2. The imported operating system after renaming it.
## Step 4: Add an application
-
When you configure your MDT Build Lab deployment share, you will also add any applications to the new deployment share before creating your task sequence. This section walks you through the process of adding an application to the MDT Production deployment share using Adobe Reader as an example.
### Create the install: Adobe Reader XI x86
In this example, we assume that you have downloaded the Adobe Reader XI installation file (AdbeRdr11000\_eu\_ES.msi) to E:\\Setup\\Adobe Reader on MDT01.
-
1. Using the Deployment Workbench, expand the **MDT Production** node and navigate to the **Applications** node.
-
2. Right-click the **Applications** node, and create a new folder named **Adobe**.
-
3. In the **Applications** node, right-click the **Adobe** folder and select **New Application**.
-
4. On the **Application Type** page, select the **Application with source files** option and click **Next**.
-
5. On the **Details** page, in the **Application** name text box, type **Install - Adobe Reader XI - x86** and click **Next**.
-
6. On the **Source** page, in the **Source Directory** text box, browse to **E:\\Setup\\Adobe Reader XI** and click **Next**.
-
7. On the **Destination** page, in the **Specify the name of the directory that should be created** text box, type **Install - Adobe Reader XI - x86** and click **Next**.
-
8. On the **Command Details** page, in the **Command Line** text box, type **msiexec /i AdbeRdr11000\_eu\_ES.msi /q**, click **Next** twice, and then click **Finish**.
@@ -171,101 +118,61 @@ Figure 3. The Adobe Reader application added to the Deployment Workbench.
## Step 5: Prepare the drivers repository
-
In order to deploy Windows 10 with MDT 2013 Update 2 successfully, you need drivers for the boot images and for the actual operating system. This section will show you how to add drivers for the boot image and operating system, using the following hardware models as examples:
-
- Lenovo ThinkPad T420
-
- Dell Latitude E6440
-
- HP EliteBook 8560w
-
- Microsoft Surface Pro
-
For boot images, you need to have storage and network drivers; for the operating system, you need to have the full suite of drivers.
**Note**
You should only add drivers to the Windows PE images if the default drivers don't work. Adding drivers that are not necessary will only make the boot image larger and potentially delay the download time.
-
-
### Create the driver source structure in the file system
The key to successful management of drivers for MDT 2013 Update 2, as well as for any other deployment solution, is to have a really good driver repository. From this repository, you import drivers into MDT for deployment, but you should always maintain the repository for future use.
1. On MDT01, using File Explorer, create the **E:\\Drivers** folder.
-
2. In the **E:\\Drivers** folder, create the following folder structure:
-
1. WinPE x86
-
2. WinPE x64
-
3. Windows 10 x64
-
3. In the new Windows 10 x64 folder, create the following folder structure:
-
- Dell
-
- Latitude E6440
-
- HP
-
- HP EliteBook 8560w
-
- Lenovo
-
- ThinkPad T420 (4178)
-
- Microsoft Corporation
-
- Surface Pro 3
**Note**
Even if you are not going to use both x86 and x64 boot images, we still recommend that you add the support structure for future use.
-
-
### Create the logical driver structure in MDT 2013 Update 2
When you import drivers to the MDT 2013 Update 2 driver repository, MDT creates a single instance folder structure based on driver class names. However, you can, and should, mimic the driver structure of your driver source repository in the Deployment Workbench. This is done by creating logical folders in the Deployment Workbench.
-
1. On MDT01, using Deployment Workbench, select the **Out-of-Box Drivers** node.
-
2. In the **Out-Of-Box Drivers** node, create the following folder structure:
-
1. WinPE x86
-
2. WinPE x64
-
3. Windows 10 x64
-
3. In the **Windows 10 x64** folder, create the following folder structure:
-
- Dell Inc.
-
- Latitude E6440
-
- Hewlett-Packard
-
- HP EliteBook 8560w
-
- Lenovo
-
- 4178
-
- Microsoft Corporation
-
- Surface Pro 3
The preceding folder names are selected because they match the actual make and model values that MDT reads from the machines during deployment. You can find out the model values for your machines via the following command in Windows PowerShell:
-
``` syntax
Get-WmiObject -Class:Win32_ComputerSystem
```
-
Or, you can use this command in a normal command prompt:
-
``` syntax
wmic csproduct get name
```
@@ -279,23 +186,14 @@ Figure 4. The Out-of-Box Drivers structure in Deployment Workbench.
### Create the selection profiles for boot image drivers
By default, MDT adds any storage and network drivers that you import to the boot images. However, you should add only the drivers that are necessary to the boot image. You can control which drivers are added by using selection profiles.
-
The drivers that are used for the boot images (Windows PE) are Windows 10 drivers. If you can’t locate Windows 10 drivers for your device, a Windows 7 or Windows 8.1 driver will most likely work, but Windows 10 drivers should be your first choice.
-
1. On MDT01, using the Deployment Workbench, in the **MDT Production** node, expand the **Advanced Configuration** node, right-click the **Selection Profiles** node, and select **New Selection Profile**.
-
2. In the New Selection Profile Wizard, create a selection profile with the following settings:
-
1. Selection Profile name: WinPE x86
-
2. Folders: Select the WinPE x86 folder in Out-of-Box Drivers.
-
3. Again, right-click the **Selection Profiles** node, and select **New Selection Profile**.
-
4. In the New Selection Profile Wizard, create a selection profile with the following settings:
-
1. Selection Profile name: WinPE x64
-
2. Folders: Select the WinPE x64 folder in Out-of-Box Drivers.
@@ -305,17 +203,12 @@ Figure 5. Creating the WinPE x64 selection profile.
### Extract and import drivers for the x64 boot image
Windows PE supports all the hardware models that we have, but here you learn to add boot image drivers to accommodate any new hardware that might require additional drivers. In this example, you add the latest Intel network drivers to the x64 boot image.
-
In these steps, we assume you have downloaded PROWinx64.exe from Intel.com and saved it to a temporary folder.
1. Extract PROWinx64.exe to a temporary folder - in this example to the **C:\\Tmp\\ProWinx64** folder.
-
2. Using File Explorer, create the **E:\\Drivers\\WinPE x64\\Intel PRO1000** folder.
-
3. Copy the content of the **C:\\Tmp\\PROWinx64\\PRO1000\\Winx64\\NDIS64** folder to the **E:\\Drivers\\WinPE x64\\Intel PRO1000** folder.
-
4. Using Deployment Workbench, expand the **Out-of-Box Drivers** node, right-click the **WinPE x64** node, and select **Import Drivers**. Use the following setting for the Import Drivers Wizard:
-
- Driver source directory: **E:\\Drivers\\WinPE x64\\Intel PRO1000**
### Download, extract, and import drivers
@@ -329,9 +222,7 @@ To get the updates, you download the drivers from the Lenovo ThinkVantage Update
In these steps, we assume you have downloaded and extracted the drivers using ThinkVantage Update Retriever v5.0 to the E:\\Drivers\\Lenovo\\ThinkPad T420 (4178) folder.
1. On MDT01, using the Deployment Workbench, in the **MDT Production** node, expand the **Out-Of-Box Drivers** node, and expand the **Lenovo** node.
-
2. Right-click the **4178** folder and select **Import Drivers**; use the following setting for the Import Drivers Wizard:
-
- Driver source directory: **E:\\Drivers\\Windows 10 x64\\Lenovo\\ThinkPad T420 (4178)**
### For the Latitude E6440
@@ -341,9 +232,7 @@ For the Dell Latitude E6440 model, you use the Dell Driver CAB file, which is ac
In these steps, we assume you have downloaded and extracted the CAB file for the Latitude E6440 model to the E:\\Drivers\\Dell\\Latitude E6440 folder.
1. On **MDT01**, using the **Deployment Workbench**, in the **MDT Production** node, expand the **Out-Of-Box Drivers** node, and expand the **Dell** node.
-
2. Right-click the **Latitude E6440** folder and select **Import Drivers**; use the following setting for the Import Drivers Wizard:
-
- Driver source directory: **E:\\Drivers\\Windows 10 x64\\Dell\\Latitude E6440**
### For the HP EliteBook 8560w
@@ -353,9 +242,7 @@ For the HP EliteBook 8560w, you use HP SoftPaq Download Manager to get the drive
In these steps, we assume you have downloaded and extracted the drivers for the HP EliteBook 8650w model to the E:\\Drivers\\Windows 10 x64\\HP\\HP EliteBook 8560w folder.
1. On **MDT01**, using the **Deployment Workbench**, in the **MDT Production** node, expand the **Out-Of-Box Drivers** node, and expand the **Hewlett-Packard** node.
-
2. Right-click the **HP EliteBook 8560w** folder and select **Import Drivers**; use the following setting for the Import Drivers Wizard:
-
- Driver source directory: **E:\\Drivers\\Windows 10 x64\\HP\\HP EliteBook 8560w**
### For the Microsoft Surface Pro 3
@@ -363,71 +250,43 @@ In these steps, we assume you have downloaded and extracted the drivers for the
For the Microsoft Surface Pro model, you find the drivers on the Microsoft website. In these steps we assume you have downloaded and extracted the Surface Pro 3 drivers to the E:\\Drivers\\Windows 10 x64\\Microsoft\\Surface Pro 3 folder.
1. On MDT01, using the Deployment Workbench, in the **MDT Production** node, expand the **Out-Of-Box Drivers** node, and expand the **Microsoft** node.
-
2. Right-click the **Surface Pro 3** folder and select **Import Drivers**; use the following setting for the Import Drivers Wizard:
-
- Driver source directory: **E:\\Drivers\\Windows 10 x64\\Microsoft\\Surface Pro 3**
## Step 6: Create the deployment task sequence
-
This section will show you how to create the task sequence used to deploy your production Windows 10 reference image. You will then configure the tasks sequence to enable patching via a Windows Server Update Services (WSUS) server.
### Create a task sequence for Windows 10 Enterprise
1. Using the Deployment Workbench, select **Task Sequences** in the **MDT Production** node, and create a folder named **Windows 10**.
-
2. Right-click the new **Windows 10** folder and select **New Task Sequence**. Use the following settings for the New Task Sequence Wizard:
-
1. Task sequence ID: W10-X64-001
-
2. Task sequence name: Windows 10 Enterprise x64 RTM Custom Image
-
3. Task sequence comments: Production Image
-
4. Template: Standard Client Task Sequence
-
5. Select OS: Windows 10 Enterprise x64 RTM Custom Image
-
6. Specify Product Key: Do not specify a product key at this time
-
7. Full Name: Contoso
-
8. Organization: Contoso
-
9. Internet Explorer home page: about:blank
-
10. Admin Password: Do not specify an Administrator Password at this time
-
### Edit the Windows 10 task sequence
1. Right-click the **Windows 10 Enterprise x64 RTM Custom Image** task sequence, and select **Properties**.
-
2. On the **Task Sequence** tab, configure the **Windows 10 Enterprise x64 RTM Custom Image** task sequence with the following settings:
-
1. Preinstall. After the **Enable BitLocker (Offline)** action, add a **Set Task Sequence Variable** action with the following settings:
-
1. Name: Set DriverGroup001
-
2. Task Sequence Variable: DriverGroup001
-
3. Value: Windows 10 x64\\%Make%\\%Model%
-
2. Configure the **Inject Drivers** action with the following settings:
-
1. Choose a selection profile: Nothing
-
2. Install all drivers from the selection profile
-
**Note**
The configuration above indicates that MDT should only use drivers from the folder specified by the DriverGroup001 property, which is defined by the "Choose a selection profile: Nothing" setting, and that MDT should not use plug and play to determine which drivers to copy, which is defined by the "Install all drivers from the selection profile" setting.
-
-
3. State Restore. Enable the **Windows Update (Pre-Application Installation)** action.
-
4. State Restore. Enable the **Windows Update (Post-Application Installation)** action.
-
3. Click **OK**.
@@ -436,21 +295,15 @@ Figure 6. The task sequence for production deployment.
## Step 7: Configure the MDT production deployment share
-
In this section, you will learn how to configure the MDT Build Lab deployment share with the rules required to create a simple and dynamic deployment process. This includes configuring commonly used rules and an explanation of how these rules work.
### Configure the rules
1. On MDT01, using File Explorer, copy the following files from the **D:\\Setup\\Sample Files\\MDT Production\\Control** folder to **E:\\MDTProduction\\Control**. Overwrite the existing files.
-
1. Bootstrap.ini
-
2. CustomSettings.ini
-
2. Right-click the **MDT Production** deployment share and select **Properties**.
-
3. Select the **Rules** tab and modify using the following information:
-
``` syntax
[Settings]
Priority=Default
@@ -486,9 +339,7 @@ In this section, you will learn how to configure the MDT Build Lab deployment sh
SkipCapture=YES
SkipFinalSummary=NO
```
-
4. Click **Edit Bootstrap.ini** and modify using the following information:
-
``` syntax
[Settings]
Priority=Default
@@ -498,43 +349,26 @@ In this section, you will learn how to configure the MDT Build Lab deployment sh
UserID=MDT_BA
SkipBDDWelcome=YES
```
-
5. In the **Windows PE** tab, in the **Platform** drop-down list, make sure **x86** is selected.
-
6. In the **General** sub tab, configure the following settings:
-
- In the **Lite Touch Boot Image Settings** area:
-
1. Image description: MDT Production x86
-
2. ISO file name: MDT Production x86.iso
-
**Note**
Because you are going to use Pre-Boot Execution Environment (PXE) later to deploy the machines, you do not need the ISO file; however, we recommend creating ISO files because they are useful when troubleshooting deployments and for quick tests.
-
-
7. In the **Drivers and Patches** sub tab, select the **WinPE x86** selection profile and select the **Include all drivers from the selection profile** option.
-
8. In the **Windows PE** tab, in the **Platform** drop-down list, select **x64**.
-
9. In the **General** sub tab, configure the following settings:
-
- In the **Lite Touch Boot Image Settings** area:
-
1. Image description: MDT Production x64
-
2. ISO file name: MDT Production x64.iso
-
10. In the **Drivers and Patches** sub tab, select the **WinPE x64** selection profile and select the **Include all drivers from the selection profile** option.
-
11. In the **Monitoring** tab, select the **Enable monitoring for this deployment share** check box.
-
12. Click **OK**.
**Note**
It will take a while for the Deployment Workbench to create the monitoring database and web service.
-
@@ -548,23 +382,18 @@ The rules for the MDT Production deployment share are somewhat different from th
### The Bootstrap.ini file
This is the MDT Production Bootstrap.ini without the user credentials (except domain information):
-
``` syntax
[Settings]
Priority=Default
[Default]
DeployRoot=\\MDT01\MDTProduction$
-
UserDomain=CONTOSO
UserID=MDT_BA
-
SkipBDDWelcome=YES
```
-
### The CustomSettings.ini file
This is the CustomSettings.ini file with the new join domain information:
-
``` syntax
[Settings]
Priority=Default
@@ -601,53 +430,34 @@ SkipCapture=YES
SkipFinalSummary=NO
EventService=http://MDT01:9800
```
-
The additional properties to use in the MDT Production rules file are as follows:
-
- **JoinDomain.** The domain to join.
-
- **DomainAdmin.** The account to use when joining the machine to the domain.
-
- **DomainAdminDomain.** The domain for the join domain account.
-
- **DomainAdminPassword.** The password for the join domain account.
-
- **MachineObjectOU.** The organizational unit (OU) to which to add the computer account.
-
- **ScanStateArgs.** Arguments for the User State Migration Tool (USMT) ScanState command.
-
- **USMTMigFiles(\*).** List of USMT templates (controlling what to backup and restore).
-
- **EventService.** Activates logging information to the MDT monitoring web service.
### Optional deployment share configuration
-If your organization has a Microsoft Software Assurance agreement, you also can subscribe to the additional Microsoft Desktop Optimization Package (MDOP) license (at an additional cost). Included in MDOP is Microsoft Diagnostics and Recovery Toolkit (DaRT), which contains tools that can help you troubleshoot MDT deployments, as well as troubleshoot Windows itself.
+If your organization has a Microsoft Software Assurance agreement, you also can subscribe to the additional Microsoft Desktop Optimization Package (MDOP) license (at an additional cost). Included in MDOP is Microsoft Diagnostics and Recovery Toolkit (DaRT), which contains tools that can help you
+troubleshoot MDT deployments, as well as troubleshoot Windows itself.
### Add DaRT 10 to the boot images
If you have licensing for MDOP and DaRT, you can add DaRT to the boot images using the steps in this section. If you do not have DaRT licensing, or don't want to use it, simply skip to the next section, [Update the Deployment Share](#bkmk-update-deployment). To enable the remote connection feature in MDT 2013 Update 2, you need to do the following:
-
- Install DaRT 10 (part of MDOP 2015 R1).
-
- Copy the two tools CAB files (Toolsx86.cab and Toolsx64.cab) to the deployment share.
-
- Configure the deployment share to add DaRT.
-
In these steps, we assume that you downloaded MDOP 2015 R1 and copied DaRT 10 to the E:\\Setup\\DaRT 10 folder on MDT01.
-
1. On MDT01, install DaRT 10 (MSDaRT10.msi) using the default settings.
-
2. Using File Explorer, navigate to the **C:\\Program Files\\Microsoft DaRT\\v10** folder.
-
3. Copy the Toolsx64.cab file to **E:\\MDTProduction\\Tools\\x64**.
-
4. Copy the Toolsx86.cab file to **E:\\MDTProduction\\Tools\\x86**.
-
5. Using the Deployment Workbench, right-click the **MDT Production** deployment share and select **Properties**.
-
6. In the **Windows PE** tab, in the **Platform** drop-down list, make sure **x86** is selected.
-
7. In the **Features** sub tab, select the **Microsoft Diagnostics and Recovery Toolkit (DaRT)** check box.
@@ -655,35 +465,26 @@ In these steps, we assume that you downloaded MDOP 2015 R1 and copied DaRT 10 to
Figure 8. Selecting the DaRT 10 feature in the deployment share.
8. In the **Windows PE** tab, in the **Platform** drop-down list, select **x64**.
-
9. In the **Features** sub tab, in addition to the default selected feature pack, select the **Microsoft Diagnostics and Recovery Toolkit (DaRT)** check box.
-
10. Click **OK**.
### Update the deployment share
Like the MDT Build Lab deployment share, the MDT Production deployment share needs to be updated after it has been configured. This is the process during which the Windows PE boot images are created.
-
1. Right-click the **MDT Production** deployment share and select **Update Deployment Share**.
-
2. Use the default options for the Update Deployment Share Wizard.
**Note**
The update process will take 5 to 10 minutes.
-
-
## Step 8: Deploy the Windows 10 client image
-
These steps will walk you throug the process of using task sequences to deploy Windows 10 images through a fully automated process. First, you need to add the boot image to Windows Deployment Services (WDS) and then start the deployment. In contrast with deploying images from the MDT Build Lab deployment share, we recommend using the Pre-Installation Execution Environment (PXE) to start the full deployments in the datacenter, even though you technically can use an ISO/CD or USB to start the process.
### Configure Windows Deployment Services
You need to add the MDT Production Lite Touch x64 Boot image to WDS in preparation for the deployment. For the following steps, we assume that Windows Deployment Services has already been installed on MDT01.
-
1. Using the WDS console, right-click **Boot Images** and select **Add Boot Image**.
-
2. Browse to the E:\\MDTProduction\\Boot\\LiteTouchPE\_x64.wim file and add the image with the default settings.
@@ -693,19 +494,12 @@ Figure 9. The boot image added to the WDS console.
### Deploy the Windows 10 client
At this point, you should have a solution ready for deploying the Windows 10 client. We recommend starting by trying a few deployments at a time until you are confident that your configuration works as expected. We find it useful to try some initial tests on virtual machines before testing on physical hardware. This helps rule out hardware issues when testing or troubleshooting. Here are the steps to deploy your Windows 10 image to a virtual machine:
-
1. Create a virtual machine with the following settings:
-
1. Name: PC0005
-
2. Location: C:\\VMs
-
3. Generation: 2
-
4. Memory: 2048 MB
-
5. Hard disk: 60 GB (dynamic disk)
-
2. Start the PC0005 virtual machine, and press **Enter** to start the PXE boot. The machine will now load the Windows PE boot image from the WDS server.
@@ -713,21 +507,13 @@ At this point, you should have a solution ready for deploying the Windows 10 cl
Figure 10. The initial PXE boot process of PC0005.
3. After Windows PE has booted, complete the Windows Deployment Wizard using the following setting:
-
1. Password: P@ssw0rd
-
2. Select a task sequence to execute on this computer: Windows 10 Enterprise x64 RTM Custom Image
-
3. Computer Name: PC0005
-
4. Applications: Select the Install - Adobe Reader XI - x86 application.
-
4. The setup now starts and does the following:
-
1. Installs the Windows 10 Enterprise operating system.
-
2. Installs the added application.
-
3. Updates the operating system via your local Windows Server Update Services (WSUS) server.
### Use the MDT 2013 monitoring feature
@@ -735,9 +521,7 @@ At this point, you should have a solution ready for deploying the Windows 10 cl
Now that you have enabled the monitoring on the MDT Production deployment share, you can follow your deployment of PC0005 via the monitoring node.
1. On MDT01, using Deployment Workbench, expand the **MDT Production** deployment share folder.
-
2. Select the **Monitoring** node, and wait until you see PC0005.
-
3. Double-click PC0005, and review the information.
@@ -754,23 +538,20 @@ Figure 12. The Event Viewer showing a successful deployment of PC0005.
## Multicast deployments
-
Multicast deployment allows for image deployment with reduced network load during simultaneous deployments. Multicast is a useful operating system deployment feature in MDT deployments, however it is important to ensure that your network supports it and is designed for it.
### Requirements
-Multicast requires that Windows Deployment Services (WDS) is running on Windows Server 2008 or later. In addition to the core MDT 2013 setup for multicast, the network needs to be configured to support multicast. In general, this means involving the organization networking team to make sure that Internet Group Management Protocol (IGMP) snooping is turned on and that the network is designed for multicast traffic. The multicast solution uses IGMPv3.
+Multicast requires that Windows Deployment Services (WDS) is running on Windows Server 2008 or later. In addition to the core MDT 2013 setup for multicast, the network needs to be configured to support multicast. In general, this means involving the organization networking team to make sure that
+Internet Group Management Protocol (IGMP) snooping is turned on and that the network is designed for multicast traffic. The multicast solution uses IGMPv3.
### Set up MDT for multicast
Setting up MDT for multicast is straightforward. You enable multicast on the deployment share, and MDT takes care of the rest.
1. On MDT01, right-click the **MDT Production** deployment share folder and select **Properties**.
-
2. In the **General** tab, select the **Enable multicast for this deployment share (requires Windows Server 2008 R2 Windows Deployment Services)** check box, and click **OK**.
-
3. Right-click the **MDT Production** deployment share folder and select **Update Deployment Share**.
-
4. After updating the deployment share, use the Windows Deployment Services console to, verify that the multicast namespace was created.
@@ -779,7 +560,6 @@ Figure 13. The newly created multicast namespace.
## Use offline media to deploy Windows 10
-
In addition to network-based deployments, MDT supports the use of offline media-based deployments of Windows 10. You can very easily generate an offline version of your deployment share - either the full deployment share or a subset of it - by the use of selection profiles. The generated offline media can be burned to a DVD or copied to a USB stick for deployment.
Offline media are useful not only when you do not have network connectivity to the deployment share, but also when you have limited connection to the deployment share and do not want to copy 5 GB of data over the wire. Offline media can still join the domain, but you save the transfer of operating system images, drivers, and applications over the wire.
@@ -787,25 +567,15 @@ Offline media are useful not only when you do not have network connectivity to t
### Create the offline media selection profile
To filter what is being added to the media, you create a selection profile. When creating selection profiles, you quickly realize the benefits of having created a good logical folder structure in the Deployment Workbench.
-
1. On MDT01, using Deployment Workbench, in the **MDT Production / Advanced Configuration** node, right-click **Selection Profile**, and select **New Selection Profile**.
-
2. Use the following settings for the New Selection Profile Wizard:
-
1. General Settings
-
- Selection profile name: Windows 10 Offline Media
-
2. Folders
-
1. Applications / Adobe
-
2. Operating Systems / Windows 10
-
3. Out-Of-Box Drivers / WinPE x64
-
4. Out-Of-Box Drivers / Windows 10 x64
-
5. Task Sequences / Windows 10
### Create the offline media
@@ -813,20 +583,13 @@ To filter what is being added to the media, you create a selection profile. When
In these steps, you generate offline media from the MDT Production deployment share. To filter what is being added to the media, you use the previously created selection profile.
1. On MDT01, using File Explorer, create the **E:\\MDTOfflineMedia** folder.
-
**Note**
When creating offline media, you need to create the target folder first. It is crucial that you do not create a subfolder inside the deployment share folder because it will break the offline media.
-
-
2. Using Deployment Workbench, in the **MDT Production / Advanced Configuration** node, right-click the **Media** node, and select **New Media**.
-
3. Use the following settings for the New Media Wizard:
-
- General Settings
-
1. Media path: **E:\\MDTOfflineMedia**
-
2. Selection profile: Windows 10 Offline Media
### Configure the offline media
@@ -834,27 +597,16 @@ In these steps, you generate offline media from the MDT Production deployment sh
Offline media has its own rules, its own Bootstrap.ini and CustomSettings.ini files. These files are stored in the Control folder of the offline media; they also can be accessed via properties of the offline media in the Deployment Workbench.
1. On MDT01, using File Explorer, copy the CustomSettings.ini file from the **E:\\MDTBuildLab\\Control** folder to **E:\\MDTOfflineMedia\\Content\\Deploy\\Control**. Overwrite the existing files.
-
2. Using Deployment Workbench, in the **MDT Production / Advanced Configuration / Media** node, right-click the **MEDIA001** media, and select **Properties**.
-
3. In the **General** tab, configure the following:
-
1. Clear the Generate x86 boot image check box.
-
2. ISO file name: Windows 10 Offline Media.iso
-
4. Still in the **Windows PE** tab, in the **Platform** drop-down list, select **x64**.
-
5. In the **General** sub tab, configure the following settings:
-
1. In the **Lite Touch Boot Image Settings** area:
-
- Image description: MDT Production x64
-
2. In the **Windows PE Customizations** area, set the Scratch space size to 128.
-
6. In the **Drivers and Patches** sub tab, select the **WinPE x64** selection profile and select the **Include all drivers from the selection profile** option.
-
7. Click **OK**.
### Generate the offline media
@@ -862,30 +614,22 @@ Offline media has its own rules, its own Bootstrap.ini and CustomSettings.ini fi
You have now configured the offline media deployment share however the share has not yet been populated with the files required for deployment. Now everything is ready you populate the deployment share content folder and generate the offline media ISO.
1. On MDT01, using Deployment Workbench, navigate to the **MDT Production / Advanced Configuration / Media** node.
-
2. Right-click the **MEDIA001** media, and select **Update Media Content**. The Update Media Content process now generates the offline media in the **E:\\MDTOfflineMedia\\Content** folder.
### Create a bootable USB stick
The ISO that you got when updating the offline media item can be burned to a DVD and used directly (it will be bootable), but it is often more efficient to use USB sticks instead since they are faster and can hold more data. (A dual-layer DVD is limited to 8.5 GB.)
-
Follow these steps to create a bootable USB stick from the offline media content:
1. On a physical machine running Windows 7 or later, insert the USB stick you want to use.
-
2. Copy the content of the **MDTOfflineMedia\\Content** folder to the root of the USB stick.
-
3. Start an elevated command prompt (run as Administrator), and start the Diskpart utility by typing **Diskpart** and pressing **Enter**.
-
4. In the Diskpart utility, you can type **list volume** (or the shorter **list vol**) to list the volumes, but you really only need to remember the drive letter of the USB stick to which you copied the content. In our example, the USB stick had the drive letter F.
-
5. In the Diskpart utility, type **select volume F** (replace F with your USB stick drive letter).
-
6. In the Diskpart utility, type **active**, and then type **exit**.
## Unified Extensible Firmware Interface (UEFI)-based deployments
-
As referenced in [Windows 10 deployment tools](http://go.microsoft.com/fwlink/p/?LinkId=619546), Unified Extensible Firmware Interface (UEFI)-based deployments are becoming more common. In fact, when you create a generation 2 virtual machine in Hyper-V, you get a UEFI-based computer. During deployment, MDT automatically detects that you have an UEFI-based machine and creates the partitions UEFI requires. You do not need to update or change your task sequences in any way to accommodate UFEI.
@@ -894,7 +638,6 @@ Figure 14. The partitions when deploying an UEFI-based machine.
## Related topics
-
[Get started with the Microsoft Deployment Toolkit (MDT)](get-started-with-the-microsoft-deployment-toolkit.md)
[Create a Windows 10 reference image](create-a-windows-10-reference-image.md)
@@ -906,12 +649,3 @@ Figure 14. The partitions when deploying an UEFI-based machine.
[Replace a Windows 7 computer with a Windows 10 computer](replace-a-windows-7-computer-with-a-windows-10-computer.md)
[Configure MDT settings](configure-mdt-2013-settings.md)
-
-
-
-
-
-
-
-
-
diff --git a/windows/deploy/deploy-windows-10-with-the-microsoft-deployment-toolkit.md b/windows/deploy/deploy-windows-10-with-the-microsoft-deployment-toolkit.md
index dec8665051..765f29c16d 100644
--- a/windows/deploy/deploy-windows-10-with-the-microsoft-deployment-toolkit.md
+++ b/windows/deploy/deploy-windows-10-with-the-microsoft-deployment-toolkit.md
@@ -2,48 +2,38 @@
title: Deploy Windows 10 with the Microsoft Deployment Toolkit (Windows 10)
description: This guide will walk you through the process of deploying Windows 10 in an enterprise environment using the Microsoft Deployment Toolkit (MDT), and MDT 2013 Update 2 specifically.
ms.assetid: 837f009c-617e-4b3f-9028-2246067ee0fb
-keywords: ["deploy", "tools", "configure", "script"]
+keywords: deploy, tools, configure, script
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: mtniehaus
+ms.pagetype: mdt
---
# Deploy Windows 10 with the Microsoft Deployment Toolkit
-
**Applies to**
-
- Windows 10
This guide will walk you through the process of deploying Windows 10 in an enterprise environment using the Microsoft Deployment Toolkit (MDT), and MDT 2013 Update 2 specifically.
The Microsoft Deployment Toolkit is a unified collection of tools, processes, and guidance for automating desktop and server deployment. In addition to reducing deployment time and standardizing desktop and server images, MDT enables you to more easily manage security and ongoing configurations. MDT builds on top of the core deployment tools in the Windows Assessment and Deployment Kit (Windows ADK) with additional guidance and features designed to reduce the complexity and time required for deployment in an enterprise environment.
-
MDT 2013 Update 2 supports the deployment of Windows 10, as well as Windows 7, Windows 8, Windows 8.1, and Windows Server 2012 R2. It also includes support for zero-touch installation (ZTI) with Microsoft System Center 2012 R2 Configuration Manager.
To download the latest version of MDT, visit the [MDT resource page](http://go.microsoft.com/fwlink/p/?LinkId=618117).
## In this section
-
- [Get started with the Microsoft Deployment Toolkit (MDT)](get-started-with-the-microsoft-deployment-toolkit.md)
-
- [Create a Windows 10 reference image](create-a-windows-10-reference-image.md)
-
- [Deploy a Windows 10 image using MDT 2013 Update 2](deploy-a-windows-10-image-using-mdt.md)
-
- [Build a distributed environment for Windows 10 deployment](build-a-distributed-environment-for-windows-10-deployment.md)
-
- [Refresh a Windows 7 computer with Windows 10](refresh-a-windows-7-computer-with-windows-10.md)
-
- [Replace a Windows 7 computer with a Windows 10 computer](replace-a-windows-7-computer-with-a-windows-10-computer.md)
-
- [Configure MDT settings](configure-mdt-2013-settings.md)
## Proof-of-concept environment
-
For the purposes of this guide, and the topics discussed herein, we will use the following servers and client machines: DC01, MDT01, CM01, PC0001, and PC0002.
@@ -59,53 +49,34 @@ Figure 2. The organizational unit (OU) structure used in this guide.
### Server details
- **DC01.** A Windows Server 2012 R2 Standard machine, fully patched with the latest security updates, and configured as Active Directory Domain Controller, DNS Server, and DHCP Server in the contoso.com domain.
-
- Server name: DC01
-
- IP Address: 192.168.1.200
-
- Roles: DNS, DHCP, and Domain Controller
-
- **MDT01.** A Windows Server 2012 R2 Standard machine, fully patched with the latest security updates, and configured as a member server in the contoso.com domain.
-
- Server name: MDT01
-
- IP Address: 192.168.1.210
-
- **CM01.** A Windows Server 2012 R2 Standard machine, fully patched with the latest security updates, and configured as a member server in the contoso.com domain.
-
- Server name: CM01
-
- IP Address: 192.168.1.214
### Client machine details
- **PC0001.** A Windows 10 Enterprise x64 machine, fully patched with the latest security updates, and configured as a member in the contoso.com domain. This machine is referenced as the admin workstation.
-
- Client name: PC0001
-
- IP Address: DHCP
-
- **PC0002.** A Windows 7 SP1 Enterprise x64 machine, fully patched with the latest security updates, and configured as a member in the contoso.com domain. This machine is referenced during the migration scenarios.
-
- Client name: PC0002
-
- IP Address: DHCP
## Sample files
-
The information in this guide is designed to help you deploy Windows 10. In order to help you put the information you learn into practice more quickly, we recommend that you download a small set of sample files for the fictitious Contoso Corporation:
-
- [Gather.ps1](http://go.microsoft.com/fwlink/p/?LinkId=619361). This sample Windows PowerShell script performs the MDT Gather process in a simulated MDT environment. This allows you to test the MDT gather process and check to see if it is working correctly without performing a full Windows deployment.
-
- [Set-OUPermissions.ps1](http://go.microsoft.com/fwlink/p/?LinkId=619362). This sample Windows PowerShell script creates a domain account and then configures OU permissions to allow the account to join machines to the domain in the specified OU.
-
- [MDTSample.zip](http://go.microsoft.com/fwlink/p/?LinkId=619363). This sample web service shows you how to configure a computer name dynamically using MDT.
## Related topics
-
[Microsoft Deployment Toolkit downloads and resources](http://go.microsoft.com/fwlink/p/?LinkId=618117)
[Windows 10 deployment scenarios](windows-10-deployment-scenarios.md)
@@ -119,12 +90,3 @@ The information in this guide is designed to help you deploy Windows 10. In ord
[Sideload apps in Windows 10](sideload-apps-in-windows-10.md)
[Volume Activation for Windows 10](volume-activation-windows-10.md)
-
-
-
-
-
-
-
-
-
diff --git a/windows/deploy/get-started-with-the-microsoft-deployment-toolkit.md b/windows/deploy/get-started-with-the-microsoft-deployment-toolkit.md
index 80d8c4e9f8..57d9153cb2 100644
--- a/windows/deploy/get-started-with-the-microsoft-deployment-toolkit.md
+++ b/windows/deploy/get-started-with-the-microsoft-deployment-toolkit.md
@@ -2,25 +2,25 @@
title: Get started with the Microsoft Deployment Toolkit (MDT) (Windows 10)
description: This topic will help you gain a better understanding of how to use the Microsoft Deployment Toolkit (MDT), and MDT 2013 Update 2 in particular, as part of a Windows operating system deployment.
ms.assetid: a256442c-be47-4bb9-a105-c831f58ce3ee
-keywords: ["deploy", "image", "feature", "install", "tools"]
+keywords: deploy, image, feature, install, tools
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: mdt
author: mtniehaus
---
# Get started with the Microsoft Deployment Toolkit (MDT)
-
**Applies to**
-
- Windows 10
This topic will help you gain a better understanding of how to use the Microsoft Deployment Toolkit (MDT), and MDT 2013 Update 2 in particular, as part of a Windows operating system deployment. MDT is one of the most important tools available to IT professionals today. You can use it to create reference images or as a complete deployment solution. MDT 2013 Update 2 also can be used to extend the operating system deployment features available in Microsoft System Center 2012 R2 Configuration Manager.
In addition to familiarizing you with the features and options available in MDT 2013 Update 2, this topic will walk you through the process of preparing for deploying Windows 10 using MDT by configuring Active Directory, creating an organizational unit (OU) structure, creating service accounts, configuring log files and folders, and installing the tools needed to view the logs and continue with the deployment process.
-For the purposes of this topic, we will use two machines: DC01 and MDT01. DC01 is a domain controller and MDT01 is a Windows Server 2012 R2 standard server. MDT01 is a member of the domain contoso.com for the fictitious Contoso Corporation. For more details on the setup for this topic, please see [Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-10-with-the-microsoft-deployment-toolkit.md#proof).
+For the purposes of this topic, we will use two machines: DC01 and MDT01. DC01 is a domain controller and MDT01 is a Windows Server 2012 R2 standard server. MDT01 is a member of the domain contoso.com for the fictitious Contoso Corporation. For more details on the setup for this topic, please see
+[Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-10-with-the-microsoft-deployment-toolkit.md#proof).
@@ -28,16 +28,12 @@ Figure 1. The machines used in this topic.
## In this section
-
- [Key features in MDT 2013 Update 2](key-features-in-mdt-2013.md)
-
- [MDT 2013 Update 2 Lite Touch components](mdt-2013-lite-touch-components.md)
-
- [Prepare for deployment with MDT 2013 Update 2](prepare-for-windows-deployment-with-mdt-2013.md)
## Related topics
-
[Microsoft Deployment Toolkit downloads and documentation](http://go.microsoft.com/fwlink/p/?LinkId=618117)
[Create a Windows 10 reference image](create-a-windows-10-reference-image.md)
@@ -51,12 +47,3 @@ Figure 1. The machines used in this topic.
[Replace a Windows 7 computer with a Windows 10 computer](replace-a-windows-7-computer-with-a-windows-10-computer.md)
[Configure MDT settings](configure-mdt-2013-settings.md)
-
-
-
-
-
-
-
-
-
diff --git a/windows/deploy/import-export-vamt-data.md b/windows/deploy/import-export-vamt-data.md
index 717f65634e..aff3d6376f 100644
--- a/windows/deploy/import-export-vamt-data.md
+++ b/windows/deploy/import-export-vamt-data.md
@@ -5,14 +5,15 @@ ms.assetid: 09a2c595-1a61-4da6-bd46-4ba8763cfd4f
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Import and Export VAMT Data
-You can use the Volume Activation Management Tool (VAMT) to import product-activation data from a Computer Information List (.cilx or .cil) file into SQL Server, and to export product-activation data into a .cilx file. A .cilx file is an XML file that stores computer and product-activation data. You can import data or export data during the following scenarios:
+You can use the Volume Activation Management Tool (VAMT) to import product-activation data from a Computer Information List (.cilx or .cil) file into SQL Server, and to export product-activation data into a .cilx file. A .cilx file is an XML file that stores computer and product-activation data.
+You can import data or export data during the following scenarios:
- Import and merge data from previous versions of VAMT.
-
- Export data to use to perform proxy activations.
**Warning**
@@ -21,37 +22,25 @@ Editing a .cilx file using an application other than VAMT can corrupt the .cilx
## Import VAMT Data
**To import data into VAMT**
-
1. Open VAMT.
-
2. In the right-side **Actions** pane, click **Import list** to open the **Import List** dialog box.
-
3. In the **Import List** dialog box, navigate to the .cilx file location, select the file, and click **Open**.
-
4. In the **Volume Activation Management Tool** dialog box, click **OK** to begin the import. VAMT displays a progress message while the file is being imported. Click **OK** when a message appears and confirms that the import has completed successfully.
## Export VAMT Data
+
Exporting VAMT data from a non-Internet-connected VAMT host computer is the first step of proxy activation using multiple VAMT hosts. To export product-activation data to a .cilx file:
-
1. In the left-side pane, you can click a product you want to export data for, or click **Products** if the list contains data for all products.
-
2. If you want to export only part of the data in a product list, in the product list view in the center pane select the products you want to export.
-
3. In the right-side **Actions** pane on, click **Export list** to open the **Export List** dialog box.
-
4. In the **Export List** dialog box, click **Browse** to navigate to the .cilx file.
-
5. Under **Export options**, select one of the following data-type options:
-
- Export products and product keys
-
- Export products only
-
- Export proxy activation data only. Selecting this option ensures that the export contains only the licensing information required for the proxy web service to obtain CIDs from Microsoft. No Personally Identifiable Information (PII) is contained in the exported .cilx file when this selection is checked.
-
6. If you have selected products to export, select the **Export selected product rows only** check box.
-
7. Click **Save**. VAMT displays a progress message while the data is being exported. Click **OK** when a message appears and confirms that the export has completed successfully.
## Related topics
-- [Perform Proxy Activation](proxy-activation-vamt.md)
\ No newline at end of file
+
+- [Perform Proxy Activation](proxy-activation-vamt.md)
diff --git a/windows/deploy/install-configure-vamt.md b/windows/deploy/install-configure-vamt.md
index f067221d22..a660854f6f 100644
--- a/windows/deploy/install-configure-vamt.md
+++ b/windows/deploy/install-configure-vamt.md
@@ -5,13 +5,16 @@ ms.assetid: 5c7ae9b9-0dbc-4277-bc4f-8b3e4ab0bf50
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Install and Configure VAMT
+
This section describes how to install and configure the Volume Activation Management Tool (VAMT).
## In this Section
+
|Topic |Description |
|------|------------|
|[VAMT Requirements](vamt-requirements.md) |Provides system requirements for installing VAMT on a host computer. |
@@ -19,13 +22,7 @@ This section describes how to install and configure the Volume Activation Manage
|[Configure Client Computers](configure-client-computers-vamt.md) |Describes how to configure client computers on your network to work with VAMT. |
## Related topics
+
- [Introduction to VAMT](introduction-vamt.md)
-
-
-
-
-
-
-
diff --git a/windows/deploy/install-kms-client-key-vamt.md b/windows/deploy/install-kms-client-key-vamt.md
index 87139b0c7e..f1e5cd2769 100644
--- a/windows/deploy/install-kms-client-key-vamt.md
+++ b/windows/deploy/install-kms-client-key-vamt.md
@@ -5,40 +5,33 @@ ms.assetid: d234468e-7917-4cf5-b0a8-4968454f7759
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Install a KMS Client Key
+
You can use the Volume Activation Management Tool (VAMT) to install Generic Volume License Key (GVLK), or KMS client, product keys. For example, if you are converting a MAK-activated product to KMS activation.
**Note**
By default, volume license editions of Windows Vista, Windows® 7, Windows 8, Windows 10, Windows Server 2008, Windows Server 2008 R2, Windows Server® 2012, and Microsoft® Office 2010 use KMS for activation. GVLKs are already installed in volume license editions of these products.
**To install a KMS Client key**
-
1. Open VAMT.
-
2. In the left-side pane click **Products** to open the product list view in the center pane.
-
3. In the products list view in the center pane, select the products that need to have GVLKs installed. You can use the **Filter** function to narrow your search for computers by clicking **Filter** in the right-side pane to open the **Filter Products** dialog box.
-
4. In the **Filter Products** dialog box, you can filter the list by computer name, product name, product key type, license status, or by any combination of these options.
-
- To filter the list by computer name, enter a name in the **Computer Name** box.
-
- To filter the list by Product Name, Product Key Type, or License Status, click the list you want to use for the filter and select an option. If necessary, click **clear all filters** to create a new filter.
-
5. Click **Filter**. VAMT displays the filtered list in the center pane.
-
6. Click **Install product key** in the **Selected Items** menu in the right-side pane to display the **Install Product Key** dialog box.
-
7. The **Install Product Key** dialog box displays the keys that are available to be installed.
-
8. Select the **Automatically select an AD or KMS client key** option and then click **Install Key**.
VAMT displays the **Installing product key** dialog box while it attempts to install the product key for the selected products. When the process is finished, the status appears in the **Action Status** column of the dialog box. Click **Close** to close the dialog box. You can also click the **Automatically close when done** check box when the dialog box appears.
-
+
The same status is shown under the **Status of Last Action** column in the product list view in the center pane.
## Related topics
-- [Perform KMS Activation](kms-activation-vamt.md)
\ No newline at end of file
+
+- [Perform KMS Activation](kms-activation-vamt.md)
diff --git a/windows/deploy/install-product-key-vamt.md b/windows/deploy/install-product-key-vamt.md
index 2e55911707..a3f4a3760e 100644
--- a/windows/deploy/install-product-key-vamt.md
+++ b/windows/deploy/install-product-key-vamt.md
@@ -5,49 +5,35 @@ ms.assetid: 78812c87-2208-4f8b-9c2c-5a8a18b2d648
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Install a Product Key
+
You can use the Volume Activation Management Tool (VAMT) to install retail, Multiple Activation Key (MAK), and KMS Host key (CSVLK).
**To install a Product key**
-
1. Open VAMT.
-
2. In the left-side pane, click the product that you want to install keys onto.
-
3. You can use the **Filter** function to narrow your search for computers by clicking **Filter** in the right-side pane to open the **Filter Products** dialog box.
-
4. In the **Filter Products** dialog box, you can filter the list by computer name, product name, product key type, license status, or by any combination of these options.
-
- To filter the list by computer name, enter a name in the **Computer Name** box.
-
- To filter the list by Product Name, Product Key Type, or License Status, click the list you want to use for the filter and select an option. If necessary, click **clear all filters** to create a new filter.
-
5. Click **Filter**.
-
6. In the products list view in the center pane, sort the list if needed and then select the products that need to have keys installed. You can use the **CTRL** key or the **SHIFT** key to select more than one product.
-
7. Click **Install product key** in the **Selected Items** menu in the right-side pane to display the **Install Product Key** dialog box.
-
8. The **Select Product Key** dialog box displays the keys that are available to be installed. Under **Recommended MAKs**, VAMT might display one or more recommended MAK based on the selected products. You can select a recommended product key or a product key from the **All Product Keys** list. Use the scroll bar if you need to view the **Description** for each key. When you have selected the product key you want to install, click **Install Key**. Note that only one key can be installed at a time.
-
9. VAMT displays the **Installing product key** dialog box while it attempts to install the product key for the selected products. When the process is finished, the status appears in the **Action Status** column of the dialog box. Click **Close** to close the dialog box. You can also click the **Automatically close when done** check box when the dialog box appears.
The same status is shown under the **Status of Last Action** column in the product list view in the center pane.
**Note**
- Product key installation will fail if VAMT finds mismatched key types or editions. VAMT will display the failure status and will continue the installation for the next product in the list. For more information on choosing the correct MAK or KMS Host key (CSVLK), see [How to Choose the Right Volume License Key for Windows](http://go.microsoft.com/fwlink/p/?linkid=238382).
+ Product key installation will fail if VAMT finds mismatched key types or editions. VAMT will display the failure status and will continue the installation for the next product in the list. For more information on choosing the correct MAK or KMS Host key (CSVLK), see [How to Choose the Right
+ Volume License Key for Windows](http://go.microsoft.com/fwlink/p/?linkid=238382).
## Related topics
+
- [Manage Product Keys](manage-product-keys-vamt.md)
-
-
-
-
-
-
-
diff --git a/windows/deploy/install-vamt.md b/windows/deploy/install-vamt.md
index 025b2747b9..02275fb993 100644
--- a/windows/deploy/install-vamt.md
+++ b/windows/deploy/install-vamt.md
@@ -5,13 +5,16 @@ ms.assetid: 2eabd3e2-0a68-43a5-8189-2947e46482fc
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Install VAMT
+
This topic describes how to install the Volume Activation Management Tool (VAMT).
## Install VAMT
+
You can install VAMT as part of the [Windows Assessment and Deployment Kit (ADK)](http://go.microsoft.com/fwlink/p/?LinkId=526740) for Windows 10.
**Important**
@@ -22,15 +25,12 @@ The VAMT Microsoft Management Console snap-in ships as an x86 package.
After you install VAMT, if you have a computer information list (CIL) that was created in a previous version of VAMT, you must import the list into a SQL database. If you do not have SQL installed, you can download a free copy of Microsoft SQL Server Express and create a new database into which you can import the CIL. To install SQL Server Express:
1. Install the Windows ADK.
-
2. Ensure that **Volume Activation Management Tool** and **Microsoft® SQL Server® 2012 Express** are selected to be installed.
-
3. Click **Install**.
-
## Select a Database
-**Using a SQL database installed during ADK setup**
+**Using a SQL database installed during ADK setup**
If SQL Server 2012 Express was installed during ADK setup, the default database name will be **ADK**.By default, VAMT is configure to use a SQL database that is installed on the local machine during ADK setup and displays the server name as **.\\ADK**. If the SQL database was installed on another machine, you must configure the database to allow remote connections and you must provide the corresponding server name. If a new VAMT database needs to be created, provide a name for the new database.
**Using a SQL database installed outside of ADK setup**
@@ -38,20 +38,12 @@ If SQL Server 2012 Express was installed during ADK setup, the default database
You must configure SQL installation to allow remote connections and you must provide the corresponding server name in the format: *Machine Name\\SQL Server Name*. If a new VAMT database needs to be created, provide a name for the new database.
## Uninstall VAMT
+
To uninstall VAMT via the **Programs and Features** Control Panel:
-
1. Open the **Control Panel** and select **Programs and Features**.
-
2. Select **Assessment and Deployment Kit** from the list of installed programs and click **Change**. Follow the instructions in the Windows ADK installer to remove VAMT.
## Related topics
- [Install and Configure VAMT](install-configure-vamt.md)
-
-
-
-
-
-
-
diff --git a/windows/deploy/integrate-configuration-manager-with-mdt-2013.md b/windows/deploy/integrate-configuration-manager-with-mdt-2013.md
index fb39507c19..1ad2dbc2bd 100644
--- a/windows/deploy/integrate-configuration-manager-with-mdt-2013.md
+++ b/windows/deploy/integrate-configuration-manager-with-mdt-2013.md
@@ -2,7 +2,8 @@
title: Integrate Configuration Manager with MDT 2013 Update 2 (Windows 10)
description: This topic will help you understand the benefits of integrating the Microsoft Deployment Toolkit with Microsoft System Center 2012 R2 Configuration Manager SP1 when you deploy a new or updated version of the Windows operating system.
ms.assetid: 3bd1cf92-81e5-48dc-b874-0f5d9472e5a5
-keywords: ["deploy, image, customize, task sequence"]
+ms.pagetype: mdt
+keywords: deploy, image, customize, task sequence
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
@@ -11,18 +12,14 @@ author: mtniehaus
# Integrate Configuration Manager with MDT 2013 Update 2
-
**Applies to**
-
- Windows 10
This topic will help you understand the benefits of integrating the Microsoft Deployment Toolkit with Microsoft System Center 2012 R2 Configuration Manager SP1 when you deploy a new or updated version of the Windows operating system.
-
MDT 2013 is a free, supported download from Microsoft that adds approximately 280 enhancements to Windows operating system deployment with System Center 2012 R2 Configuration Manager SP1. It is, therefore, recommended that you utilize MDT when deploying the Windows operating system with Configuration Manager SP1. In addition to integrating MDT with Configuration Manager, we also recommend using MDT Lite Touch to create the Windows 10 reference images used in Configuration Manager. For more information on how to create a reference image, see [Create a Windows 10 reference image](create-a-windows-10-reference-image.md).
## Why integrate MDT 2013 Update 2 with Configuration Manager
-
As noted above, MDT adds many enhancements to Configuration Manager. While these enhancements are called Zero Touch, that name does not reflect how deployment is conducted. The following sections provide a few samples of the 280 enhancements that MDT 2013 Update 2 adds to Configuration Manager.
### MDT enables dynamic deployment
@@ -30,18 +27,14 @@ As noted above, MDT adds many enhancements to Configuration Manager. While these
When MDT is integrated with Configuration Manager, the task sequence takes additional instructions from the MDT rules. In its most simple form, these settings are stored in a text file, the CustomSettings.ini file, but you can store the settings in Microsoft SQL Server databases, or have Microsoft Visual Basic Scripting Edition (VBScripts) or web services provide the settings used.
The task sequence uses instructions that allow you to reduce the number of task sequences in Configuration Manager and instead store settings outside the task sequence. Here are a few examples:
-
- The following settings instruct the task sequence to install the HP Hotkeys package, but only if the hardware is a HP EliteBook 8570w. Note that you don't have to add the package to the task sequence.
-
``` syntax
[Settings]
Priority=Model
[HP EliteBook 8570w]
Packages001=PS100010:Install HP Hotkeys
```
-
- The following settings instruct the task sequence to put laptops and desktops in different organizational units (OUs) during deployment, assign different computer names, and finally have the task sequence install the Cisco VPN client, but only if the machine is a laptop.
-
``` syntax
[Settings]
Priority= ByLaptopType, ByDesktopType
@@ -90,24 +83,16 @@ MDT Zero Touch simply extends Configuration Manager with many useful built-in op
## Why use MDT Lite Touch to create reference images
-
You can create reference images for Configuration Manager in Configuration Manager, but in general we recommend creating them in MDT Lite Touch for the following reasons:
-
- In a deployment project, it is typically much faster to create a reference image using MDT Lite Touch than Configuration Manager.
-
- You can use the same image for every type of operating system deployment - Microsoft Virtual Desktop Infrastructure (VDI), Microsoft System Center 2012 R2 Virtual Machine Manager (SCVMM), MDT, Configuration Manager, Windows Deployment Services (WDS), and more.
-
- Microsoft System Center 2012 R2 performs deployment in the LocalSystem context. This means that you cannot configure the Administrator account with all of the settings that you would like to be included in the image. MDT runs in the context of the Local Administrator, which means you can configure the look and feel of the configuration and then use the CopyProfile functionality to copy these changes to the default user during deployment.
-
- The Configuration Manager task sequence does not suppress user interface interaction.
-
- MDT Lite Touch supports a Suspend action that allows for reboots, which is useful when you need to perform a manual installation or check the reference image before it is automatically captured.
-
- MDT Lite Touch does not require any infrastructure and is easy to delegate.
## Related topics
-
[Prepare for Zero Touch Installation of Windows 10 with Configuration Manager](prepare-for-zero-touch-installation-of-windows-10-with-configuration-manager.md)
[Create a custom Windows PE boot image with Configuration Manager](create-a-custom-windows-pe-boot-image-with-configuration-manager.md)
@@ -122,15 +107,7 @@ You can create reference images for Configuration Manager in Configuration Manag
[Deploy Windows 10 using PXE and Configuration Manager](deploy-windows-10-using-pxe-and-configuration-manager.md)
+
[Refresh a Windows 7 SP1 client with Windows 10 using Configuration Manager](refresh-a-windows-7-client-with-windows-10-using-configuration-manager.md)
-[Replace a Windows 7 SP1 client with Windows 10 using Configuration Manager](replace-a-windows-7-client-with-windows-10-using-configuration-manager.md)
-
-
-
-
-
-
-
-
-
+[Replace a Windows 7 SP1 client with Windows 10 using Configuration Manager](replace-a-windows-7-client-with-windows-10-using-configuration-manager.md)
diff --git a/windows/deploy/introduction-vamt.md b/windows/deploy/introduction-vamt.md
index 7a3deda46b..ee0060ad4e 100644
--- a/windows/deploy/introduction-vamt.md
+++ b/windows/deploy/introduction-vamt.md
@@ -5,10 +5,12 @@ ms.assetid: 0439685e-0bae-4967-b0d4-dd84ca6d7fa7
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Introduction to VAMT
+
The Volume Activation Management Tool (VAMT) enables network administrators and other IT professionals to automate and centrally manage the Windows®, Microsoft® Office®, and select other Microsoft products volume and retail activation process. VAMT can manage volume activation using Multiple Activation Keys (MAKs) or the Windows Key Management Service (KMS). VAMT is a standard Microsoft Management Console (MMC) snap-in and can be installed on any computer that has one of the following Windows operating systems: Windows® 7, Windows 8, Windows 8.1, Windows 10,Windows Server 2008 R2, or Windows Server 2012.
**Note**
@@ -16,59 +18,44 @@ VAMT can be installed on, and can manage, physical or virtual instances. VAMT ca
## In this Topic
- [Managing Multiple Activation Key (MAK) and Retail Activation](#bkmk-managingmak)
-
- [Managing Key Management Service (KMS) Activation](#bkmk-managingkms)
-
- [Enterprise Environment](#bkmk-enterpriseenvironment)
-
- [VAMT User Interface](#bkmk-userinterface)
## Managing Multiple Activation Key (MAK) and Retail Activation
+
You can use a MAK or a retail product key to activate Windows, Windows Server, or Office on an individual computer or a group of computers. VAMT enables two different activation scenarios:
-
- **Online activation.** Many enterprises maintain a single Windows system image or Office installation package for deployment across the enterprise. Occasionally there is also a need to use retail product keys in special situations. Online activation enables you to activate over the Internet any products installed with MAK, KMS host, or retail product keys on one or more connected computers within a network. This process requires that each product communicate activation information directly to Microsoft.
-
- **Proxy activation.** This activation method enables you to perform volume activation for products installed on client computers that do not have Internet access. The VAMT host computer distributes a MAK, KMS Host key (CSVLK), or retail product key to one or more client products and collects the installation ID (IID) from each client product. The VAMT host sends the IIDs to Microsoft on behalf of the client products and obtains the corresponding Confirmation IDs (CIDs). The VAMT host then installs the CIDs on the client products to complete the activation. Using this method, only the VAMT host computer needs Internet access. You can also activate products installed on computers in a workgroup that is completely isolated from any larger network, by installing a second instance of VAMT on a computer within the workgroup. Then, use removable media to transfer activation data between this new instance of VAMT and the Internet-connected VAMT host.
## Managing Key Management Service (KMS) Activation
-In addition to MAK or retail activation, you can use VAMT to perform volume activation using the Key Management Service (KMS). VAMT can install and activate GVLK (KMS client) keys on client products. GVLKs are the default product keys used by Volume License editions of Windows Vista, Windows 7, Windows 8, Windows 10, Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012 as well as Microsoft Office 2010.
+In addition to MAK or retail activation, you can use VAMT to perform volume activation using the Key Management Service (KMS). VAMT can install and activate GVLK (KMS client) keys on client products. GVLKs are the default product keys used by Volume License editions of Windows Vista, Windows 7, Windows 8, Windows 10, Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012 as well as Microsoft Office 2010.
VAMT treats a KMS Host key (CSVLK) product key identically to a retail-type product key; therefore, the experience for product key entry and activation management are identical for both these product key types.
## Enterprise Environment
+
VAMT is commonly implemented in enterprise environments. The following illustrates three common environments—Core Network, Secure Zone, and Isolated Lab.
In the Core Network environment, all computers are within a common network managed by Active Directory® Domain Services (AD DS). The Secure Zone represents higher-security Core Network computers that have additional firewall protection.
-
The Isolated Lab environment is a workgroup that is physically separate from the Core Network, and its computers do not have Internet access. The network security policy states that no information that could identify a specific computer or user may be transferred out of the Isolated Lab.
## VAMT User Interface
+
The following screenshot shows the VAMT graphical user interface.
VAMT provides a single, graphical user interface for managing activations, and for performing other activation-related tasks such as:
-
- **Adding and removing computers.** You can use VAMT to discover computers in the local environment. VAMT can discover computers by querying AD DS, workgroups, by individual computer name or IP address, or via a general LDAP query.
-
- **Discovering products.** You can use VAMT to discover Windows, Windows Server, Office, and select other products installed on the client computers.
-
- **Monitoring activation status.** You can collect activation information about each product, including the last 5 characters of the product key being used, the current license state (such as Licensed, Grace, Unlicensed), and the product edition information.
-
- **Managing product keys.** You can store multiple product keys and use VAMT to install these keys to remote client products. You can also determine the number of activations remaining for MAKs.
-
- **Managing activation data.** VAMT stores activation data in a SQL database. VAMT can export this data to other VAMT hosts or to an archive in XML format.
## Related topics
- [VAMT Step-by-Step Scenarios](vamt-step-by-step.md)
-
-
-
-
-
-
-
diff --git a/windows/deploy/key-features-in-mdt-2013.md b/windows/deploy/key-features-in-mdt-2013.md
index 21bcc2ef9a..7982bb6d03 100644
--- a/windows/deploy/key-features-in-mdt-2013.md
+++ b/windows/deploy/key-features-in-mdt-2013.md
@@ -2,34 +2,27 @@
title: Key features in MDT 2013 Update 2 (Windows 10)
description: The Microsoft Deployment Toolkit (MDT) has been in existence since 2003, when it was first introduced as Business Desktop Deployment (BDD) 1.0.
ms.assetid: 858e384f-e9db-4a93-9a8b-101a503e4868
-keywords: ["deploy, feature, tools, upgrade, migrate, provisioning"]
+keywords: deploy, feature, tools, upgrade, migrate, provisioning
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: mdt
author: mtniehaus
---
# Key features in MDT 2013 Update 2
-
**Applies to**
-
- Windows 10
The Microsoft Deployment Toolkit (MDT) has been in existence since 2003, when it was first introduced as Business Desktop Deployment (BDD) 1.0. The toolkit has evolved, both in functionality and popularity, and today it is considered fundamental to Windows operating system and enterprise application deployment.
MDT 2013 has many useful features, the most important of which are:
-
- **Windows Client support.** Supports Windows 7, Windows 8, Windows 8.1, and Windows 10.
-
- **Windows Server support.** Supports Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2.
-
- **Additional operating systems support.** Supports Windows Thin PC and Windows Embedded POSReady 7, as well as Windows 8.1 Embedded Industry.
-
- **UEFI support.** Supports deployment to machines using Unified Extensible Firmware Interface (UEFI) version 2.3.1.
-
- **GPT support.** Supports deployment to machines that require the new GUID (globally unique identifier) partition table (GPT) format. This is related to UEFI.
-
- **Enhanced Windows PowerShell support.** Provides support for running PowerShell scripts.
@@ -37,23 +30,14 @@ MDT 2013 has many useful features, the most important of which are:
Figure 2. The deployment share mounted as a standard PSDrive allows for administration using PowerShell.
- **Add local administrator accounts.** Allows you to add multiple user accounts to the local Administrators group on the target computers, either via settings or the deployment wizard.
-
- **Automated participation in CEIP and WER.** Provides configuration for participation in Windows Customer Experience Improvement Program (CEIP) and Windows Error Reporting (WER).
-
- **Deploy Windows RE.** Enables deployment of a customized Windows Recovery Environment (Windows RE) as part of the task sequence.
-
- **Deploy to VHD.** Provides ready-made task sequence templates for deploying Windows into a virtual hard disk (VHD) file.
-
- **Improved deployment wizard.** Provides additional progress information and a cleaner UI for the Lite Touch Deployment Wizard.
-
- **Monitoring.** Allows you to see the status of currently running deployments.
-
- **Apply GPO Pack.** Allows you to deploy local group policy objects created by Microsoft Security Compliance Manager (SCM).
-
- **Partitioning routines.** Provides improved partitioning routines to ensure that deployments work regardless of the current hard drive structure.
-
- **Offline BitLocker.** Provides the capability to have BitLocker enabled during the Windows Preinstallation Environment (Windows PE) phase, thus saving hours of encryption time.
-
- **USMT offline user-state migration.** Provides support for running the User State Migration Tool (USMT) capture offline, during the Windows PE phase of the deployment.
@@ -61,31 +45,17 @@ MDT 2013 has many useful features, the most important of which are:
Figure 3. The offline USMT backup in action.
- **Install or uninstall Windows roles or features.** Enables you to select roles and features as part of the deployment wizard. MDT also supports uninstall of roles and features.
-
- **Microsoft System Center 2012 Orchestrator integration.** Provides the capability to use Orchestrator runbooks as part of the task sequence.
-
- **Support for DaRT.** Supports optional integration of the DaRT components into the boot image.
-
- **Support for Office 2013.** Provides added support for deploying Microsoft Office Professional Plus 2013.
-
- **Support for Modern UI app package provisioning.** Provisions applications based on the new Windows app package standard, which is used in Windows 8 and later.
-
- **Extensibility.** Provides the capability to extend MDT far beyond the built-in features by adding custom scripts, web services, System Center Orchestrator runbooks, PowerShell scripts, and VBScripts.
-
- **Upgrade task sequence.** Provides a new upgrade task sequence template that you can use to upgrade existing Windows 7, Windows 8, and Windows 8.1 systems directly to Windows 10, automatically preserving all data, settings, applications, and drivers. For more information about using this new upgrade task sequence, refer to the [Microsoft Deployment Toolkit resource page](http://go.microsoft.com/fwlink/p/?LinkId=618117).
## Related topics
-
[Prepare for deployment with MDT 2013 Update 2](prepare-for-windows-deployment-with-mdt-2013.md)
[MDT 2013 Update 2 Lite Touch components](mdt-2013-lite-touch-components.md)
-
-
-
-
-
-
-
diff --git a/windows/deploy/kms-activation-vamt.md b/windows/deploy/kms-activation-vamt.md
index ea79345364..4cd554a80b 100644
--- a/windows/deploy/kms-activation-vamt.md
+++ b/windows/deploy/kms-activation-vamt.md
@@ -5,66 +5,40 @@ ms.assetid: 5a3ae8e6-083e-4153-837e-ab0a225c1d10
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Perform KMS Activation
+
The Volume Activation Management Tool (VAMT) can be used to perform volume activation using the Key Management Service (KMS). You can use VAMT to activate Generic Volume Licensing Keys, or KMS client keys, on products accessible to VAMT. GVLKs are the default product keys used by the volume-license editions of Windows Vista, Windows 7, Windows 8, Windows 10, Windows Server 2008, Windows Server 2008 R2, Windows Server® 2012, and Microsoft Office 2010. GVLKs are already installed in volume-license editions of these products.
## Requirements
+
Before configuring KMS activation, ensure that your network and VAMT installation meet the following requirements:
-
- KMS host is set up and enabled.
-
- KMS clients can access the KMS host.
-
- VAMT is installed on a central computer with network access to all client computers.
-
- The products to be activated have been added to VAMT. For more information on adding product keys, see [Install a KMS Client Key](install-kms-client-key-vamt.md).
-
- VAMT has administrative permissions on all computers to be activated, and Windows Management Instrumentation (WMI) is accessible through the Windows Firewall. For more information, see [Configure Client Computers](configure-client-computers-vamt.md).
## To configure devices for KMS activation
**To configure devices for KMS activation**
-
1. Open VAMT.
-
2. If necessary, set up the KMS activation preferences. If you don’t need to set up the preferences, skip to step 6 in this procedure. Otherwise, continue to step 2.
-
3. To set up the preferences, on the menu bar click **View**, then click **Preferences** to open the **Volume Activation Management Tool Preferences** dialog box.
-
4. Under **Key Management Services host selection**, select one of the following options:
-
- **Find a KMS host automatically using DNS (default)**. If you choose this option, VAMT first clears any previously configured KMS host on the target computer and instructs the computer to query the Domain Name Service (DNS) to locate a KMS host and attempt activation.
-
- **Find a KMS host using DNS in this domain for supported products**. Enter the domain name. If you choose this option, VAMT first clears any previously configured KMS host on the target computer and instructs the computer to query the DNS in the specified domain to locate a KMS host and attempt activation.
-
- **Use specific KMS host**. Enter the KMS host name and KMS host port. For environments which do not use DNS for KMS host identification, VAMT sets the specified KMS host name and KMS host port on the target computer, and then instructs the computer to attempt activation with the specific KMS host.
-
5. Click **Apply**, and then click **OK** to close the **Volume Activation Management Tool Preferences** dialog box.
-
6. Select the products to be activated by selecting individual products in the product list view in the center pane. You can use the **Filter** function to narrow your search for computers by clicking **Filter** in the right-side pane to open the **Filter Products** dialog box.In the **Filter Products** dialog box, you can filter the list by computer name, product name, product key type, license status, or by any combination of these options.
-
- To filter the list by computer name, enter a name in the **Computer Name** box.
-
- To filter the list by Product Name, Product Key Type, or License Status, click the list you want to use for the filter and select an option. If necessary, click **clear all filters** to create a new filter.
-
7. Click **Filter**. VAMT displays the filtered list in the center pane.
-
8. In the right-side pane, click **Activate** in the **Selected Items** menu, and then click **Volume activate**.
-
9. Click a credential option. Choose **Alternate credentials** only if you are activating products that require administrator credentials different from the ones you are currently using.
-
10. If you are supplying alternate credentials, at the prompt, type the appropriate user name and password and click **OK**.
-
VAMT displays the **Volume Activation** dialog box until it completes the requested action. When the process is finished, the updated activation status of each product appears in the product list view in the center pane.
-
-
-
-
-
-
-
-
-
+
\ No newline at end of file
diff --git a/windows/deploy/local-reactivation-vamt.md b/windows/deploy/local-reactivation-vamt.md
index d8a5f6f9db..2cd36eb80b 100644
--- a/windows/deploy/local-reactivation-vamt.md
+++ b/windows/deploy/local-reactivation-vamt.md
@@ -5,12 +5,13 @@ ms.assetid: aacd5ded-da11-4d27-a866-3f57332f5dec
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Perform Local Reactivation
-If you reinstall Windows® or Microsoft® Office 2010 on a computer that was initially activated using proxy activation (MAK, retail, or CSLVK (KMS host)), and have not made significant changes to the hardware, use this local reactivation procedure to reactivate the program on that computer.
+If you reinstall Windows® or Microsoft® Office 2010 on a computer that was initially activated using proxy activation (MAK, retail, or CSLVK (KMS host)), and have not made significant changes to the hardware, use this local reactivation procedure to reactivate the program on that computer.
Local reactivation relies upon data that was created during the initial proxy activation and stored in the Volume Activation Management Tool (VAMT) database. The database contains the installation ID (IID) and confirmation ID (Pending CID). Local reactivation uses this data to reapply the CID and reactivate those products. Reapplying the same CID conserves the remaining activations on the key.
**Note**
@@ -19,34 +20,23 @@ During the initial proxy activation, the CID is bound to a digital “fingerprin
## To Perform a Local Reactivation
**To perform a local reactivation**
-
1. Open VAMT. Make sure that you are connected to the desired database.
-
2. In the left-side pane, click the product you want to reactivate to display the products list.
-
3. In the product list view in the center pane, select the desired products to be reactivated. You can sort the list by computer name by clicking on the **Computer Name** heading. You can also use the **Filter** function to narrow your search for computers by clicking **Filter** in the right-side pane to open the **Filter Products** dialog box.
-
4. In the **Filter Products** dialog box, you can filter the list by computer name, product name, product key type, license status, or by any combination of these options.
-
- To filter the list by computer name, enter a name in the **Computer Name** box.
-
- To filter the list by Product Name, Product Key Type, or License Status, click the list you want to use for the filter and select an option. If necessary, click **clear all filters** to create a new filter.
-
5. Click **Filter**. VAMT displays the filtered list in the center pane.
-
6. In the right-side pane, click **Activate**, and then click **Apply Confirmation ID**.
-
7. Click a credential option. Choose **Alternate credentials** only if you are reactivating products that require administrator credentials different from the ones you are currently using.
-
8. If you are supplying alternate credentials, in the **Windows Security** dialog box type the appropriate user name and password and click **OK**.
VAMT displays the **Apply Confirmation ID** dialog box.
10. If you are using a different product key than the product key used for initial activation, you must complete a new activation to obtain a new CID.
-
11. If you are activating a product that requires administrator credentials different from the ones you are currently using, select the **Use Alternate Credentials** check box.
-
12. Click **OK**.
## Related topics
-- [Manage Activations](manage-activations-vamt.md)
\ No newline at end of file
+
+- [Manage Activations](manage-activations-vamt.md)
diff --git a/windows/deploy/manage-activations-vamt.md b/windows/deploy/manage-activations-vamt.md
index 45355c6033..1f15048dea 100644
--- a/windows/deploy/manage-activations-vamt.md
+++ b/windows/deploy/manage-activations-vamt.md
@@ -5,10 +5,12 @@ ms.assetid: 53bad9ed-9430-4f64-a8de-80613870862c
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Manage Activations
+
This section describes how to activate a client computer, by using a variety of activation methods.
## In this Section
@@ -21,14 +23,6 @@ This section describes how to activate a client computer, by using a variety of
|[Perform Local Reactivation](local-reactivation-vamt.md) |Describes how to reactivate an operating system or Office program that was reinstalled. |
|[Activate an Active Directory Forest Online](activate-forest-vamt.md) |Describes how to use Active Directory-Based Activation to online activate an Active Directory forest. |
|[Activate by Proxy an Active Directory Forest](activate-forest-by-proxy-vamt.md) |Describes how to use Active Directory-Based Activation to proxy activate an Active Directory forest that is not connected to the Internet. |
-
-
-
-
-
-
-
-
diff --git a/windows/deploy/manage-product-keys-vamt.md b/windows/deploy/manage-product-keys-vamt.md
index 0d97b1fce6..fffe5de77e 100644
--- a/windows/deploy/manage-product-keys-vamt.md
+++ b/windows/deploy/manage-product-keys-vamt.md
@@ -5,12 +5,13 @@ ms.assetid: 4c6c4216-b4b7-437c-904e-4cb257f913cd
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Manage Product Keys
-This section describes how to add and remove a product key from the Volume Activation Management Tool (VAMT). After you add a product key to VAMT, you can install that product key on a product or products you select in the VAMT database.
+This section describes how to add and remove a product key from the Volume Activation Management Tool (VAMT). After you add a product key to VAMT, you can install that product key on a product or products you select in the VAMT database.
## In this Section
|Topic |Description |
@@ -19,12 +20,5 @@ This section describes how to add and remove a product key from the Volume Activ
|[Install a Product Key](install-product-key-vamt.md) |Describes how to install a product key for specific product. |
|[Install a KMS Client Key](install-kms-client-key-vamt.md) |Describes how to install a GVLK (KMS client) key. |
-
-
-
-
-
-
-
diff --git a/windows/deploy/manage-vamt-data.md b/windows/deploy/manage-vamt-data.md
index ce2e7dc5ca..adbd4c4ec6 100644
--- a/windows/deploy/manage-vamt-data.md
+++ b/windows/deploy/manage-vamt-data.md
@@ -5,15 +5,16 @@ ms.assetid: 233eefa4-3125-4965-a12d-297a67079dc4
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Manage VAMT Data
+
This section describes how to save, import, export, and merge a Computer Information List (CILX) file using the Volume Activation Management Tool (VAMT).
## In this Section
-
|Topic |Description |
|------|------------|
|[Import and Export VAMT Data](import-export-vamt-data.md) |Describes how to import and export VAMT data. |
-|[Use VAMT in Windows PowerShell](use-vamt-in-windows-powershell.md) |Describes how to access Windows PowerShell and how to import the VAMT PowerShell module. |
\ No newline at end of file
+|[Use VAMT in Windows PowerShell](use-vamt-in-windows-powershell.md) |Describes how to access Windows PowerShell and how to import the VAMT PowerShell module. |
diff --git a/windows/deploy/mdt-2013-lite-touch-components.md b/windows/deploy/mdt-2013-lite-touch-components.md
index 580575314a..6766bdc104 100644
--- a/windows/deploy/mdt-2013-lite-touch-components.md
+++ b/windows/deploy/mdt-2013-lite-touch-components.md
@@ -2,22 +2,20 @@
title: MDT 2013 Update 2 Lite Touch components (Windows 10)
description: This topic provides an overview of the features in the Microsoft Deployment Toolkit (MDT) 2013 Update 2 that support Lite Touch Installation (LTI) for Windows 10.
ms.assetid: 7d6fc159-e338-439e-a2e6-1778d0da9089
-keywords: ["deploy, install, deployment, boot, log, monitor"]
+keywords: deploy, install, deployment, boot, log, monitor
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: mdt
author: mtniehaus
---
# MDT 2013 Update 2 Lite Touch components
-
**Applies to**
-
- Windows 10
This topic provides an overview of the features in the Microsoft Deployment Toolkit (MDT) 2013 Update 2 that support Lite Touch Installation (LTI) for Windows 10. An LTI deployment strategy requires very little infrastructure or user interaction, and can be used to deploy an operating system from a network share or from a physical media, such as a USB flash drive or disc.
-
When deploying the Windows operating system using MDT, most of the administration and configuration is done through the Deployment Workbench, but you also can perform many of the tasks using Windows PowerShell. The easiest way to find out how to use PowerShell in MDT is to use the Deployment Workbench to perform an operation and at the end of that task, click View Script. That will give you the PowerShell command.
@@ -26,22 +24,15 @@ Figure 4. If you click **View Script** on the right side, you will get the Power
## Deployment shares
-
A deployment share is essentially a folder on the server that is shared and contains all the setup files and scripts needed for the deployment solution. It also holds the configuration files (called rules) that are gathered when a machine is deployed. These configuration files can reach out to other sources, like a database, external script, or web server to get additional settings for the deployment. For Lite Touch deployments, it is common to have two deployment shares: one for creating the reference images and one for deployment. For Zero Touch, it is common to have only the deployment share for creating reference images because Microsoft System Center 2012 R2 Configuration Manager deploys the image in the production environment.
## Rules
-
The rules (CustomSettings.ini and Bootstrap.ini) make up the brain of MDT. The rules control the Windows Deployment Wizard on the client and, for example, can provide the following settings to the machine being deployed:
-
- Computer name
-
- Domain to join, and organizational unit (OU) in Active Directory to hold the computer object
-
- Whether to enable BitLocker
-
- Regional settings
-
You can manage hundreds of settings in the rules. For more information, see the [Microsoft Deployment Toolkit resource center](http://go.microsoft.com/fwlink/p/?LinkId=618117).
@@ -50,118 +41,78 @@ Figure 5. Example of a MDT rule. In this example, the new computer name is being
## Boot images
-
-Boot images are the Windows Preinstallation Environment (Windows PE) images that are used to start the deployment. They can be started from a CD or DVD, an ISO file, a USB device, or over the network using a Pre-Boot Execution Environment (PXE) server. The boot images connect to the deployment share on the server and start the deployment.
+Boot images are the Windows Preinstallation Environment (Windows PE) images that are used to start the deployment. They can be started from a CD or DVD, an ISO file, a USB device, or over the network using a Pre-Boot Execution Environment (PXE) server. The boot images connect to the deployment
+share on the server and start the deployment.
## Operating systems
-
Using the Deployment Workbench, you import the operating systems you want to deploy. You can import either the full source (like the full Windows 10 DVD/ISO) or a custom image that you have created. The full-source operating systems are primarily used to create reference images; however, they also can be used for normal deployments.
## Applications
-
Using the Deployment Workbench, you also add the applications you want to deploy. MDT supports virtually every executable Windows file type. The file can be a standard .exe file with command-line switches for an unattended install, a Microsoft Windows Installer (MSI) package, a batch file, or a VBScript. In fact, it can be just about anything that can be executed unattended. MDT also supports the new Universal Windows apps.
## Driver repository
-
You also use the Deployment Workbench to import the drivers your hardware needs into a driver repository that lives on the server, not in the image.
## Packages
-
With the Deployment Workbench, you can add any Microsoft packages that you want to use. The most commonly added packages are language packs, and the Deployment Workbench Packages node works well for those. You also can add security and other updates this way. However, we generally recommend that you use Windows Server Update Services (WSUS) for operating system updates. The rare exceptions are critical hotfixes that are not available via WSUS, packages for the boot image, or any other package that needs to be deployed before the WSUS update process starts.
## Task sequences
-
Task sequences are the heart and soul of the deployment solution. When creating a task sequence, you need to select a template. The templates are located in the Templates folder in the MDT installation directory, and they determine which default actions are present in the sequence.
You can think of a task sequence as a list of actions that need to be executed in a certain order. Each action can also have conditions. Some examples of actions are as follows:
-
- **Gather.** Reads configuration settings from the deployment server.
-
- **Format and Partition.** Creates the partition(s) and formats them.
-
- **Inject Drivers.** Finds out which drivers the machine needs and downloads them from the central driver repository.
-
- **Apply Operating System.** Uses ImageX to apply the image.
-
- **Windows Update.** Connects to a WSUS server and updates the machine.
## Task sequence templates
-
MDT comes with nine default task sequence templates. You can also create your own templates. As long as you store them in the Templates folder, they will be available when you create a new task sequence.
-
- **Sysprep and Capture task sequence.** Used to run the System Preparation (Sysprep) tool and capture an image of a reference computer.
**Note**
It is preferable to use a complete build and capture instead of the Sysprep and Capture task sequence. A complete build and capture can be automated, whereas Sysprep and Capture cannot.
-
-
- **Standard Client task sequence.** The most frequently used task sequence. Used for creating reference images and for deploying clients in production.
-
- **Standard Client Replace task sequence.** Used to run User State Migration Tool (USMT) backup and the optional full Windows Imaging (WIM) backup action. Can also be used to do a secure wipe of a machine that is going to be decommissioned.
-
- **Custom task sequence.** As the name implies, a custom task sequence with only one default action (one Install Application action).
-
- **Standard Server task sequence.** The default task sequence for deploying operating system images to servers. The main difference between this template and the Standard Client task sequence template is that it does not contain any USMT actions because USMT is not supported on servers.
-
- **Lite Touch OEM task sequence.** Used to preload operating systems images on the computer hard drive. Typically used by computer original equipment manufacturers (OEMs) but some enterprise organizations also use this feature.
-
- **Post OS Installation task sequence.** A task sequence prepared to run actions after the operating system has been deployed. Very useful for server deployments but not often used for client deployments.
-
- **Deploy to VHD Client task sequence.** Similar to the Standard Client task sequence template but also creates a virtual hard disk (VHD) file on the target computer and deploys the image to the VHD file.
-
- **Deploy to VHD Server task sequence.** Same as the Deploy to VHD Client task sequence but for servers.
-
- **Standard Client Upgrade task sequence.** A simple task sequence template used to perform an in-place upgrade from Windows 7, Windows 8, or Windows 8.1 directly to Windows 10, automatically preserving existing data, settings, applications, and drivers.
## Selection profiles
-
Selection profiles, which are available in the Advanced Configuration node, provide a way to filter content in the Deployment Workbench. Selection profiles are used for several purposes in the Deployment Workbench and in Lite Touch deployments. For example, they can be used to:
-
- Control which drivers and packages are injected into the Lite Touch (and generic) boot images.
-
- Control which drivers are injected during the task sequence.
-
- Control what is included in any media that you create.
-
- Control what is replicated to other deployment shares.
-
- Filter which task sequences and applications are displayed in the Deployment Wizard.
## Logging
-
MDT uses many log files during operating system deployments. By default the logs are client side, but by configuring the deployment settings, you can have MDT store them on the server, as well.
**Note**
The easiest way to view log files is to use Configuration Manager Trace (CMTrace), which is included in the [System Center 2012 R2 Configuration Manager Toolkit](http://go.microsoft.com/fwlink/p/?LinkId=734717).
-
-
## Monitoring
-
On the deployment share, you also can enable monitoring. After you enable monitoring, you will see all running deployments in the Monitor node in the Deployment Workbench.
## Related topics
-
[Key features in MDT 2013 Update 2](key-features-in-mdt-2013.md)
[Prepare for deployment with MDT 2013 Update 2](prepare-for-windows-deployment-with-mdt-2013.md)
-
-
-
-
-
-
-
diff --git a/windows/deploy/monitor-activation-client.md b/windows/deploy/monitor-activation-client.md
index bd48f813f0..5a3050cb0b 100644
--- a/windows/deploy/monitor-activation-client.md
+++ b/windows/deploy/monitor-activation-client.md
@@ -2,16 +2,17 @@
title: Monitor activation (Windows 10)
ms.assetid: 264a3e86-c880-4be4-8828-bf4c839dfa26
description:
-keywords: ["vamt", "volume activation", "activation", "windows activation"]
+keywords: vamt, volume activation, activation, windows activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: CFaw
---
# Monitor activation
-**Applies to**
+**Applies to**
- Windows 10
- Windows 8.1
- Windows 8
@@ -25,27 +26,15 @@ author: CFaw
- [Get Help Activating Microsoft Windows](http://go.microsoft.com/fwlink/p/?LinkId=618644)
You can monitor the success of the activation process for a computer running Windows 8.1 in several ways. The most popular methods include:
-
- Using the Volume Licensing Service Center website to track use of MAK keys.
-
- Using the **Slmgr /dlv** command on a client computer or on the KMS host. (For a full list of options, see [Slmgr.vbs Options](http://technet.microsoft.com/library/ff793433.aspx).)
-
- Viewing the licensing status, which is exposed through Windows Management Instrumentation (WMI); therefore, it is available to non-Microsoft or custom tools that can access WMI. (Windows PowerShell can also access WMI information.)
-
- Most licensing actions and events are recorded in the Event log.
-
- Microsoft System Center Operations Manager and the KMS Management Pack can provide insight and information to users of System Center Operations Manager.
-
- The VAMT provides a single site from which to manage and monitor volume activations. This is explained in the next section.
## See also
+
- [Volume Activation for Windows 10](volume-activation-windows-10.md)
-
-
-
-
-
-
-
diff --git a/windows/deploy/online-activation-vamt.md b/windows/deploy/online-activation-vamt.md
index 233b91c84b..5f537d3e20 100644
--- a/windows/deploy/online-activation-vamt.md
+++ b/windows/deploy/online-activation-vamt.md
@@ -5,46 +5,37 @@ ms.assetid: 8381792b-a454-4e66-9b4c-e6e4c9303823
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Perform Online Activation
+
You can use the Volume Activation Management Tool (VAMT) to enable client products to be activated over the Internet. You can install the client products with any kind of product key that is eligible for online activation—Multiple Activation Key (MAK), retail, and Windows Key Management Services (KMS) host key.
## Requirements
+
Before performing online activation, ensure that the network and the VAMT installation meet the following requirements:
-
- VAMT is installed on a central computer that has network access to all client computers.
-
- Both the VAMT host and client computers have Internet access.
-
- The products that you want to activate are added to VAMT.
-
- VAMT has administrative permissions on all computers that you intend to activate, and that Windows Management Instrumentation (WMI) can be accessed through the Windows firewall. For more information, see [Configure Client Computers](configure-client-computers-vamt.md).
-The product keys that are installed on the client products must have a sufficient number of remaining activations. If you are activating a MAK key, you can retrieve the remaining number of activations for that key by selecting the MAK in the product key list in the center pane and then clicking **Refresh product key data online** in the right-side pane. This retrieves the number of remaining activations for the MAK from Microsoft. Note that this step requires Internet access and that the remaining activation count can only be retrieved for MAKs.
+The product keys that are installed on the client products must have a sufficient number of remaining activations. If you are activating a MAK key, you can retrieve the remaining number of activations for that key by selecting the MAK in the product key list in the center pane and then clicking
+**Refresh product key data online** in the right-side pane. This retrieves the number of remaining activations for the MAK from Microsoft. Note that this step requires Internet access and that the remaining activation count can only be retrieved for MAKs.
## To Perform an Online Activation
+
**To perform an online activation**
-
1. Open VAMT.
-
2. In the products list view in the center pane, sort the list if necessary. You can use the **Filter** function to narrow your search for computers by clicking **Filter** in the right-side pane to open the **Filter Products** dialog box.
-
3. In the **Filter Products** dialog box, you can filter the list by computer name, product name, product key type, license status, or by any combination of these options.
-
- To filter the list by computer name, enter a name in the **Computer Name** box.
-
- To filter the list by Product Name, Product Key Type, or License Status, click the list you want to use for the filter and select an option. If necessary, click **clear all filters** to create a new filter.
-
4. Click **Filter**. VAMT displays the filtered list in the center pane.
-
5. Select the products that you want to activate. You can use the **CTRL** key or the **SHIFT** key to select more than one product.
-
6. Click **Activate** in the **Selected Items** menu in the right-side **Actions** pane and then point to **Activate**. If the **Actions** pane is not displayed, click the Show/Hide Action Pane button, which is located on the toolbar to the right of the Help button.
-
7. Point to **Online activate**, and then select the appropriate credential option. If you click the **Alternate Credentials** option, you will be prompted to enter an alternate user name and password.
-
8. VAMT displays the **Activating products** dialog box until it completes the requested action. When activation is complete, the status appears in the **Action Status** column of the dialog box. Click **Close** to close the dialog box. You can also click the **Automatically close when done** check box when the dialog box appears.
The same status is shown under the **Status of Last Action** column in the products list view in the center pane.
@@ -56,4 +47,4 @@ The product keys that are installed on the client products must have a sufficien
You can use online activation to select products that have different key types and activate the products at the same time.
## Related topics
-- [Manage Activations](manage-activations-vamt.md)
\ No newline at end of file
+- [Manage Activations](manage-activations-vamt.md)
diff --git a/windows/deploy/plan-for-volume-activation-client.md b/windows/deploy/plan-for-volume-activation-client.md
index 6a396d19f6..3247677c72 100644
--- a/windows/deploy/plan-for-volume-activation-client.md
+++ b/windows/deploy/plan-for-volume-activation-client.md
@@ -2,16 +2,17 @@
title: Plan for volume activation (Windows 10)
description: Product activation is the process of validating software with the manufacturer after it has been installed on a specific computer.
ms.assetid: f84b005b-c362-4a70-a84e-4287c0d2e4ca
-keywords: ["vamt", "volume activation", "activation", "windows activation"]
+keywords: vamt, volume activation, activation, windows activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Plan for volume activation
-**Applies to**
+**Applies to**
- Windows 10
- Windows 8.1
- Windows 8
@@ -32,64 +33,60 @@ During the activation process, information about the specific installation is ex
The IP address is used only to verify the location of the request, because some editions of Windows (such as “Starter” editions) can only be activated within certain geographical target markets.
## Distribution channels and activation
+
In general, Microsoft software is obtained through three main channels: retail, original equipment manufacturer (OEM), and volume licensing agreements. Different activations methods are available through each channel. Because organizations are free to obtain software through multiple channels (for example, buying some at retail and others through a volume licensing program) most organizations choose to use a combination of activation methods.
### Retail activations
-The retail activation method has not changed in several versions of Windows and Windows Server. Each purchased copy comes with one unique product key (often referred to as a retail key). The user enters this key during product installation. The computer uses this retail key to complete the activation after the installation is complete. Most activations are performed online, but telephone activation is also available.
+The retail activation method has not changed in several versions of Windows and Windows Server. Each purchased copy comes with one unique product key (often referred to as a retail key). The user enters this key during product installation. The computer uses this retail key to complete the activation after the installation is complete. Most activations are performed online, but telephone activation is also available.
Recently, retail keys have been expanded into new distribution scenarios. Product key cards are available to activate products that have been preinstalled or downloaded. Programs such as Windows Anytime Upgrade and Get Genuine allow users to acquire legal keys separately from the software. These electronically distributed keys may come with media that contains software, they can come as a software shipment, or they may be provided on a printed card or electronic copy. Products are activated the same way with any of these retail keys.
### Original equipment manufacturer
-Most original equipment manufacturers (OEMs) sell systems that include a standard build of the Windows operating system. The hardware vendor activates Windows by associating the operating system with the firmware (BIOS) of the computer. This occurs before the computer is sent to the customer, and no additional actions are required.
+Most original equipment manufacturers (OEMs) sell systems that include a standard build of the Windows operating system. The hardware vendor activates Windows by associating the operating system with the firmware (BIOS) of the computer. This occurs before the computer is sent to the customer, and no additional actions are required.
OEM activation is valid as long as the customer uses the OEM-provided image on the system. OEM activation is available only for computers that are purchased through OEM channels and have the Windows operating system preinstalled.
### Volume licensing
+
Volume licensing offers customized programs that are tailored to the size and purchasing preference of the organization. To become a volume licensing customer, the organization must set up a volume licensing agreement with Microsoft.There is a common misunderstanding about acquiring licenses for a new computer through volume licensing. There are two legal ways to acquire a full Windows client license for a new computer:
-
- Have the license preinstalled through the OEM.
-
- Purchase a fully packaged retail product.
The licenses that are provided through volume licensing programs such as Open License, Select License, and Enterprise Agreements cover upgrades to Windows client operating systems only. An existing retail or OEM operating system license is needed for each computer running Windows 10, Windows 8.1 Pro, Windows 8 Pro, Windows 7 Professional or Ultimate, or Windows XP Professional before the upgrade rights obtained through volume licensing can be exercised.
-
Volume licensing is also available through certain subscription or membership programs, such as the Microsoft Partner Network and MSDN. These volume licenses may contain specific restrictions or other changes to the general terms applicable to volume licensing.
**Note**
Some editions of the operating system, such as Windows 10 Enterprise, and some editions of application software are available only through volume licensing agreements or subscriptions.
## Activation models
+
For a user or IT department, there are no significant choices about how to activate products that are acquired through retail or OEM channels. The OEM performs the activation at the factory, and the user or the IT department need take no activation steps.
With a retail product, the Volume Activation Management Tool (VAMT), which is discussed later in this guide, helps you track and manage keys. For each retail activation, you can choose:
-
- Online activation
-
- Telephone activation
-
- VAMT proxy activation
Telephone activation is primarily used in situations where a computer is isolated from all networks. VAMT proxy activation (with retail keys) is sometimes used when an IT department wants to centralize retail activations or when a computer with a retail version of the operating system is isolated from the Internet but connected to the LAN. For volume-licensed products, however, you must determine the best method or combination of methods to use in your environment. For Windows 10 Pro and Enterprise, you can choose from three models:
-
- MAKs
-
- KMS
-
- Active Directory-based activation
**Note**
A specialized method, Token-based activation, is available for specific situations when approved customers rely on a public key infrastructure in a completely isolated, and usually high-security, environment. For more information, contact your Microsoft Account Team or your service representative.
### Multiple activation key
-A Multiple Activation Key (MAK) is commonly used in small- or mid-sized organizations that have a volume licensing agreement, but they do not meet the requirements to operate a KMS or they prefer a simpler approach. A MAK also allows permanent activation of computers that are isolated from the KMS or are part of an isolated network that does not have enough computers to use the KMS.
+
+A Multiple Activation Key (MAK) is commonly used in small- or mid-sized organizations that have a volume licensing agreement, but they do not meet the requirements to operate a KMS or they prefer a simpler approach. A MAK also
+allows permanent activation of computers that are isolated from the KMS or are part of an isolated network that does not have enough computers to use the KMS.
To use a MAK, the computers to be activated must have a MAK installed. The MAK is used for one-time activation with the Microsoft online hosted activation services, by telephone, or by using VAMT proxy activation.
-
In the simplest terms, a MAK acts like a retail key, except that a MAK is valid for activating multiple computers. Each MAK can be used a specific number of times. The VAMT can assist in tracking the number of activations that have been performed with each key and how many remain.
Organizations can download MAK and KMS keys from the [Volume Licensing Service Center](http://go.microsoft.com/fwlink/p/?LinkId=618213) website. Each MAK has a preset number of activations, which are based on a percentage of the count of licenses the organization purchases; however, you can increase the number of activations that are available with your MAK by calling Microsoft.
### Key Management Service
+
With the Key Management Service (KMS), IT pros can complete activations on their local network, eliminating the need for individual computers to connect to Microsoft for product activation. The KMS is a lightweight service that does not require a dedicated system and can easily be cohosted on a system that provides other services.
Volume editions of Windows 10 and Windows Server 2012 R2 (in addition to volume editions of operating system editions since Windows Vista and Windows Server 2008) automatically connect to a system that hosts the KMS to request activation. No action is required from the user.
@@ -99,14 +96,17 @@ The KMS requires a minimum number of computers (physical computers or virtual ma
Planning to use the KMS includes selecting the best location for the KMS host and how many KMS hosts to have. One KMS host can handle a large number of activations, but organizations will often deploy two KMS hosts to ensure availability. Only rarely would more than two KMS hosts be used. The KMS can be hosted on a client computer or on a server, and it can be run on older versions of the operating system if proper configuration steps are taken. Setting up your KMS is discussed later in this guide.
### Active Directory-based activation
+
Active Directory-based activation is the newest type of volume activation, and it was introduced in Windows 8. In many ways, Active Directory-based activation is similar to activation by using the KMS, but the activated computer does not need to maintain periodic connectivity with the KMS host. Instead, a domain-joined computer running Windows 10, Windows 8.1, Windows 8, Windows Server 2012 R2, or Windows Server 2012 R2 queries AD DS for a volume activation object that is stored in the domain. The operating system checks the digital signatures that are contained in the activation object, and then activates the device.
Active Directory-based activation allows enterprises to activate computers through a connection to their domain. Many companies have computers at remote or branch locations, where it is impractical to connect to a KMS, or would not reach the KMS activation threshold. Rather than use MAKs, Active Directory-based activation provides a way to activate computers running Windows 10, Windows 8.1, Windows 8, Windows Server 2012 R2, or Windows Server 2012 R2 as long as the computers can contact the company’s domain. Active Directory-based activation offers the advantage of extending volume activation services everywhere you already have a domain presence.
## Network and connectivity
+
A modern business network has many nuances and interconnections. This section examines evaluating your network and the connections that are available to determine how volume activations will occur.
### Core network
+
Your core network is that part of your network that enjoys stable, high-speed, reliable connectivity to infrastructure servers. In many cases, the core network is also connected to the Internet, although that is not a requirement to use the KMS or Active Directory-based activation after the KMS server or AD DS is configured and active. Your core network likely consists of many network segments. In many organizations, the core network makes up the vast majority of the business network.
In the core network, a centralized KMS solution is usually recommended. You can also use Active Directory-based activation, but in many organizations, KMS will still be required to activate older client computers and computers that are not joined to the domain. Some administrators prefer to run both solutions to have the most flexibility, while others prefer to choose only a KMS-based solution for simplicity. Active Directory-based activation as the only solution is workable if all of the clients in your organization are running Windows 10, Windows 8.1, or Windows 8.
@@ -118,9 +118,11 @@ A typical core network that includes a KMS host is shown in Figure 1.
**Figure 1**. Typical core network
### Isolated networks
+
In a large network, it is all but guaranteed that some segments will be isolated, either for security reasons or because of geography or connectivity issues.
-**Isolated for security**
+**Isolated for security**
+
Sometimes called a *high-security zone*, a particular network segment may be isolated from the core network by a firewall or disconnected from other networks totally. The best solution for activating computers in an isolated network depends on the security policies in place in the organization.
If the isolated network can access the core network by using outbound requests on TCP port 1688, and it is allowed to receive remote procedure calls (RPCs), you can perform activation by using the KMS in the core network, thereby avoiding the need to reach additional activation thresholds.
@@ -137,28 +139,24 @@ If the network is fully isolated, MAK-independent activation would be the recomm
**Branch offices and distant networks**
From mining operations to ships at sea, organizations often have a few computers that are not easily connected to the core network or the Internet. Some organizations have network segments at branch offices that are large and well-connected internally, but have a slow or unreliable WAN link to the rest of the organization. In these situations, you have several options:
-
- **Active Directory-based activation**. In any site where the client computers are running Windows 10, Active Directory-based activation is supported, and it can be activated by joining the domain.
-
- **Local KMS**. If a site has 25 or more client computers, it can activate against a local KMS server.
-
- **Remote (core) KMS**. If the remote site has connectivity to an existing KMS (perhaps through a virtual private network (VPN) to the core network), that KMS can be used. Using the existing KMS means that you only need to meet the activation threshold on that server.
-
- **MAK activation**. If the site has only a few computers and no connectivity to an existing KMS host, MAK activation is the best option.
### Disconnected computers
-Some users may be in remote locations or may travel to many locations. This scenario is common for roaming clients, such as the computers that are used by salespeople or other users who are offsite but not at branch locations. This scenario can also apply to remote branch office locations that have no connection to the core network. You can consider this an “isolated network,” where the number of computers is one. Disconnected computers can use Active Directory-based activation, the KMS, or MAK depending on the client version and how often the computers connect to the core network.
+Some users may be in remote locations or may travel to many locations. This scenario is common for roaming clients, such as the computers that are used by salespeople or other users who are offsite but not at branch locations. This scenario can also apply to remote branch office locations that have no connection to the core network. You can consider this an “isolated network,” where the number of computers is one. Disconnected computers can use Active Directory-based activation, the KMS, or MAK depending on the client version and how often the computers connect to the core network.
If the computer is joined to the domain and running Windows 10, Windows 8.1, Windows 8, Windows Server 2012 R2, or Windows Server 2012 R2 8, you can use Active Directory-based activation—directly or through a VPN—at least once every 180 days. If the computer connects to a network with a KMS host at least every 180 days, but it does not support Active Directory-based activation, you can use KMS activation. Otherwise for computers that rarely or never connect to the network, use MAK independent activation (by using the telephone or the Internet).
### Test and development labs
+
Lab environments often have large numbers of virtual machines, and physical computers and virtual machines in labs are reconfigured frequently. Therefore, first determine whether the computers in test and development labs require activation. Editions of Windows 10 that include volume licensing will operate normally, even if they cannot activate immediately.
-
If you have ensured that your test or development copies of the operating system are within the license agreement, you may not need to activate the lab computers if they will be rebuilt frequently. If you require that the lab computers be activated, treat the lab as an isolated network and use the methods described earlier in this guide.
-
In labs that have a high turnover of computers and a small number of KMS clients, you must monitor the KMS activation count. You might need to adjust the time that the KMS caches the activation requests. The default is 30 days.
## Mapping your network to activation methods
+
Now it’s time to assemble the pieces into a working solution. By evaluating your network connectivity, the numbers of computers you have at each site, and the operating system versions in use in your environment, you have collected the information you need to determine which activation methods will work best for you. You can fill-in information in Table 1 to help you make this determination.
**Table 1**. Criteria for activation methods
@@ -174,21 +172,22 @@ Now it’s time to assemble the pieces into a working solution. By evaluating yo
|Number of computers in test and development labs that will not be activated |None|
|Number of computers that do not have a retail volume license |Retail (online or phone) |
|Number of computers that do not have an OEM volume license |OEM (at factory) |
-|Total number of computer activations
Note
This total should match the total number of licensed computers in your organization. | |
+|Total number of computer activations
Note
This total should match the total number of licensed computers in your organization. |
## Choosing and acquiring keys
+
When you know which keys you need, you must obtain them. Generally speaking, volume licensing keys are collected in two ways:
-
- Go to the **Product Keys** section of the [Volume Licensing Service Center](http://go.microsoft.com/fwlink/p/?LinkID=618213) for the following agreements: Open, Open Value, Select, Enterprise, and Services Provider License.
-
- Contact your [Microsoft Activation Center](http://go.microsoft.com/fwlink/p/?LinkId=618264).
### KMS host keys
+
A KMS host needs a key that activates, or authenticates, the KMS host with Microsoft. This key is usually referred to as the *KMS host key*, but it is formally known as a *Microsoft Customer Support Volume License Key* (CSVLK). Most documentation and Internet references earlier than Windows 8.1 use the term KMS key, but CSVLK is becoming more common in current documentation and management tools.
A KMS host running Windows Server 2012 R2, Windows Server 2012, or Windows Server 2008 R2 can activate both Windows Server and Windows client operating systems. A KMS host key is also needed to create the activation objects in AD DS, as described later in this guide. You will need a KMS host key for any KMS that you want to set up and if you are going to use Active Directory-based activation.
### Generic volume licensing keys
+
When you create installation media or images for client computers that will be activated by KMS or Active Directory-based activation, install a generic volume license key (GVLK) for the edition of Windows you are creating. GVLKs are also referred to as KMS client setup keys.
Installation media from Microsoft for Enterprise editions of the Windows operating system may already contain the GVLK. One GVLK is available for each type of installation. Note that the GLVK will not activate the software against Microsoft activation servers, only against a KMS or Active Directory-based activation object. In other words, the GVLK does not work unless a valid KMS host key can be found. GVLKs are the only product keys that do not need to be kept confidential.
@@ -196,31 +195,24 @@ Installation media from Microsoft for Enterprise editions of the Windows operati
Typically, you will not need to manually enter a GVLK unless a computer has been activated with a MAK or a retail key and it is being converted to a KMS activation or to Active Directory-based activation. If you need to locate the GVLK for a particular client edition, see [Appendix A: KMS Client Setup Keys](http://technet.microsoft.com/library/jj612867.aspx).
### Multiple activation keys
+
You will also need MAK keys with the appropriate number of activations available. You can see how many times a MAK has been used on the Volume Licensing Service Center website or in the VAMT.
## Selecting a KMS host
+
The KMS does not require a dedicated server. It can be cohosted with other services, such as AD DS domain controllers and read-only domain controllers.
-
KMS hosts can run on physical computers or virtual machines that are running any supported Windows operating system. A KMS host that is running Windows Server 2012 R2, Windows Server 2012, or Windows Server 2008 R2 can activate any Windows client or server operating system that supports volume activation. A KMS host that is running Windows 10 can activate only computers running Windows 10, Windows 8.1, Windows 8, Windows 7, or Windows Vista.
-
A single KMS host can support unlimited numbers of KMS clients, but Microsoft recommends deploying a minimum of two KMS hosts for failover purposes. However, as more clients are activated through Active Directory-based activation, the KMS and the redundancy of the KMS will become less important. Most organizations can use as few as two KMS hosts for their entire infrastructure.
The flow of KMS activation is shown in Figure 3, and it follows this sequence:
1. An administrator uses the VAMT console to configure a KMS host and install a KMS host key.
-
2. Microsoft validates the KMS host key, and the KMS host starts to listen for requests.
-
3. The KMS host updates resource records in DNS to allow clients to locate the KMS host. (Manually adding DNS records is required if your environment does not support DNS dynamic update protocol.)
-
4. A client configured with a GVLK uses DNS to locate the KMS host.
-
5. The client sends one packet to the KMS host.
-
6. The KMS host records information about the requesting client (by using a client ID). Client IDs are used to maintain the count of clients and detect when the same computer is requesting activation again. The client ID is only used to determine whether the activation thresholds are met. The IDs are not stored permanently or transmitted to Microsoft. If the KMS is restarted, the client ID collection starts again.
-
7. If the KMS host has a KMS host key that matches the products in the GVLK, the KMS host sends a single packet back to the client. This packet contains a count of the number of computers that have requested activation from this KMS host.
-
8. If the count exceeds the activation threshold for the product that is being activated, the client is activated. If the activation threshold has not yet been met, the client will try again.
@@ -229,12 +221,5 @@ The flow of KMS activation is shown in Figure 3, and it follows this sequence:
## See also
- [Volume Activation for Windows 10](volume-activation-windows-10.md)
-
-
-
-
-
-
-
diff --git a/windows/deploy/prepare-for-windows-deployment-with-mdt-2013.md b/windows/deploy/prepare-for-windows-deployment-with-mdt-2013.md
index 19e866a468..a7b98b2ab3 100644
--- a/windows/deploy/prepare-for-windows-deployment-with-mdt-2013.md
+++ b/windows/deploy/prepare-for-windows-deployment-with-mdt-2013.md
@@ -2,18 +2,17 @@
title: Prepare for deployment with MDT 2013 Update 2 (Windows 10)
description: This topic will walk you through the steps necessary to create the server structure required to deploy the Windows 10 operating system using the Microsoft Deployment Toolkit (MDT) 2013 Update 2.
ms.assetid: 5103c418-0c61-414b-b93c-a8e8207d1226
-keywords: ["deploy, system requirements"]
+keywords: deploy, system requirements
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: mdt
author: mtniehaus
---
# Prepare for deployment with MDT 2013 Update 2
-
**Applies to**
-
- Windows 10
This topic will walk you through the steps necessary to create the server structure required to deploy the Windows 10 operating system using the Microsoft Deployment Toolkit (MDT) 2013 Update 2. It covers the installation of the necessary system prerequisites, the creation of shared folders and service accounts, and the configuration of security permissions in the files system and in Active Directory.
@@ -22,88 +21,52 @@ For the purposes of this topic, we will use two machines: DC01 and MDT01. DC01 i
## System requirements
-
MDT 2013 Update 2 requires the following components:
-
- Any of the following operating systems:
-
- Windows 7
-
- Windows 8
-
- Windows 8.1
-
- Windows 10
-
- Windows Server 2008 R2
-
- Windows Server 2012
-
- Windows Server 2012 R2
-
- Windows Assessment and Deployment Kit (ADK) for Windows 10
-
- Windows PowerShell
-
- Microsoft .NET Framework
## Install Windows ADK for Windows 10
-
These steps assume that you have the MDT01 member server installed and configured and that you have downloaded [Windows ADK for Windows 10](http://go.microsoft.com/fwlink/p/?LinkId=526803) to the E:\\Downloads\\ADK folder.
-
1. On MDT01, log on as Administrator in the CONTOSO domain using a password of **P@ssw0rd**.
-
2. Start the **ADK Setup** (E:\\Downloads\\ADK\\adksetup.exe), and on the first wizard page, click **Continue**.
-
3. On the **Select the features you want to change** page, select the features below and complete the wizard using the default settings:
-
1. Deployment Tools
-
2. Windows Preinstallation Environment (Windows PE)
-
3. User State Migration Tool (UMST)
## Install MDT 2013 Update 2
-
These steps assume that you have downloaded [MDT 2013 Update 2](http://go.microsoft.com/fwlink/p/?LinkId=618117 ) to the E:\\Downloads\\MDT 2013 folder on MDT01.
1. On MDT01, log on as Administrator in the CONTOSO domain using a password of **P@ssw0rd**.
-
2. Install **MDT** (E:\\Downloads\\MDT 2013\\MicrosoftDeploymentToolkit2013\_x64.msi) with the default settings.
## Create the OU structure
-
If you do not have an organizational unit (OU) structure in your Active Directory, you should create one. In this section, you create an OU structure and a service account for MDT 2013 Update 2.
-
1. On DC01, using Active Directory User and Computers, in the contoso.com domain level, create a top-level OU named **Contoso**.
-
2. In the **Contoso** OU, create the following OUs:
-
1. Accounts
-
2. Computers
-
3. Groups
-
3. In the **Contoso / Accounts** OU, create the following underlying OUs:
-
1. Admins
-
2. Service Accounts
-
3. Users
-
4. In the **Contoso / Computers** OU, create the following underlying OUs:
-
1. Servers
-
2. Workstations
-
5. In the **Contoso / Groups** OU, create the following OU:
-
- Security Groups
@@ -112,34 +75,22 @@ Figure 6. A sample of how the OU structure will look after all the OUs are creat
## Create the MDT service account
-
When creating a reference image, you need an account for MDT. The MDT Build Account is used for Windows Preinstallation Environment (Windows PE) to connect to MDT01.
-
1. On DC01, using Active Directory User and Computers, browse to **contoso.com / Contoso / Service Accounts**.
-
2. Select the **Service Accounts** OU and create the **MDT\_BA** account using the following settings:
-
1. Name: MDT\_BA
-
2. User logon name: MDT\_BA
-
3. Password: P@ssw0rd
-
4. User must change password at next logon: Clear
-
5. User cannot change password: Selected
-
6. Password never expires: Selected
## Create and share the logs folder
-
By default MDT stores the log files locally on the client. In order to capture a reference image, you will need to enable server-side logging and, to do that, you will need to have a folder in which to store the logs. For more information, see [Create a Windows 10 reference image](create-a-windows-10-reference-image.md).
1. On MDT01, log on as **CONTOSO\\Administrator**.
-
2. Create and share the **E:\\Logs** folder by running the following commands in an elevated Windows PowerShell prompt:
-
``` syntax
New-Item -Path E:\Logs -ItemType directory
New-SmbShare ?Name Logs$ ?Path E:\Logs -ChangeAccess EVERYONE
@@ -152,7 +103,6 @@ Figure 7. The Sharing tab of the E:\\Logs folder after sharing it with PowerShel
## Use CMTrace to read log files (optional)
-
The log files in MDT Lite Touch are formatted to be read by Configuration Manager Trace (CMTrace), which is available as part [of Microsoft System Center 2012 R2 Configuration Manager Toolkit](http://go.microsoft.com/fwlink/p/?LinkId=734717). You can use Notepad, but CMTrace formatting makes the logs easier to read.
@@ -161,20 +111,10 @@ Figure 8. An MDT log file opened in Notepad.
+
Figure 9. The same log file, opened in CMTrace, is much easier to read.
-
## Related topics
-
[Key features in MDT 2013 Update 2](key-features-in-mdt-2013.md)
[MDT 2013 Update 2 Lite Touch components](mdt-2013-lite-touch-components.md)
-
-
-
-
-
-
-
-
-
diff --git a/windows/deploy/proxy-activation-vamt.md b/windows/deploy/proxy-activation-vamt.md
index 8866da1596..c848bcd8ab 100644
--- a/windows/deploy/proxy-activation-vamt.md
+++ b/windows/deploy/proxy-activation-vamt.md
@@ -5,10 +5,12 @@ ms.assetid: 35a919ed-f1cc-4d10-9c88-9bd634549dc3
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Perform Proxy Activation
+
You can use the Volume Activation Management Tool (VAMT) to perform activation for client computers that do not have Internet access. The client products can be installed with any type of product key that is eligible for proxy activation: Multiple activation Key (MAK), KMS Host key (CSVLK), or retail key.
In a typical proxy-activation scenario, the VAMT host computer distributes a MAK to one or more client computers and collects the installation ID (IID) from each computer. The VAMT host computer sends the IIDs to Microsoft on behalf of the client computers and obtains the corresponding Confirmation IDs (CIDs). The VAMT host computer then installs the CIDs on the client computer to complete the activation. Using this activation method, only the VAMT host computer needs Internet access.
@@ -17,16 +19,12 @@ In a typical proxy-activation scenario, the VAMT host computer distributes a MAK
For workgroups that are completely isolated from any larger network, you can still perform MAK, KMS Host key (CSVLK), or retail proxy activation. This requires installing a second instance of VAMT on a computer within the isolated group and using removable media to transfer activation data between that computer and another VAMT host computer that has Internet access. For more information about this scenario, see [Scenario 2: Proxy Activation](scenario-proxy-activation-vamt.md). Similarly, you can proxy activate a KMS Host key (CSVLK) located in an isolated network. You can also proxy activate a KMS Host key (CSVLK) in the core network if you do not want the KMS host computer to connect to Microsoft over the Internet.
## Requirements
+
Before performing proxy activation, ensure that your network and the VAMT installation meet the following requirements:
-
- There is an instance of VAMT that is installed on a computer that has Internet access. If you are performing proxy activation for an isolated workgroup, you also need to have VAMT installed on one of the computers in the workgroup.
-
- The products to be activated have been added to VAMT and are installed with a retail product key, a KMS Host key (CSVLK) or a MAK. If the products have not been installed with a proper product key, refer to the steps in the [Add and Remove a Product Key](add-remove-product-key-vamt.md) section for instructions on how to install a product key.
-
- VAMT has administrative permissions on all products to be activated and Windows Management Instrumentation (WMI) is accessible through the Windows firewall.
-
- For workgroup computers, a registry key must be created to enable remote administrative actions under User Account Control (UAC). For more information, see [Configure Client Computers](configure-client-computers-vamt.md).
-
The product keys that are installed on the client products must have a sufficient number of remaining activations. If you are activating a MAK key, you can retrieve the remaining number of activations for that key by selecting the MAK in the product key list in the center pane and then clicking **Refresh product key data online** in the right-side pane. This retrieves the number of remaining activations for the MAK from Microsoft. Note that this step requires Internet access and that the remaining activation count can only be retrieved for MAKs.
## To Perform Proxy Activation
@@ -34,43 +32,22 @@ The product keys that are installed on the client products must have a sufficien
**To perform proxy activation**
1. Open VAMT.
-
2. If necessary, install product keys. For more information see:
-
- [Install a Product Key](install-product-key-vamt.md) to install retail, MAK, or KMS Host key (CSVLK).
-
- [Install a KMS Client Key](install-kms-client-key-vamt.md) to install GVLK (KMS client) keys.
-
3. In the **Products** list in the center pane, select the individual products to be activated. You can use the **Filter** function to narrow your search for products by clicking **Filter** in the right-side pane to open the **Filter Products** dialog box.
-
4. In the **Filter Products** dialog box, you can filter the list by computer name, product name, product key type, license status, or by any combination of these options.
-
- To filter the list by computer name, enter a name in the **Computer Name** box.
-
- To filter the list by Product Name, Product Key Type, or License Status, click the list you want to use for the filter and select an option. If necessary, click **clear all filters** to create a new filter.
-
5. Click **Filter**. VAMT displays the filtered list in the center pane.
-
6. In the right-side pane, click **Activate** and then click **Proxy activate** to open the **Proxy Activate** dialog box.
-
7. In the **Proxy Activate** dialog box click **Apply Confirmation ID, apply to selected machine(s) and activate**.
-
8. If you are activating products that require administrator credentials different from the ones you are currently using, select the **Use Alternate Credentials** checkbox.
-
9. Click **OK**.
-
10. VAMT displays the **Activating products** dialog box until it completes the requested action. If you selected the **Alternate Credentials** option, you will be prompted to enter the credentials.
**Note**
You can use proxy activation to select products that have different key types and activate the products at the same time.
-
-
-
-
-
-
-
-
diff --git a/windows/deploy/refresh-a-windows-7-computer-with-windows-10.md b/windows/deploy/refresh-a-windows-7-computer-with-windows-10.md
index 922ae1219e..70dadf1711 100644
--- a/windows/deploy/refresh-a-windows-7-computer-with-windows-10.md
+++ b/windows/deploy/refresh-a-windows-7-computer-with-windows-10.md
@@ -2,18 +2,17 @@
title: Refresh a Windows 7 computer with Windows 10 (Windows 10)
description: This topic will show you how to use MDT 2013 Update 2 Lite Touch Installation (LTI) to upgrade a Windows 7 computer to a Windows 10 computer using the computer refresh process.
ms.assetid: 2866fb3c-4909-4c25-b083-6fc1f7869f6f
-keywords: ["reinstallation, customize, template, script, restore"]
+keywords: reinstallation, customize, template, script, restore
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: mdt
author: mtniehaus
---
# Refresh a Windows 7 computer with Windows 10
-
**Applies to**
-
- Windows 10
This topic will show you how to use MDT 2013 Update 2 Lite Touch Installation (LTI) to upgrade a Windows 7 computer to a Windows 10 computer using the computer refresh process. The refresh scenario, or computer refresh, is a reinstallation of an operating system on the same machine. You can refresh the machine to the same operating system as it is currently running, or to a later version.
@@ -26,111 +25,74 @@ Figure 1. The machines used in this topic.
## The computer refresh process
-
Even though a computer will appear, to the end user, to be upgraded, a computer refresh is not, technically, an in-place upgrade. A computer refresh also involves taking care of user data and settings from the old installation and making sure to restore those at the end of the installation.
-
For a computer refresh with MDT, you use the User State Migration Tool (USMT), which is part of the Windows Assessment and Deployment Kit (ADK) for Windows 10, to migrate user data and settings. To complete a computer refresh you will:
-
1. Back up data and settings locally, in a backup folder.
-
2. Wipe the partition, except for the backup folder.
-
3. Apply the new operating system image.
-
4. Install other applications.
-
5. Restore data and settings.
-
During the computer refresh, USMT uses a feature called Hard-Link Migration Store. When you use this feature, the files are simply linked in the file system, which allows for fast migration, even when there is a lot of data.
**Note**
In addition to the USMT backup, you can enable an optional full Windows Imaging (WIM) backup of the machine by configuring the MDT rules. If you do this, a .wim file is created in addition to the USMT backup. The .wim file will contain the entire volume from the computer, and helpdesk personnel can extract content from it if needed. Please note that this is a data WIM backup only. Using this backup to restore the entire machine is not a supported scenario.
-
-
### Multi-user migration
-By default, ScanState in USMT backs up all profiles on the machine, including local computer profiles. If you have a machine that has been in your environment for a while, it likely has several domain-based profiles on it, including those of former users. You can limit which profiles are backed up by configuring command-line switches to ScanState (added as rules in MDT).
+By default, ScanState in USMT backs up all profiles on the machine, including local computer profiles. If you have a machine that has been in your environment for a while, it likely has several domain-based profiles on it, including those of former users. You can limit which profiles are backed up
+by configuring command-line switches to ScanState (added as rules in MDT).
As an example, the following line configures USMT to migrate only domain user profiles and not profiles from the local SAM account database: ScanStateArgs=/ue:\*\\\* /ui:CONTOSO\\\*
**Note**
You also can combine the preceding switches with the /uel switch, which excludes profiles that have not been accessed within a specific number of days. For example, adding /uel:60 will configure ScanState (or LoadState) not to include profiles that haven't been accessed for more than 60 days.
-
-
### Support for additional settings
In addition to the command-line switches that control which profiles to migrate, the XML templates control exactly what data is being migrated. You can control data within and outside the user profiles
## Create a custom User State Migration Tool (USMT) template
-
In this section, you learn to migrate additional data using a custom template. You configure the environment to use a custom USMT XML template that will:
-
1. Back up the **C:\\Data** folder (including all files and folders).
-
2. Scan the local disk for PDF documents (\*.pdf files) and restore them into the **C:\\Data\\PDF Documents** folder on the destination machine.
-
The custom USMT template is named MigContosoData.xml, and you can find it in the sample files for this documentation, which include:
-
- [Gather script](http://go.microsoft.com/fwlink/p/?LinkId=619361)
-
- [Set-OUPermissions](http://go.microsoft.com/fwlink/p/?LinkId=619362) script
-
- [MDT Sample Web Service](http://go.microsoft.com/fwlink/p/?LinkId=619363)
### Add the custom XML template
In order to use the custom MigContosoData.xml USMT template, you need to copy it to the MDT Production deployment share and update the CustomSettings.ini file. In these steps, we assume you have downloaded the MigContosoData.xml file.
-
1. Using File Explorer, copy the MigContosoData.xml file to the **E:\\MDTProduction\\Tools\\x64\\USMT5** folder.
-
2. Using Notepad, edit the E:\\MDTProduction\\Control\\CustomSettings.ini file. After the USMTMigFiles002=MigUser.xml line add the following line:
-
``` syntax
USMTMigFiles003=MigContosoData.xml
```
-
3. Save the CustomSettings.ini file.
## Refresh a Windows 7 SP1 client
-
After adding the additional USMT template and configuring the CustomSettings.ini file to use it, you are now ready to refresh a Windows 7 SP1 client to Windows 10. In these steps, we assume you have a Windows 7 SP1 client named PC0001 in your environment that is ready for a refresh to Windows 10.
**Note**
MDT also supports an offline computer refresh. For more info on that scenario, see the USMTOfflineMigration property in the [MDT resource page](http://go.microsoft.com/fwlink/p/?LinkId=618117).
-
-
### Upgrade (refresh) a Windows 7 SP1 client
1. On PC0001, log on as **CONTOSO\\Administrator**. Start the Lite Touch Deploy Wizard by executing **\\\\MDT01\\MDTProduction$\\Scripts\\Litetouch.vbs**. Complete the deployment guide using the following settings:
-
1. Select a task sequence to execute on this computer: Windows 10 Enterprise x64 RTM
-
2. Computer name: <default>
-
3. Specify where to save a complete computer backup: Do not back up the existing computer
-
**Note**
Skip this optional full WIM backup. The USMT backup will still run.
-
-
2. Select one or more applications to install: Install - Adobe Reader XI - x86
-
3. The setup now starts and does the following:
-
1. Backs up user settings and data using USMT.
-
2. Installs the Windows 10 Enterprise x64 operating system.
-
3. Installs the added application(s).
-
4. Updates the operating system via your local Windows Server Update Services (WSUS) server.
-
5. Restores user settings and data using USMT.
@@ -139,24 +101,15 @@ Figure 2. Starting the computer refresh from the running Windows 7 SP1 client.
## Related topics
-
[Get started with the Microsoft Deployment Toolkit (MDT)](get-started-with-the-microsoft-deployment-toolkit.md)
[Create a Windows 10 reference image](create-a-windows-10-reference-image.md)
[Deploy a Windows 10 image using MDT 2013 Update 2](deploy-a-windows-10-image-using-mdt.md)
+
[Build a distributed environment for Windows 10 deployment](build-a-distributed-environment-for-windows-10-deployment.md)
[Replace a Windows 7 computer with a Windows 10 computer](replace-a-windows-7-computer-with-a-windows-10-computer.md)
[Configure MDT settings](configure-mdt-2013-settings.md)
-
-
-
-
-
-
-
-
-
diff --git a/windows/deploy/remove-products-vamt.md b/windows/deploy/remove-products-vamt.md
index 1ee6fa653c..8dca272b68 100644
--- a/windows/deploy/remove-products-vamt.md
+++ b/windows/deploy/remove-products-vamt.md
@@ -5,40 +5,26 @@ ms.assetid: 4d44379e-dda1-4a8f-8ebf-395b6c0dad8e
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Remove Products
+
To remove one or more products from the Volume Activation Management Tool (VAMT), you can delete them from the product list view in the center pane.
**To delete one or more products**
-
1. Click a product node in the left-side pane.
-
2. You can use the **Filter** function to narrow your search for computers by clicking **Filter** in the right-side pane to open the **Filter Products** dialog box.
-
3. In the **Filter Products** dialog box, you can filter the list by computer name, product name, product key type, license status, or by any combination of these options.
-
- To filter the list by computer name, enter a name in the **Computer Name** box.
-
- To filter the list by Product Name, Product Key Type, or License Status, click the list you want to use for the filter and select an option. If necessary, click **clear all filters** to create a new filter.
-
4. Click **Filter**. VAMT displays the filtered list in the center pane.
-
5. Select the products you want to delete.
-
6. Click **Delete** in the **Selected Items** menu in the right-side pane.
-
7. On the **Confirm Delete Selected Products** dialog box, click **OK**.
## Related topics
- [Add and Manage Products](add-manage-products-vamt.md)
-
-
-
-
-
-
-
diff --git a/windows/deploy/replace-a-windows-7-computer-with-a-windows-10-computer.md b/windows/deploy/replace-a-windows-7-computer-with-a-windows-10-computer.md
index ba1084135e..bc78de5970 100644
--- a/windows/deploy/replace-a-windows-7-computer-with-a-windows-10-computer.md
+++ b/windows/deploy/replace-a-windows-7-computer-with-a-windows-10-computer.md
@@ -2,22 +2,20 @@
title: Replace a Windows 7 computer with a Windows 10 computer (Windows 10)
description: A computer replace scenario for Windows 10 is quite similar to a computer refresh for Windows 10; however, because you are replacing a machine, you cannot store the backup on the old computer.
ms.assetid: acf091c9-f8f4-4131-9845-625691c09a2a
-keywords: ["deploy, deployment, replace"]
+keywords: deploy, deployment, replace
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: mdt
author: mtniehaus
---
# Replace a Windows 7 computer with a Windows 10 computer
-
**Applies to**
-
- Windows 10
A computer replace scenario for Windows 10 is quite similar to a computer refresh for Windows 10; however, because you are replacing a machine, you cannot store the backup on the old computer. Instead you need to store the backup to a location where the new computer can read it.
-
For the purposes of this topic, we will use four machines: DC01, MDT01, PC0002, and PC0007. DC01 is a domain controller and MDT01 is a Windows Server 2012 R2 standard server. PC0002 is an old machine running Windows 7 SP1. It is going to be replaced by a new Windows 10 machine, PC0007. User State Migration Tool (USMT) will be used to backup and restore data and settings. MDT01, PC0002, and PC0007 are members of the domain contoso.com for the fictitious Contoso Corporation. For more details on the setup for this topic, please see [Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-10-with-the-microsoft-deployment-toolkit.md#proof).
@@ -26,42 +24,31 @@ Figure 1. The machines used in this topic.
## Prepare for the computer replace
-
When preparing for the computer replace, you need to create a folder in which to store the backup, and a backup only task sequence that you run on the old computer.
### Configure the rules on the Microsoft Deployment Toolkit (MDT) Production share
1. On MDT01, using the Deployment Workbench, update the MDT Production deployment share rules.
-
2. Change the **SkipUserData=YES** option to **NO**, and click **OK**.
### Create and share the MigData folder
1. On MDT01, log on as **CONTOSO\\Administrator**.
-
2. Create and share the **E:\\MigData** folder by running the following three commands in an elevated Windows PowerShell prompt:
-
``` syntax
New-Item -Path E:\MigData -ItemType directory
New-SmbShare ?Name MigData$ ?Path E:\MigData
-ChangeAccess EVERYONE
icacls E:\MigData /grant '"MDT_BA":(OI)(CI)(M)'
```
-
### Create a backup only (replace) task sequence
1. On MDT01, using the Deployment Workbench, in the MDT Production deployment share, select the **Task Sequences** node and create a new folder named **Other**.
-
2. Right-click the **Other** folder and select **New Task Sequence**. Use the following settings for the New Task Sequence Wizard:
-
1. Task sequence ID: REPLACE-001
-
2. Task sequence name: Backup Only Task Sequence
-
3. Task sequence comments: Run USMT to backup user data and settings
-
4. Template: Standard Client Replace Task Sequence
-
3. In the **Other** folder, double-click **Backup Only Task Sequence**, and then in the **Task Sequence** tab, review the sequence. Notice that it only contains a subset of the normal client task sequence actions.
@@ -70,36 +57,23 @@ When preparing for the computer replace, you need to create a folder in which to
## Perform the computer replace
-
During a computer replace, these are the high-level steps that occur:
-
1. On the computer you are replacing, a special replace task sequence runs the USMT backup and, if you configured it, runs the optional full Window Imaging (WIM) backup.
-
2. On the new machine, you perform a standard bare-metal deployment. At the end of the bare-metal deployment, the USMT backup from the old computer is restored.
### Execute the replace task sequence
1. On PC0002, log on as **CONTOSO\\Administrator**.
-
2. Verify that you have write access to the **\\\\MDT01\\MigData$** share.
-
3. Execute **\\\\MDT01\\MDTProduction$\\Scripts\\LiteTouch.vbs**.
-
4. Complete the Windows Deployment Wizard using the following settings:
-
1. Select a task sequence to execute on this computer: Backup Only Task Sequence
-
1. Specify where to save your data and settings: Specify a location
-
2. Location: \\\\MDT01\\MigData$\\PC0002
-
**Note**
If you are replacing the computer at a remote site you should create the MigData folder on MDT02 and use that share instead.
-
-
2. Specify where to save a complete computer backup: Do not back up the existing computer
-
3. Password: P@ssw0rd
The task sequence will now run USMT (Scanstate.exe) to capture user data and settings of the machine.
@@ -117,17 +91,11 @@ During a computer replace, these are the high-level steps that occur:
### Deploy the PC0007 virtual machine
1. Create a virtual machine with the following settings:
-
1. Name: PC0007
-
2. Location: C:\\VMs
-
3. Generation: 2
-
4. Memory: 2048 MB
-
5. Hard disk: 60 GB (dynamic disk)
-
2. Start the PC0007 virtual machine, and press **Enter** to start the Pre-Boot Execution Environment (PXE) boot. The machine will now load the Windows PE boot image from the WDS server.
@@ -135,30 +103,19 @@ During a computer replace, these are the high-level steps that occur:
Figure 5. The initial PXE boot process of PC0005.
3. After Windows Preinstallation Environment (Windows PE) has booted, complete the Windows Deployment Wizard using the following settings:
-
1. Password: P@ssw0rd
-
2. Select a task sequence to execute on this computer:
-
1. Windows 10 Enterprise x64 RTM Custom Image
-
2. Computer Name: PC0007
-
3. Applications: Select the Install - Adobe Reader XI - x86 application.
-
4. The setup now starts and does the following:
-
1. Installs the Windows 10 Enterprise operating system.
-
2. Installs the added application.
-
3. Updates the operating system via your local Windows Server Update Services (WSUS) server.
-
4. Restores the USMT backup from PC0002.
## Related topics
-
[Get started with the Microsoft Deployment Toolkit (MDT)](get-started-with-the-microsoft-deployment-toolkit.md)
[Create a Windows 10 reference image](create-a-windows-10-reference-image.md)
@@ -170,12 +127,3 @@ During a computer replace, these are the high-level steps that occur:
[Refresh a Windows 7 computer with Windows 10](refresh-a-windows-7-computer-with-windows-10.md)
[Configure MDT settings](configure-mdt-2013-settings.md)
-
-
-
-
-
-
-
-
-
diff --git a/windows/deploy/scenario-kms-activation-vamt.md b/windows/deploy/scenario-kms-activation-vamt.md
index 8fa9120e1f..a43796b90b 100644
--- a/windows/deploy/scenario-kms-activation-vamt.md
+++ b/windows/deploy/scenario-kms-activation-vamt.md
@@ -5,59 +5,39 @@ ms.assetid: 72b04e8f-cd35-490c-91ab-27ea799b05d0
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Scenario 3: KMS Client Activation
+
In this scenario, you use the Volume Activation Management Tool (VAMT) to activate Key Management Service (KMS) client keys or Generic Volume License Keys (GVLKs). This can be performed on either Core Network or Isolated Lab computers. By default, volume license editions of Windows Vista, Windows® 7, Windows 8, Windows 10, Windows Server 2008, Windows Server 2008 R2, Windows Server® 2012, and Microsoft® Office 2010 use KMS for activation. GVLKs are already installed in volume license editions of these products. You do not have to enter a key to activate a product as a GVLK, unless you are converting a MAK-activated product to a KMS activation. For more information, see [Install a KMS Client Key](install-kms-client-key-vamt.md).
The procedure that is described below assumes the following:
-
- The KMS Service is enabled and available to all KMS clients.
-
- VAMT has been installed and computers have been added to the VAMT database. See Parts 1 through 4 in either [Scenario 1: Online Activation](scenario-online-activation-vamt.md) or [Scenario 2: Proxy Activation](scenario-proxy-activation-vamt.md) for more information.
## Activate KMS Clients
+
1. Open VAMT.
-
2. To set the KMS activation options, on the menu bar click **View**. Then click **Preferences** to open the **Volume Activation Management Tool Preferences** dialog box.
-
3. In the **Volume Activation Management Tool Preferences** dialog box, under **KMS Management Services host selection** select from the following options:
-
- **Find a KMS host automatically using DNS**. This is the default setting. VAMT will instruct the computer to query the Domain Name Service (DNS) to locate a KMS host and perform activation. If the client contains a registry key with a valid KMS host, that value will be used instead.
-
- **Find a KMS host using DNS in this domain for supported products**. Select this option if you use a specific domain, and enter the name of the domain.
-
- **Use specific KMS host**. Select this option for environments which do not use DNS for KMS host identification, and manually enter the KMS host name and select the KMS host port. VAMT will set the specified KMS host name and KMS host port on the target computer, and then instruct the computer to perform activation with the specific KMS host.
-
4. In the left-side pane, in the **Products** node, click the product that you want to activate.
-
5. In the products list view in the center pane, sort the list if necessary. You can use the **Filter** function to narrow your search for computers by clicking **Filter** in the right-side pane to open the **Filter Products** dialog box.
-
6. In the **Filter Products** dialog box, you can filter the list by computer name, product name, product key type, license status, or by any combination of these options.
-
- To filter the list by computer name, enter a name in the **Computer Name** box.
-
- To filter the list by Product Name, Product Key Type, or License Status, click the list you want to use for the filter and select an option. If necessary, click **clear all filters** to create a new filter.
-
7. Click **Filter**. VAMT displays the filtered list in the center pane.
-
8. Select the products that you want to activate.
-
9. Click **Activate** in the **Selected Items** menu in the right-side **Actions** pane, click **Activate**, point to **Volume activate**, and then click the appropriate credential option. If you click the **Alternate Credentials** option, you will be prompted to enter an alternate user name and password.
-
10. VAMT displays the **Activating products** dialog box until it completes the requested action. When activation is complete, the status appears in the **Action Status** column of the dialog box. Click **Close** to close the dialog box. You can also click the **Automatically close when done** check box when the dialog box appears.
The same status is shown under the **Status of Last Action** column in the products list view in the center pane.
## Related topics
- [VAMT Step-by-Step Scenarios](vamt-step-by-step.md)
-
-
-
-
-
-
-
diff --git a/windows/deploy/scenario-online-activation-vamt.md b/windows/deploy/scenario-online-activation-vamt.md
index dc3fed1186..69d308ee9c 100644
--- a/windows/deploy/scenario-online-activation-vamt.md
+++ b/windows/deploy/scenario-online-activation-vamt.md
@@ -5,49 +5,36 @@ ms.assetid: 94dba40e-383a-41e4-b74b-9e884facdfd3
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Scenario 1: Online Activation
+
In this scenario, the Volume Activation Management Tool (VAMT) is deployed in the Core Network environment. VAMT is installed on a central computer that has network access to all of the client computers. Both the VAMT host and the client computers have Internet access. The following illustration shows a diagram of an online activation scenario for Multiple Activation Keys (MAKs). You can use this scenario for online activation of the following key types:
-
- Multiple Activation Key (MAK)
-
- Windows Key Management Service (KMS) keys:
-
- KMS Host key (CSVLK)
-
- Generic Volume License Key (GVLK), or KMS client key
-
- Retail
-
The Secure Zone represents higher-security Core Network computers that have additional firewall protection.
## In This Topic
- [Install and start VAMT on a networked host computer](#bkmk-partone)
-
- [Configure the Windows Management Instrumentation firewall exception on target computers](#bkmk-parttwo)
-
- [Connect to VAMT database](#bkmk-partthree)
-
- [Discover products](#bkmk-partfour)
-
- [Sort and filter the list of computers](#bkmk-partfive)
-
- [Collect status information from the computers in the list](#bkmk-partsix)
-
- [Add product keys and determine the remaining activation count](#bkmk-partseven)
-
- [Install the product keys](#bkmk-parteight)
-
- [Activate the client products](#bkmk-partnine)
## Step 1: Install and start VAMT on a networked host computer
1. Install VAMT on the host computer.
-
2. Click the VAMT icon in the **Start** menu to open VAMT.
## Step 2: Configure the Windows Management Instrumentation firewall exception on target computers
@@ -60,71 +47,50 @@ The Secure Zone represents higher-security Core Network computers that have addi
## Step 3: Connect to a VAMT database
1. If you are not already connected to a database, the **Database Connection Settings** dialog box appears when you open VAMT. Select the server and database where the keys that must be activated are located.
-
2. Click **Connect**.
-
3. If you are already connected to a database, VAMT displays an inventory of the products and product keys in the center pane, and a license overview of the computers in the database. If you need to connect to a different database, click **Successfully connected to Server** to open **the Database Connection Settings** dialog box. For more information about how to create VAMT databases and adding VAMT data, see [Manage VAMT Data](manage-vamt-data.md)
## Step 4: Discover products
1. In the left-side pane, in the **Products** node Products, click the product that you want to activate.
-
2. To open the **Discover Products** dialog box, click **Discover products** in the **Actions** menu in the right-side pane.
-
3. In the **Discover Products** dialog box, click **Search for computers in the Active Directory** to display the search options, and then click the search options that you want to use. You can search for computers in an Active Directory domain, by individual computer name or IP address, in a workgroup, or by a general Lightweight Directory Access Protocol (LDAP) query:
-
- To search for computers in an Active Directory domain, click **Search for computers in the Active Directory**. Then under **Domain Filter Criteria**, in the list of domain names click the name of the domain that you want to search. You can narrow the search further by typing a name in the **Filter by computer name** field to search for specific computers in the domain. This filter supports the asterisk (\*) wildcard. For example, typing "a\*" will display only those computer names that start with the letter "a".
-
- To search by individual computer name or IP address, click **Manually enter name or IP address**. Then enter the full name or IP address in the **One or more computer names or IP addresses separated by commas** text box. Separate multiple entries with a comma. Note that VAMT supports both IPv4 and IPV6 addressing.
-
- To search for computers in a workgroup, click **Search for computers in the workgroup**. Then under **Workgroup Filter Criteria**, in the list of workgroup names, click the name of the workgroup that you want to search. You can narrow the search further by typing a name in the **Filter by computer name** field to search for a specific computer in the workgroup. This filter supports the asterisk (\*) wildcard. For example, typing "a\*" will display only computer names that start with the letter "a".
-
- To search for computers by using a general LDAP query, click **Search with LDAP query** and enter your query in the text box that appears. VAMT will validate the LDAP query syntax, but will otherwise run the query without additional checks.
-
4. Click **Search**.
When the search is complete, the products that VAMT discovers appear in the product list view in the center pane.
## Step 5: Sort and filter the list of computers
+
You can sort the list of products so that it is easier to find the computers that require product keys to be activated:
-
1. On the menu bar at the top of the center pane, click **Group by**, and then click **Product**, **Product Key Type**, or **License Status**.
-
2. To sort the list further, you can click one of the column headings to sort by that column.
-
3. You can also use the **Filter** function to narrow your search for computers by clicking **Filter** in the right-side pane to open the **Filter Products** dialog box.
-
4. In the **Filter Products** dialog box, you can filter the list by computer name, product name, product key type, license status, or by any combination of these options.
-
- To filter the list by computer name, enter a name in the **Computer Name** box.
-
- To filter the list by product name, product key type, or license status, click the list you want to use for the filter and select an option. If necessary, click **clear all filters** to create a new filter.
-
5. Click **Filter**. VAMT displays the filtered list in the product list view in the center pane.
## Step 6: Collect status information from the computers in the list
+
To collect the status from select computers in the database, you can select computers in the product list view by using one of the following methods:
-
- To select a block of consecutively listed computers, click the first computer that you want to select, and then click the last computer while pressing the **Shift** key.
-
- To select computers which are not listed consecutively, hold down the **Ctrl** key and select each computer for which you want to collect the status information.
-
**To collect status information from the selected computers**
-
1. In the right-side **Actions** pane, click **Update license status** in the **Selected Items** menu and then click a credential option. Choose **Alternate Credentials** only if you are updating products that require administrator credentials that are different from the ones that you used to log on to the computer. Otherwise, click **Current Credentials** and continue to step 2.If you are supplying alternate credentials, in the **Windows Security** dialog box, type the appropriate user name and password and then click **OK**.
-
2. VAMT displays the **Collecting product information** dialog box while it collects the license status of all supported products on the selected computers. When the process is finished, the updated license status of each product will appear in the product list view in the center pane.
**Note**
If a computer has more than one supported product installed, VAMT adds an entry for each product. The entry appears under the appropriate product heading.
## Step 7: Add product keys and determine the remaining activation count
+
1. Click the **Product Keys** node in the left-side pane, and then click **Add Product Keys** in the right-side pane to open the **Add Product Keys** dialog box.
-
2. In the **Add Product Key** dialog box, you can select from one of the following methods to add product keys:
-
- To add product keys manually, click **Enter product key(s) separated by line breaks**, enter one or more product keys, and then click **Add Key(s)**.
-
- To import a Comma Separated Values File (CSV) that contains a list of product keys, click **Select a product key file to import**, browse to the file location, click **Open** to import the file, and then click **Add Key(s)**.
The keys that you have added appear in the **Product Keys** list view in the center pane.
@@ -133,32 +99,25 @@ To collect the status from select computers in the database, you can select comp
If you are activating many products with a MAK, refresh the activation count of the MAK to ensure that the MAK can support the required number of activations. In the product key list in the center pane, select the MAK and then click **Refresh product key data online** in the right-side pane to contact Microsoft and retrieve the number of remaining activations for the MAK. This step requires Internet access. You can only retrieve the remaining activation count for MAKs.
## Step 8: Install the product keys
+
1. In the left-side pane, click the product that you want to install keys on to.
-
2. If necessary, sort and filter the list of products so that it is easier to find the computers that must have a product key installed. See [Step 5: Sort and filter the list of computers](#bkmk-partfive).
-
3. In the **Products** list view pane, select the individual products which must have keys installed. You can use the **CTRL** key or the **SHIFT** key to select more than one product.
-
4. Click **Install product key** in the **Selected Items** menu in the right-side pane to display the **Install Product Key** dialog box.
-
5. The **Select Product Key** dialog box displays the keys that are available to be installed. Under **Recommended MAKs**, VAMT might display one or more recommended MAKs based on the selected products. If you are installing a MAK you can select a recommended product key or any other MAK from the **All Product Keys List**. If you are not installing a MAK, select a product key from the **All Product Keys** list. Use the scroll bar if you want to view the **Description** for each key. When you have selected the product key that you want to install, click **Install Key**. Note that only one key can be installed at a time.
-
6. VAMT displays the **Installing product key** dialog box while it attempts to install the product key for the selected products. When the process is finished, the status appears in the **Action Status** column of the dialog box. Click **Close** to close the dialog box. You can also click the **Automatically close when done** check box when the dialog box appears.
The same status appears under the **Status of Last Action** column in the product list view in the center pane.
-
**Note**
+
Product key installation will fail if VAMT finds mismatched key types or editions. VAMT will display the failure status and will continue the installation for the next product in the list. For more information on choosing the correct product key, see [How to Choose the Right Volume License Key for Windows.](http://go.microsoft.com/fwlink/p/?linkid=238382)
## Step 9: Activate the client products
+
1. Select the individual products that you want to activate in the list-view pane.
-
2. On the menu bar, click **Action**, point to **Activate** and point to **Online activate**. You can also right-click the selected computers(s) to display the **Action** menu, point to **Activate** and point to **Online activate**. You can also click **Activate** in the **Selected Items** menu in the right-hand pane to access the **Activate** option.
-
3. If you are activating product keys using your current credential, click **Current credential** and continue to step 5. If you are activating products that require an administrator credential that is different from the one you are currently using, click the **Alternate credential** option.
-
4. Enter your alternate user name and password and click **OK**.
-
5. The **Activate** option contacts the Microsoft product-activation server over the Internet and requests activation for the selected products. VAMT displays the **Activating products** dialog box until the requested actions are completed.
**Note**
@@ -168,12 +127,5 @@ To collect the status from select computers in the database, you can select comp
## Related topics
- [VAMT Step-by-Step Scenarios](vamt-step-by-step.md)
-
-
-
-
-
-
-
diff --git a/windows/deploy/scenario-proxy-activation-vamt.md b/windows/deploy/scenario-proxy-activation-vamt.md
index 976fc0b386..8666ae35c6 100644
--- a/windows/deploy/scenario-proxy-activation-vamt.md
+++ b/windows/deploy/scenario-proxy-activation-vamt.md
@@ -5,47 +5,43 @@ ms.assetid: ed5a8a56-d9aa-4895-918f-dd1898cb2c1a
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Scenario 2: Proxy Activation
+
In this scenario, the Volume Activation Management Tool (VAMT) is used to activate products that are installed on workgroup computers in an isolated lab environment. For workgroups which are isolated from the larger network, you can perform proxy activation of Multiple Activation Keys (MAKs), KMS Host keys (CSVLKs), Generic Volume License Keys (GVLKs) (or KMS client keys), or retail keys. Proxy activation is performed by installing a second instance of VAMT on a computer in the isolated workgroup. You can then use removable media to transfer VAMT Computer Information Lists (CILXs) between the instance of VAMT in the isolated workgroup and another VAMT host that has Internet access. The following diagram shows a Multiple Activation Key (MAK) proxy activation scenario:
## Step 1: Install VAMT on a Workgroup Computer in the Isolated Lab
-1. Install VAMT on a host computer in the isolated lab workgroup. This computer can be running Windows 7, Windows 8, Windows 10, Windows Server 2008 R2, or Windows Server® 2012.
+1. Install VAMT on a host computer in the isolated lab workgroup. This computer can be running Windows 7, Windows 8, Windows 10, Windows Server 2008 R2, or Windows Server® 2012.
2. Click the VAMT icon in the **Start** menu to open VAMT.
## Step 2: Configure the Windows Management Instrumentation Firewall Exception on Target Computers
+
- Ensure that the Windows Management Instrumentation (WMI) firewall exception has been enabled for all target computers. For more information, see [Configure Client Computers](configure-client-computers-vamt.md).
**Note**
To retrieve the license status on the selected computers, VAMT must have administrative permissions on the remote computers and WMI must be accessible through the Windows Firewall. In addition, for workgroup computers, a registry key must be created to enable remote administrative actions under User Account Control (UAC). For more information, see [Configure Client Computers](configure-client-computers-vamt.md).
## Step 3: Connect to a VAMT Database
+
1. If the host computer in the isolated lab workgroup is not already connected to the database, the **Database Connection Settings** dialog box appears when you open VAMT. Select the server and database that contains the computers in the workgroup.
-
2. Click **Connect**.
-
3. If you are already connected to a database, in the center pane VAMT displays an inventory of the products and product keys, and a license overview of the computers in the database. If you need to connect to a different database, click **Successfully connected to the Server** to open the **Database Connection Settings** dialog box. For more information about how to create VAMT databases and adding VAMT data, see [Manage VAMT Data.](manage-vamt-data.md)
## Step 4: Discover Products
+
1. In the left-side pane, in the **Products** node, click the product that you want to activate.
-
2. To open the **Discover Products** dialog box, click **Discover products** in the right-side pane.
-
3. In the **Discover Products** dialog box, click **Search for computers in the Active Directory** to display the search options, and then click the search options that you want to use. You can search for computers in an Active Directory domain, by individual computer name or IP address, in a workgroup, or by a general LDAP query:
-
- To search for computers in an Active Directory domain, click **Search for computers in the Active Directory**. Then under **Domain Filter Criteria**, in the list of domain names, click the name of the domain that you want to search. You can narrow the search further by typing a name in the **Filter by computer name** field to search for specific computers in the domain. This filter supports the asterisk (\*) wildcard. For example, typing "a\*" will display only computer names that start with the letter "a".
-
- To search by individual computer name or IP address, click **Manually enter name or IP address**. Then enter the full name or IP address in the **One or more computer names or IP addresses separated by commas** text box. Separate multiple entries with a comma. Note that both IPv4 and IPv6addressing are supported.
-
- To search for computers in a workgroup, click **Search for computers in the workgroup**. Then under **Workgroup Filter Criteria**, in the list of workgroup names, click the name of the workgroup that you want to search. You can narrow the search further by typing a name in the **Filter by computer name** field to search for a specific computer in the workgroup. This filter supports the asterisk (\*) wildcard. For example, typing "a\*" will display only those computer names that start with the letter "a".
-
- To search for computers by using a general LDAP query, click **Search with LDAP query** and enter your query in the text box that appears. VAMT will validate the LDAP query syntax, but will otherwise run the query without additional checks.
-
4. Click **Search**.
The **Finding Computers** window appears and displays the search progress as the computers are located.
@@ -53,60 +49,45 @@ In this scenario, the Volume Activation Management Tool (VAMT) is used to activa
When the search is complete, the products that VAMT discovers appear in the list view in the center pane.
## Step 5: Sort and Filter the List of Computers
+
You can sort the list of products so that it is easier to find the computers that require product keys to be activated:
1. On the menu bar at the top of the center pane, click **Group by**, and then click **Product**, **Product Key Type**, or **License Status**.
-
2. To sort the list further, you can click one of the column headings to sort by that column.
-
3. You can also use the **Filter** function to narrow your search for computers by clicking **Filter** in the right-side pane to open the **Filter Products** dialog box.
-
4. In the **Filter Products** dialog box, you can filter the list by computer name, product name, product key type, license status, or by any combination of these options.
-
- To filter the list by computer name, enter a name in the **Computer Name** box.
-
- To filter the list by product name, product key type, or license status, click the list you want to use for the filter and select an option. If necessary, click **clear all filters** to create a new filter.
-
5. Click **Filter**. VAMT displays the filtered list in the product list view in the center pane.
## Step 6: Collect Status Information from the Computers in the Isolated Lab
+
To collect the status from select computers in the database, you can select computers in the product list view by using one of the following methods:
-
- To select a block of consecutively listed computers, click the first computer that you want to select, and then click the last computer while pressing the **Shift** key.
-
- To select computers which are not listed consecutively, hold down the **Ctrl** ley and select each computer for which you want to collect the status information.
-
**To collect status information from the selected computers**
-
1. In the right-side **Actions** pane, click **Update license status** in the **Selected Items** menu and then click a credential option. Choose **Alternate Credentials** only if you are updating products that require administrator credentials that are different from the ones that you used to log on to the computer. Otherwise, click **Current Credentials** and continue to step 2.If you are supplying alternate credentials, in the **Windows Security** dialog box type the appropriate user name and password and then click **OK**.
-
2. VAMT displays the **Collecting product information** dialog box while it collects the license status of all supported products on the selected computers. When the process is finished, the updated license status of each product will appear in the product list view in the center pane.
**Note**
If a computer has more than one supported product installed, VAMT adds an entry for each product. The entry appears under the appropriate product heading.
## Step 7: Add Product Keys
+
1. Click the **Product Keys** node in the left-side pane, and then click **Add Product Keys** in the right-side pane to open the **Add Product Keys** dialog box.
-
2. In the **Add Product Keys** dialog box, you can select from one of the following methods to add product keys:
-
- To add a single product key, click **Enter product key(s) separated by line breaks**, enter one or more product keys, and then click **Add key(s)**.
-
- To import a Comma Separated Values File (CSV) that contains a list of product keys, click **Select a product key to import**, browse to the file location, click **Open** to import the file, and then click **Add Key(s)**.
The keys that you have added appear in the **Product Keys** list view in the center pane.
## Step 8: Install the Product Keys on the Isolated Lab Computers
+
1. In the left-side pane, in the **Products** node click the product that you want to install keys onto.
-
2. If necessary, sort and filter the list of products so that it is easier to find the computers that must have a product key installed. See [Step 5: Sort and Filter the List of Computers](#step-5-sort-and-filter-the-list-of-computers).
-
3. In the **Products** list view pane, select the individual products which must have keys installed. You can use the **CTRL** key or the **SHIFT** key to select more than one product.
-
4. Click **Install product key** in the **Selected Items** menu in the right-side pane to display the **Install Product Key** dialog box.
-
5. The **Select Product Key** dialog box displays the keys that are available to be installed. Under **Recommended MAKs**, VAMT might display one or more recommended MAKs based on the selected products. If you are installing a MAK you can select a recommended product key or any other MAK from the **All Product Keys List**. If you are not installing a MAK, select a product key from the **All Product Keys** list. Use the scroll bar if you need to view the **Description** for each key. When you have selected the product key that you want to install, click **Install Key**. Note that only one key can be installed at a time.
-
6. VAMT displays the **Installing product key** dialog box while it attempts to install the product key for the selected products. When the process is finished, the status appears in the **Action Status** column of the dialog box. Click **Close** to close the dialog box. You can also click the **Automatically close when done** check box when the dialog box appears.
The same status appears under the **Status of Last Action** column in the product list view in the center pane.
@@ -118,75 +99,56 @@ To collect the status from select computers in the database, you can select comp
Installing a MAK and overwriting the GVLK on client products must be done with care. If the RTM version of Windows Vista has been installed on the computer for more than 30 days, then its initial grace period has expired. As a result, it will enter Reduced Functionality Mode (RFM) if online activation is not completed successfully before the next logon attempt. However, you can use online activation to recover properly configured computers from RFM, as long as the computers are available on the network. RFM only applies to the RTM version of Windows Vista or the retail editions of Microsoft Office 2010. Windows Vista with SP1 or later, Windows 7, Windows 8, Windows 10, Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012, and volume editions of Office 2010 will not enter RFM.
## Step 9: Export VAMT Data to a .cilx File
+
In this step, you export VAMT from the workgroup’s host computer and save it in a .cilx file. Then you copy the .cilx file to removable media so that you can take it to a VAMT host computer that is connected to the Internet. In MAK proxy activation, it is critical to retain this file, because VAMT uses it to apply the Confirmation IDs (CIDs) to the proper products.
1. Select the individual products that successfully received a product key in Step 8. If needed, sort and filter the list to find the products.
-
2. In the right-side **Actions** pane, click **Export list** to open the **Export List** dialog box.
-
3. In the **Export List** dialog box, click **Browse** to navigate to the .cilx file, or enter the name of the .cilx file to which you want to export the data.
-
4. Under **Export options**, select one of the following data-type options:
-
- Export products and product keys.
-
- Export products only.
-
- Export proxy activation data only. Selecting this option ensures that the export contains only the license information required for the proxy web service to obtain CIDs from Microsoft. No Personally Identifiable Information (PII) is contained in the exported .cilx file when this selection is selected. This option should be used when an enterprise’s security policy states that no information that could identify a specific computer or user may be transferred out of the isolated lab and, therefore, this type of data must be excluded from the .cilx file that is transferred to the Core Network VAMT host.
-
5. If you have selected products to export, and not the entire set of data from the database, select the **Export selected product rows only** check box.
-
6. Click **Save**. VAMT displays a progress message while the data is being exported. Click **OK** when a message appears and confirms that the export has completed successfully.
-
7. If you exported the list to a file on the host computer’s hard drive, copy the file to removable media, such as a disk drive, CD/DVD, or USB storage device.
**Important**
Choosing the **Export proxy activation data only** option excludes Personally Identifiable Information (PII) from being saved in the .cilx file. Therefore, the .cilx file must be re-imported into the SQL Server database on the isolated lab workgroup’s VAMT host computer, so that the CIDs that are requested from Microsoft (discussed in Step 10) can be correctly assigned to the computers in the isolated lab group.
## Step 10: Acquire Confirmation IDs from Microsoft on the Internet-Connected Host Computer
+
1. Insert the removable media into the VAMT host that has Internet access.
-
2. Open VAMT. Make sure you are on the root node, and that the **Volume Activation Management Tool** view is displayed in the center pane.
-
3. In the right-side **Actions** pane, click **Acquire confirmation IDs for CILX** to open the **Acquire confirmation IDs for file** dialog box.
-
4. In the **Acquire confirmation IDs for file** dialog box, browse to the location of the .cilx file that you exported from the isolated lab host computer, select the file, and then click **Open**. VAMT displays an **Acquiring Confirmation IDs** message while it contacts Microsoft and collects the CIDs.
-
5. When the CID collection process is complete, VAMT displays a **Volume Activation Management Tool** message that shows the number of confirmation IDs that were successfully acquired, and the name of the file where the IDs were saved. Click **OK** to close the message.
## Step 11: Import the .cilx File onto the VAMT Host within the Isolated Lab Workgroup
+
1. Remove the storage device that contains the .cilx file from the Internet-connected VAMT host computer and insert it into the VAMT host computer in the isolated lab.
-
2. Open VAMT and verify that you are connected to the database that contains the computer with the product keys that you are activating.
-
3. In the right-side **Actions** pane, click **Import list** to open the **Import List** dialog box.
-
4. In the **Import list** dialog box, browse to the location of the .cilx file that contains the CIDs, select the file, and then click **Open**.
-
5. Click **OK** to import the file and to overwrite any conflicting data in the database with data from the file.
-
6. VAMT displays a progress message while the data is being imported. Click **OK** when a message appears and confirms that the data has been successfully imported.
## Step 12: Apply the CIDs and Activate the Isolated Lab Computers
-1. Select the products to which you want to apply CIDs. If needed, sort and filter the list to find the products.
+1. Select the products to which you want to apply CIDs. If needed, sort and filter the list to find the products.
2. In the right-side **Selected Items** menu, click **Activate**, click **Apply Confirmation ID**, and then select the appropriate credential option. If you click the **Alternate Credentials** option, you will be prompted to enter an alternate user name and password.
VAMT displays the **Applying Confirmation Id** dialog box while it installs the CIDs on the selected products. When VAMT finishes installing the CIDs, the status appears in the **Action Sataus** column of the dialog box. Click **Close** to close the dialog box. You can also click the **Automatically close when done** check box when the dialog box appears.
-
The same status appears under the **Status of Last Action** column in the product list view in the center pane.
## Step 13: (Optional) Reactivating Reimaged Computers in the Isolated Lab
+
If you have captured new images of the computers in the isolated lab, but the underlying hardware of those computers has not changed, VAMT can reactivate those computers using the CIDs that are stored in the database.
-
1. Redeploy products to each computer, using the same computer names as before.
-
2. Open VAMT.
-
3. In the right-side **Selected Items** menu, click **Activate**, click **Apply Confirmation ID**, and then select the appropriate credential option. If you click the **Alternate Credentials** option, you will be prompted to enter an alternate user name and password.
VAMT displays the **Applying Confirmation Id** dialog box while it installs the CIDs on the selected products. When VAMT finishes installing the CIDs, the status appears in the **Action Status** column of the dialog box. Click **Close** to close the dialog box. You can also click the **Automatically close when done** check box when the dialog box appears.
-
The same status appears under the **Status of Last Action** column in the product list view in the center pane.
**Note**
@@ -199,12 +161,5 @@ If you have captured new images of the computers in the isolated lab, but the un
## Related topics
- [VAMT Step-by-Step Scenarios](vamt-step-by-step.md)
-
-
-
-
-
-
-
diff --git a/windows/deploy/set-up-mdt-2013-for-bitlocker.md b/windows/deploy/set-up-mdt-2013-for-bitlocker.md
index 3dec8b16b3..5af8715c60 100644
--- a/windows/deploy/set-up-mdt-2013-for-bitlocker.md
+++ b/windows/deploy/set-up-mdt-2013-for-bitlocker.md
@@ -2,49 +2,39 @@
title: Set up MDT for BitLocker (Windows 10)
ms.assetid: 386e6713-5c20-4d2a-a220-a38d94671a38
description:
-keywords: ["disk, encryption, TPM, configure, secure, script"]
+keywords: disk, encryption, TPM, configure, secure, script
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: mdt
author: mtniehaus
---
# Set up MDT for BitLocker
-
This topic will show you how to configure your environment for BitLocker, the disk volume encryption built into Windows 10 Enterprise and Windows 10 Pro, using MDT. BitLocker in Windows 10 has two requirements in regard to an operating system deployment:
-
- A protector, which can either be stored in the Trusted Platform Module (TPM) chip, or stored as a password. Technically, you also can use a USB stick to store the protector, but it's not a practical approach as the USB stick can be lost or stolen. We, therefore, recommend that you instead use a TPM chip and/or a password.
-
- Multiple partitions on the hard drive.
To configure your environment for BitLocker, you will need to do the following:
1. Configure Active Directory for BitLocker.
-
2. Download the various BitLocker scripts and tools.
-
3. Configure the operating system deployment task sequence for BitLocker.
-
4. Configure the rules (CustomSettings.ini) for BitLocker.
**Note**
Even though it is not a BitLocker requirement, we recommend configuring BitLocker to store the recovery key and TPM owner information in Active Directory. For additional information about these features, see [Backing Up BitLocker and TPM Recovery Information to AD DS](http://go.microsoft.com/fwlink/p/?LinkId=619548). If you have access to Microsoft BitLocker Administration and Monitoring (MBAM), which is part of Microsoft Desktop Optimization Pack (MDOP), you have additional management features for BitLocker.
-
-
For the purposes of this topic, we will use DC01, a domain controller that is a member of the domain contoso.com for the fictitious Contoso Corporation. For more details on the setup for this topic, please see [Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-10-with-the-microsoft-deployment-toolkit.md#proof).
## Configure Active Directory for BitLocker
-
To enable BitLocker to store the recovery key and TPM information in Active Directory, you need to create a Group Policy for it in Active Directory. For this section, we are running Windows Server 2012 R2, so you do not need to extend the Schema. You do, however, need to set the appropriate permissions in Active Directory.
**Note**
Depending on the Active Directory Schema version, you might need to update the Schema before you can store BitLocker information in Active Directory.
-
-
In Windows Server 2012 R2 (as well as in Windows Server 2008 R2 and Windows Server 2012), you have access to the BitLocker Drive Encryption Administration Utilities features, which will help you manage BitLocker. When you install the features, the BitLocker Active Directory Recovery Password Viewer is included, and it extends Active Directory Users and Computers with BitLocker Recovery information.
@@ -56,23 +46,14 @@ Figure 2. The BitLocker Recovery information on a computer object in the contoso
The BitLocker Drive Encryption Administration Utilities are added as features via Server Manager (or Windows PowerShell):
1. On DC01, log on as **CONTOSO\\Administrator**, and, using Server Manager, click **Add roles and features**.
-
2. On the **Before you begin** page, click **Next**.
-
3. On the **Select installation type** page, select **Role-based or feature-based installation**, and click **Next**.
-
4. On the **Select destination server** page, select **DC01.contoso.com** and click **Next**.
-
5. On the **Select server roles** page, click **Next**.
-
6. On the **Select features** page, expand **Remote Server Administration Tools**, expand **Feature Administration Tools**, select the following features, and then click **Next**:
-
1. BitLocker Drive Encryption Administration Utilities
-
2. BitLocker Drive Encryption Tools
-
3. BitLocker Recovery Password Viewer
-
7. On the **Confirm installation selections** page, click **Install** and then click **Close**.
@@ -82,44 +63,27 @@ Figure 3. Selecting the BitLocker Drive Encryption Administration Utilities.
### Create the BitLocker Group Policy
Following these steps, you enable the backup of BitLocker and TPM recovery information to Active Directory. You also enable the policy for the TPM validation profile.
-
1. On DC01, using Group Policy Management, right-click the **Contoso** organizational unit (OU), and select **Create a GPO in this domain, and Link it here**.
-
2. Assign the name **BitLocker Policy** to the new Group Policy.
-
3. Expand the **Contoso** OU, right-click the **BitLocker Policy**, and select **Edit**. Configure the following policy settings:
-
Computer Configuration / Policies / Administrative Templates / Windows Components / BitLocker Drive Encryption / Operating System Drives
-
1. Enable the **Choose how BitLocker-protected operating system drives can be recovered** policy, and configure the following settings:
-
1. Allow data recovery agent (default)
-
2. Save BitLocker recovery information to Active Directory Domain Services (default)
-
3. Do not enable BitLocker until recovery information is stored in AD DS for operating system drives
-
2. Enable the **Configure TPM platform validation profile for BIOS-based firmware configurations** policy.
-
3. Enable the **Configure TPM platform validation profile for native UEFI firmware configurations** policy.
-
Computer Configuration / Policies / Administrative Templates / System / Trusted Platform Module Services
-
4. Enable the **Turn on TPM backup to Active Directory Domain Services** policy.
**Note**
If you consistently get the error "Windows BitLocker Drive Encryption Information. The system boot information has changed since BitLocker was enabled. You must supply a BitLocker recovery password to start this system." after encrypting a computer with BitLocker, you might have to change the various "Configure TPM platform validation profile" Group Policies, as well. Whether or not you need to do this will depend on the hardware you are using.
-
-
### Set permissions in Active Directory for BitLocker
In addition to the Group Policy created previously, you need to configure permissions in Active Directory to be able to store the TPM recovery information. In these steps, we assume you have downloaded the [Add-TPMSelfWriteACE.vbs script](http://go.microsoft.com/fwlink/p/?LinkId=167133) from Microsoft to C:\\Setup\\Scripts on DC01.
-
1. On DC01, start an elevated PowerShell prompt (run as Administrator).
-
2. Configure the permissions by running the following command:
-
``` syntax
cscript C:\Setup\Scripts\Add-TPMSelfWriteACE.vbs
```
@@ -130,27 +94,21 @@ Figure 4. Running the Add-TPMSelfWriteACE.vbs script on DC01.
## Add BIOS configuration tools from Dell, HP, and Lenovo
-
If you want to automate enabling the TPM chip as part of the deployment process, you need to download the vendor tools and add them to your task sequences, either directly or in a script wrapper.
### Add tools from Dell
The Dell tools are available via the Dell Client Configuration Toolkit (CCTK). The executable file from Dell is named cctk.exe. Here is a sample command to enable TPM and set a BIOS password using the cctk.exe tool:
-
``` syntax
cctk.exe --tpm=on --valsetuppwd=Password1234
```
-
### Add tools from HP
The HP tools are part of HP System Software Manager. The executable file from HP is named BiosConfigUtility.exe. This utility uses a configuration file for the BIOS settings. Here is a sample command to enable TPM and set a BIOS password using the BiosConfigUtility.exe tool:
-
``` syntax
BIOSConfigUtility.EXE /SetConfig:TPMEnable.REPSET /NewAdminPassword:Password1234
```
-
And the sample content of the TPMEnable.REPSET file:
-
``` syntax
English
Activate Embedded Security On Next Boot
@@ -162,38 +120,26 @@ Allow user to reject
Embedded Security Device Availability
*Available
```
-
### Add tools from Lenovo
The Lenovo tools are a set of VBScripts available as part of the Lenovo BIOS Setup using Windows Management Instrumentation Deployment Guide. Lenovo also provides a separate download of the scripts. Here is a sample command to enable TPM using the Lenovo tools:
-
``` syntax
cscript.exe SetConfig.vbs SecurityChip Active
```
-
## Configure the Windows 10 task sequence to enable BitLocker
-
When configuring a task sequence to run any BitLocker tool, either directly or using a custom script, it is helpful if you also add some logic to detect whether the BIOS is already configured on the machine. In this task sequence, we are using a sample script (ZTICheckforTPM.wsf) from the Deployment Guys web page to check the status on the TPM chip. You can download this script from the Deployment Guys Blog post, [Check to see if the TPM is enabled](http://go.microsoft.com/fwlink/p/?LinkId=619549). In the following task sequence, we have added five actions:
-
- **Check TPM Status.** Runs the ZTICheckforTPM.wsf script to determine if TPM is enabled. Depending on the status, the script will set the TPMEnabled and TPMActivated properties to either true or false.
-
- **Configure BIOS for TPM.** Runs the vendor tools (in this case, HP, Dell, and Lenovo). To ensure this action is run only when necessary, add a condition so the action is run only when the TPM chip is not already activated. Use the properties from the ZTICheckforTPM.wsf.
-
**Note**
It is common for organizations wrapping these tools in scripts to get additional logging and error handling.
-
-
- **Restart computer.** Self-explanatory, reboots the computer.
-
- **Check TPM Status.** Runs the ZTICheckforTPM.wsf script one more time.
-
- **Enable BitLocker.** Runs the built-in action to activate BitLocker.
## Related topics
-
[Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
[Configure MDT for UserExit scripts](configure-mdt-2013-for-userexit-scripts.md)
@@ -207,12 +153,3 @@ When configuring a task sequence to run any BitLocker tool, either directly or u
[Use web services in MDT](use-web-services-in-mdt-2013.md)
[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt-2013.md)
-
-
-
-
-
-
-
-
-
diff --git a/windows/deploy/simulate-a-windows-10-deployment-in-a-test-environment.md b/windows/deploy/simulate-a-windows-10-deployment-in-a-test-environment.md
index 9182555e85..a8391582fa 100644
--- a/windows/deploy/simulate-a-windows-10-deployment-in-a-test-environment.md
+++ b/windows/deploy/simulate-a-windows-10-deployment-in-a-test-environment.md
@@ -2,44 +2,31 @@
title: Simulate a Windows 10 deployment in a test environment (Windows 10)
description: This topic will walk you through the process of creating a simulated environment on which to test your Windows 10 deployment using MDT.
ms.assetid: 2de86c55-ced9-4078-b280-35e0329aea9c
-keywords: ["deploy, script,"]
+keywords: deploy, script
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: mdt
author: mtniehaus
---
# Simulate a Windows 10 deployment in a test environment
-
This topic will walk you through the process of creating a simulated environment on which to test your Windows 10 deployment using MDT. When working with advanced settings and rules, especially those like database calls, it is most efficient to be able to test the settings without having to run through a complete deployment. Luckily, MDT enables you to perform a simulated deployment by running the Gather process by itself. The simulation works best when you are using a domain-joined machine (client or server). In the following example, you use the PC0001 Windows 10 client.
-
For the purposes of this topic, you already will have either downloaded and installed the free Microsoft System Center 2012 R2 Configuration Manager Toolkit, or copied Configuration Manager Trace (CMTrace) if you have access to the System Center 2012 R2 Configuration Manager media. We also assume that you have downloaded the [sample Gather.ps1 script](http://go.microsoft.com/fwlink/p/?LinkId=619361) from the TechNet gallery.
1. On PC0001, log on as **CONTOSO\\Administrator** using the password **P@ssw0rd**.
-
2. Using Computer Management, add the **CONTOSO\\MDT\_BA** user account to the local **Administrators** group.
-
3. Log off, and then log on to PC0001 as **CONTOSO\\MDT\_BA**.
-
4. Using File Explorer, create a folder named **C:\\MDT**.
-
5. Copy the downloaded Gather.ps1 script to the **C:\\MDT** folder.
-
6. From the **\\\\MDT01\\MDTProduction$\\Scripts** folder, copy the following files to **C:\\MDT**:
-
1. ZTIDataAccess.vbs
-
2. ZTIGather.wsf
-
3. ZTIGather.xml
-
4. ZTIUtility.vbs
-
7. From the **\\\\MDT01\\MDTProduction$\\Control** folder, copy the CustomSettings.ini file to **C:\\MDT**.
-
8. In the **C:\\MDT** folder, create a subfolder named **X64**.
-
9. From the **\\\\MDT01\\MDTProduction$\\Tools\\X64** folder, copy the Microsoft.BDD.Utility.dll file to **C:\\MDT\\X64**.
@@ -47,17 +34,13 @@ For the purposes of this topic, you already will have either downloaded and inst
Figure 6. The C:\\MDT folder with the files added for the simulation environment.
10. Using an elevated Windows PowerShell prompt (run as Administrator), run the following commands. Press Enter after each command:
-
``` syntax
Set-Location C:\MDT
.\Gather.ps1
```
-
11. Review the ZTIGather.log in the **C:\\MININT\\SMSOSD\\OSDLOGS** folder.
-
**Note**
Warnings or errors with regard to the Wizard.hta are expected. If the log file looks okay, you are ready to try a real deployment.
-
@@ -66,7 +49,6 @@ Figure 7. The ZTIGather.log file from PC0001, displaying some of its hardware ca
## Related topics
-
[Set up MDT for BitLocker](set-up-mdt-2013-for-bitlocker.md)
[Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
@@ -79,13 +61,4 @@ Figure 7. The ZTIGather.log file from PC0001, displaying some of its hardware ca
[Use web services in MDT](use-web-services-in-mdt-2013.md)
-[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt-2013.md)
-
-
-
-
-
-
-
-
-
+[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt-2013.md)
\ No newline at end of file
diff --git a/windows/deploy/update-product-status-vamt.md b/windows/deploy/update-product-status-vamt.md
index 1548c85d6f..deca904c0c 100644
--- a/windows/deploy/update-product-status-vamt.md
+++ b/windows/deploy/update-product-status-vamt.md
@@ -5,32 +5,29 @@ ms.assetid: 39d4abd4-801a-4e8f-9b8c-425a24a96764
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Update Product Status
-After you add computers to the VAMT database, you need to use the **Update license status** function to add the products that are installed on the computers. You can also use the **Update license status** at any time to retrieve the most current license status for any products in the VAMT database.
+After you add computers to the VAMT database, you need to use the **Update license status** function to add the products that are installed on the computers. You can also use the **Update license status** at any time to retrieve the most current license status for any products in the VAMT database.
To retrieve license status, VAMT must have administrative permissions on all selected computers and Windows Management Instrumentation (WMI) must be accessible through the Windows Firewall. In addition, for workgroup computers, a registry key must be created to enable remote administrative actions under User Account Control (UAC). For more information, see [Configure Client Computers](configure-client-computers-vamt.md).
**Note**
The license-status query requires a valid computer name for each system queried. If the VAMT database contains computers that were added without Personally Identifiable Information, computer names will not be available for those computers, and the status for these computers will not be updated.
## Update the license status of a product
+
1. Open VAMT.
-
2. In the **Products** list, select one or more products that need to have their status updated.
-
3. In the right-side **Actions** pane, click **Update license status** and then click a credential option. Choose **Alternate Credentials** only if you are updating products that require administrator credentials different from the ones you used to log into the computer.
-
4. If you are supplying alternate credentials, in the **Windows Security** dialog box type the appropriate user name and password and click **OK**.
VAMT displays the **Collecting product information** dialog box while it collects the status of all selected products. When the process is finished, the updated licensing status of each product will appear in the product list view in the center pane.
**Note**
If a previously discovered Microsoft Office 2010 product has been uninstalled from the remote computer, updating its licensing status will cause the entry to be deleted from the **Office** product list view, and, consequently, the total number of discovered products will be smaller. However, the Windows installation of the same computer will not be deleted and will always be shown in the **Windows** products list view.
-
-
## Related topics
-- [Add and Manage Products](add-manage-products-vamt.md)
\ No newline at end of file
+- [Add and Manage Products](add-manage-products-vamt.md)
diff --git a/windows/deploy/upgrade-to-windows-10-with-the-microsoft-deployment-toolkit.md b/windows/deploy/upgrade-to-windows-10-with-the-microsoft-deployment-toolkit.md
index 210b0fe19e..35b90474ab 100644
--- a/windows/deploy/upgrade-to-windows-10-with-the-microsoft-deployment-toolkit.md
+++ b/windows/deploy/upgrade-to-windows-10-with-the-microsoft-deployment-toolkit.md
@@ -2,25 +2,23 @@
title: Upgrade to Windows 10 with the Microsoft Deployment Toolkit (Windows 10)
description: The simplest path to upgrade PCs that are currently running Windows 7, Windows 8, or Windows 8.1 to Windows 10 is through an in-place upgrade.
ms.assetid: B8993151-3C1E-4F22-93F4-2C5F2771A460
-keywords: ["upgrade, update, task sequence, deploy"]
+keywords: upgrade, update, task sequence, deploy
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: mdt
author: mtniehaus
---
# Upgrade to Windows 10 with the Microsoft Deployment Toolkit
-
**Applies to**
-
- Windows 10
The simplest path to upgrade PCs that are currently running Windows 7, Windows 8, or Windows 8.1 to Windows 10 is through an in-place upgrade. You can use a Microsoft Deployment Toolkit (MDT) 2013 Update 2 task sequence to completely automate the process.
## Proof-of-concept environment
-
For the purposes of this topic, we will use four machines: DC01, MDT01, and PC0001. DC01 is a domain controller and MDT01 is a Windows Server 2012 R2 standard machine, fully patched with the latest security updates, and configured as a member server in the fictional contoso.com domain. PC0001 is a machine with Windows 7 SP1, targeted for the Windows 10 upgrade. For more details on the setup for this topic, please see [Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-10-with-the-microsoft-deployment-toolkit.md).
@@ -29,12 +27,10 @@ Figure 1. The machines used in this topic.
## Set up the upgrade task sequence
-
MDT 2013 Update 2 adds support for Windows 10 deployment, including a new in-place upgrade task sequence template that makes the process really simple.
## Create the MDT production deployment share
-
The steps to create the deployment share for production are the same as when you created the deployment share to create the custom reference image:
1. On MDT01, log on as Administrator in the CONTOSO domain with a password of **P@ssw0rd**.
@@ -47,18 +43,14 @@ The steps to create the deployment share for production are the same as when you
## Add Windows 10 Enterprise x64 (full source)
-
In these steps we assume that you have copied the content of a Windows 10 Enterprise x64 ISO to the E:\\Downloads\\Windows 10 Enterprise x64 folder.
1. Using the Deployment Workbench, expand the **Deployment Shares** node, and then expand **MDT Production**.
2. Right-click the **Operating Systems** node, and create a new folder named **Windows 10**.
3. Expand the **Operating Systems** node, right-click the **Windows 10** folder, and select **Import Operating System**. Use the following settings for the Import Operating System Wizard:
- Full set of source files
-
- Source directory: E:\\Downloads\\Windows 10 Enterprise x64
-
- Destination directory name: W10EX64RTM
-
4. After you add the operating system, in the **Operating Systems / Windows 10** folder, double-click the added operating system name in the **Operating System** node and change the name to the following: **Windows 10 Enterprise x64 RTM Default Image**
@@ -67,25 +59,16 @@ Figure 2. The imported Windows 10 operating system after you rename it.
## Create a task sequence to upgrade to Windows 10 Enterprise
-
1. Using the Deployment Workbench, select **Task Sequences** in the **MDT Production** node, and create a folder named **Windows 10**.
2. Right-click the new **Windows 10** folder and select **New Task Sequence**. Use the following settings for the New Task Sequence Wizard:
- Task sequence ID: W10-X64-UPG
-
- Task sequence name: Windows 10 Enterprise x64 RTM Upgrade
-
- Template: Standard Client Upgrade Task Sequence
-
- Select OS: Windows 10 Enterprise x64 RTM RTM Default Image
-
- Specify Product Key: Do not specify a product key at this time
-
- Full Name: Contoso
-
- Organization: Contoso
-
- Internet Explorer home page: about:blank
-
- Admin Password: Do not specify an Administrator Password at this time
@@ -94,17 +77,17 @@ Figure 3. The task sequence to upgrade to Windows 10.
## Perform the Windows 10 upgrade
-
To initiate the in-place upgrade, perform the following steps on PC0003 (currently running Windows 7 SP1).
1. Start the MDT deployment wizard by running the following command: **\\\\MDT01\\MDTProduction$\\Scripts\\LiteTouch.vbs**
-2. Select the **Windows 10 Enterprise x64 RTM Upgrade** task sequence, and then click **Next**.
+2. Select the **Windows 10 Enterprise x64 RTM Upgrade** task sequence, and then click **Next**.
+
+ 
Figure 4. Upgrade task sequence.
-
+
3. On the **Credentials** tab, specify the **MDT\_BA** account, **P@ssw0rd** password, and **CONTOSO** for the domain. (Some or all of these values can be specified in Bootstrap.ini so they are automatically populated.)
4. On the **Ready** tab, click **Begin** to start the task sequence.
-
When the task sequence begins, it automatically initiates the in-place upgrade process by invoking the Windows setup program (Setup.exe) with the necessary command-line parameters to perform an automated upgrade, which preserves all data, settings, apps, and drivers.
@@ -115,16 +98,7 @@ After the task sequence completes, the computer will be fully upgraded to Window
## Related topics
-
[Windows 10 deployment scenarios](windows-10-deployment-scenarios.md)
[Microsoft Deployment Toolkit downloads and resources](http://go.microsoft.com/fwlink/p/?LinkId=618117)
-
-
-
-
-
-
-
-
-
+
\ No newline at end of file
diff --git a/windows/deploy/use-orchestrator-runbooks-with-mdt-2013.md b/windows/deploy/use-orchestrator-runbooks-with-mdt-2013.md
index ed32ecba07..229fb16df0 100644
--- a/windows/deploy/use-orchestrator-runbooks-with-mdt-2013.md
+++ b/windows/deploy/use-orchestrator-runbooks-with-mdt-2013.md
@@ -2,63 +2,45 @@
title: Use Orchestrator runbooks with MDT (Windows 10)
description: This topic will show you how to integrate Microsoft System Center 2012 R2 Orchestrator with MDT to replace the existing web services that are used in deployment solutions.
ms.assetid: 68302780-1f6f-4a9c-9407-b14371fdce3f
-keywords: ["web services, database"]
+keywords: web services, database
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: mdt
author: mtniehaus
---
# Use Orchestrator runbooks with MDT
-
This topic will show you how to integrate Microsoft System Center 2012 R2 Orchestrator with MDT to replace the existing web services that are used in deployment solutions.
-
MDT can integrate with System Center 2012 R2 Orchestrator, which is a component that ties the Microsoft System Center products together, as well as other products from both Microsoft and third-party vendors. The difference between using Orchestrator and "normal" web services, is that with Orchestrator you have a rich drag-and-drop style interface when building the solution, and little or no coding is required.
**Note**
If you are licensed to use Orchestrator, we highly recommend that you start using it. To find out more about licensing options for System Center 2012 R2 and Orchestrator, visit the [System Center 2012 R2](http://go.microsoft.com/fwlink/p/?LinkId=619553) website.
-
-
## Orchestrator terminology
-
Before diving into the core details, here is a quick course in Orchestrator terminology:
-
- **Orchestrator Server.** This is a server that executes runbooks.
-
- **Runbooks.** A runbook is similar to a task sequence; it is a series of instructions based on conditions. Runbooks consist of workflow activities; an activity could be Copy File, Get User from Active Directory, or even Write to Database.
-
- **Orchestrator Designer.** This is where you build the runbooks. In brief, you do that by creating an empty runbook, dragging in the activities you need, and then connecting them in a workflow with conditions and subscriptions.
-
- **Subscriptions.** These are variables that come from an earlier activity in the runbook. So if you first execute an activity in which you type in a computer name, you can then subscribe to that value in the next activity. All these variables are accumulated during the execution of the runbook.
-
- **Orchestrator Console.** This is the Microsoft Silverlight-based web page you can use interactively to execute runbooks. The console listens to TCP port 81 by default.
-
- **Orchestrator web services.** These are the web services you use in the Microsoft Deployment Toolkit to execute runbooks during deployment. The web services listen to TCP port 82 by default.
-
- **Integration packs.** These provide additional workflow activities you can import to integrate with other products or solutions, like the rest of Active Directory, other System Center 2012 R2 products, or Microsoft Exchange Server, to name a few.
**Note**
To find and download additional integration packs, see [Integration Packs for System Center 2012 - Orchestrator](http://go.microsoft.com/fwlink/p/?LinkId=619554).
-
-
## Create a sample runbook
-
This section assumes you have Orchestrator 2012 R2 installed on a server named OR01. In this section, you create a sample runbook, which is used to log some of the MDT deployment information into a text file on OR01.
1. On OR01, using File Explorer, create the **E:\\Logfile** folder, and grant Users modify permissions (NTFS).
-
2. In the **E:\\Logfile** folder, create the DeployLog.txt file.
-
**Note**
Make sure File Explorer is configured to show known file extensions so the file is not named DeployLog.txt.txt.
-
-
Figure 23. The DeployLog.txt file.
@@ -70,17 +52,11 @@ This section assumes you have Orchestrator 2012 R2 installed on a server named O
Figure 24. Folder created in the Runbooks node.
4. In the **Runbooks** node, right-click the **1.0 MDT** folder, and select **New / Runbook**.
-
5. On the ribbon bar, click **Check Out**.
-
6. Right-click the **New Runbook** label, select **Rename**, and assign the name **MDT Sample**.
-
7. Add (using a drag-and-drop operation) the following items from the **Activities** list to the middle pane:
-
1. Runbook Control / Initialize Data
-
2. Text File Management / Append Line
-
8. Connect **Initialize Data** to **Append Line**.
@@ -88,7 +64,6 @@ This section assumes you have Orchestrator 2012 R2 installed on a server named O
Figure 25. Activities added and connected.
9. Right-click the **Initialize Data** activity, and select **Properties**
-
10. On **the Initialize Data Properties** page, click **Add**, change **Parameter 1** to **OSDComputerName**, and then click **Finish**.
@@ -96,11 +71,8 @@ This section assumes you have Orchestrator 2012 R2 installed on a server named O
Figure 26. The Initialize Data Properties window.
11. Right-click the **Append Line** activity, and select **Properties**.
-
12. On the **Append Line Properties** page, in the **File** text box, type **E:\\Logfile\\DeployLog.txt**.
-
13. In the **File** encoding drop-down list, select **ASCII**.
-
14. In the **Append** area, right-click inside the **Text** text box and select **Expand**.
@@ -114,9 +86,7 @@ This section assumes you have Orchestrator 2012 R2 installed on a server named O
Figure 28. Subscribing to data.
16. In the **Published Data** window, select the **OSDComputerName** item, and click **OK**.
-
17. After the **{OSDComputerName from "Initialize Data"}** text, type in **has been deployed at** and, once again, right-click and select **Subscribe / Published Data**.
-
18. In the **Published Data** window, select the **Show common Published Data** check box, select the **Activity end time** item, and click **OK**.
@@ -124,22 +94,13 @@ This section assumes you have Orchestrator 2012 R2 installed on a server named O
Figure 29. The expanded text box after all subscriptions have been added.
19. On the **Append Line Properties** page, click **Finish**.
-
## Test the demo MDT runbook
-
-
After the runbook is created, you are ready to test it.
-
1. On the ribbon bar, click **Runbook Tester**.
-
2. Click **Run**, and in the **Initialize Data Parameters** dialog box, use the following setting and then click **OK**:
-
- OSDComputerName: PC0010
-
3. Verify that all activities are green (for additional information, see each target).
-
4. Close the **Runbook Tester**.
-
5. On the ribbon bar, click **Check In**.
@@ -148,39 +109,22 @@ Figure 30. All tests completed.
## Use the MDT demo runbook from MDT
-
1. On MDT01, using the Deployment Workbench, in the MDT Production deployment share, select the **Task Sequences** node, and create a folder named **Orchestrator**.
-
2. Right-click the **Orchestrator** node, and select **New Task Sequence**. Use the following settings for the New Task Sequence Wizard:
-
1. Task sequence ID: OR001
-
2. Task sequence name: Orchestrator Sample
-
3. Task sequence comments: <blank>
-
4. Template: Custom Task Sequence
-
3. In the **Orchestrator** node, double-click the **Orchestrator Sample** task sequence, and then select the **Task Sequence** tab.
-
4. Remove the default **Application Install** action.
-
5. Add a **Gather** action and select the **Gather only local data (do not process rules)** option.
-
6. After the **Gather** action, add a **Set Task Sequence Variable** action with the following settings:
-
1. Name: Set Task Sequence Variable
-
2. Task Sequence Variable: OSDComputerName
-
3. Value: %hostname%
-
7. After the **Set Task Sequence Variable** action, add a new **Execute Orchestrator Runbook** action with the following settings:
-
1. Orchestrator Server: OR01.contoso.com
-
2. Use Browse to select **1.0 MDT / MDT Sample**.
-
8. Click **OK**.
@@ -189,34 +133,21 @@ Figure 31. The ready-made task sequence.
## Run the orchestrator sample task sequence
-
Since this task sequence just starts a runbook, you can test this on the PC0001 client that you used for the MDT simulation environment.
-
**Note**
Make sure the account you are using has permissions to run runbooks on the Orchestrator server. For more information about runbook permissions, see [Runbook Permissions](http://go.microsoft.com/fwlink/p/?LinkId=619555).
-
-
1. On PC0001, log on as **CONTOSO\\MDT\_BA**.
-
2. Using an elevated command prompt (run as Administrator), type the following command:
-
``` syntax
cscript \\MDT01\MDTProduction$\Scripts\Litetouch.vbs
```
-
3. Complete the Windows Deployment Wizard using the following information:
-
1. Task Sequence: Orchestrator Sample
-
2. Credentials:
-
1. User Name: MDT\_BA
-
2. Password: P@ssw0rd
-
3. Domain: CONTOSO
-
4. Wait until the task sequence is completed and then verify that the DeployLog.txt file in the E:\\Logfile folder on OR01 was updated.
@@ -225,7 +156,6 @@ Figure 32. The ready-made task sequence.
## Related topics
-
[Set up MDT for BitLocker](set-up-mdt-2013-for-bitlocker.md)
[Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
@@ -236,15 +166,7 @@ Figure 32. The ready-made task sequence.
[Use the MDT database to stage Windows 10 deployment information](use-the-mdt-database-to-stage-windows-10-deployment-information.md)
+
[Assign applications using roles in MDT](assign-applications-using-roles-in-mdt-2013.md)
[Use web services in MDT](use-web-services-in-mdt-2013.md)
-
-
-
-
-
-
-
-
-
diff --git a/windows/deploy/use-the-mdt-database-to-stage-windows-10-deployment-information.md b/windows/deploy/use-the-mdt-database-to-stage-windows-10-deployment-information.md
index f832cb28d8..14749270e7 100644
--- a/windows/deploy/use-the-mdt-database-to-stage-windows-10-deployment-information.md
+++ b/windows/deploy/use-the-mdt-database-to-stage-windows-10-deployment-information.md
@@ -2,7 +2,8 @@
title: Use the MDT database to stage Windows 10 deployment information (Windows 10)
description: This topic is designed to teach you how to use the MDT database to pre-stage information on your Windows 10 deployment in a Microsoft SQL Server 2012 SP1 Express database, rather than include the information in a text file (CustomSettings.ini).
ms.assetid: 8956ab54-90ba-45d3-a384-4fdec72c4d46
-keywords: ["database, permissions, settings, configure, deploy"]
+ms.pagetype: mdt
+keywords: database, permissions, settings, configure, deploy
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
@@ -11,43 +12,29 @@ author: mtniehaus
# Use the MDT database to stage Windows 10 deployment information
-
This topic is designed to teach you how to use the MDT database to pre-stage information on your Windows 10 deployment in a Microsoft SQL Server 2012 SP1 Express database, rather than include the information in a text file (CustomSettings.ini). You can use this process, for example, to add the client machines you want to deploy, specify their computer names and IP addresses, indicate applications to be deployed, and determine many additional settings for the machines.
## Database prerequisites
-
MDT can use either SQL Server Express or full SQL Server, but since the deployment database isn't big, even in large enterprise environments, we recommend using the free SQL Server 2012 SP1 Express database in your environment.
**Note**
Be sure to enable Named Pipes when configuring the SQL Server 2012 SP1 Express database. Although it is a legacy protocol, Named Pipes has proven to work well when connecting from Windows Preinstallation Environment (Windows PE) to the SQL Server database.
-
-
## Create the deployment database
-
The MDT database is by default created and managed from the Deployment Workbench. In these steps, we assume you have installed SQL Server 2012 SP1 Express on MDT01.
**Note**
Since SQL Server 2012 SP1 Express runs by default on a separate instance (SQLEXPRESS), the SQL Server Browser service must be running, and the firewall configured to allow traffic to it. Port 1433 TCP and port 1434 UDP need to be opened for inbound traffic on MDT01.
-
-
1. On MDT01, using Deployment Workbench, expand the MDT Production deployment share, expand **Advanced Configuration**, right-click **Database**, and select **New Database**.
-
2. In the New DB Wizard, on the **SQL Server Details** page, enter the following settings and click **Next**:
-
1. SQL Server Name: MDT01
-
2. Instance: SQLEXPRESS
-
3. Port: <blank>
-
4. Network Library: Named Pipes
-
3. On the **Database** page, select **Create a new database**; in the **Database** field, type **MDT** and click **Next**.
-
4. On the **SQL Share** page, in the **SQL Share** field, type **Logs$** and click **Next**. Click **Next** again and then click **Finish**.
@@ -56,13 +43,9 @@ Figure 8. The MDT database added to MDT01.
## Configure database permissions
-
After creating the database, you need to assign permissions to it. In MDT, the account you used to run the deployment is used to access the database. In this environment, the network access account is MDT\_BA.
-
1. On MDT01, start SQL Server Management Studio.
-
2. In the **Connect to Server** dialog box, in the **Server name** list, select **MDT01\\SQLEXPRESS** and click **Connect**.
-
3. In the **Object Explorer** pane, expand the top-level **Security** node, right-click **Logins**, and select **New Login**.
@@ -70,11 +53,8 @@ After creating the database, you need to assign permissions to it. In MDT, the a
Figure 9. The top-level Security node.
4. On the **Login - New** page, next to the **Login** name field, click **Search**, and search for **CONTOSO\\MDT\_BA**. Then in the left pane, select **User Mapping**. Select the **MDT** database, and assign the following roles:
-
1. db\_datareader
-
2. public (default)
-
5. Click **OK**, and close SQL Server Management Studio.
@@ -83,17 +63,11 @@ Figure 10. Creating the login and settings permissions to the MDT database.
## Create an entry in the database
-
To start using the database, you add a computer entry and assign a description and computer name. Use the computer's MAC Address as the identifier.
-
1. On MDT01, using the Deployment Workbench, in the MDT Production deployment share, expand **Advanced Configuration**, and expand **Database**.
-
2. Right-click **Computers**, select **New**, and add a computer entry with the following settings:
-
1. Description: New York Site - PC00075
-
2. MacAddress: <PC00075 MAC Address in the 00:00:00:00:00:00 format>
-
3. Details Tab / OSDComputerName: PC00075
@@ -102,7 +76,6 @@ Figure 11. Adding the PC00075 computer to the database.
## Related topics
-
[Set up MDT for BitLocker](set-up-mdt-2013-for-bitlocker.md)
[Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
@@ -116,12 +89,3 @@ Figure 11. Adding the PC00075 computer to the database.
[Use web services in MDT](use-web-services-in-mdt-2013.md)
[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt-2013.md)
-
-
-
-
-
-
-
-
-
diff --git a/windows/deploy/use-the-volume-activation-management-tool-client.md b/windows/deploy/use-the-volume-activation-management-tool-client.md
index 5cba8c8157..4303bd18a1 100644
--- a/windows/deploy/use-the-volume-activation-management-tool-client.md
+++ b/windows/deploy/use-the-volume-activation-management-tool-client.md
@@ -2,16 +2,17 @@
title: Use the Volume Activation Management Tool (Windows 10)
description: The Volume Activation Management Tool (VAMT) provides several useful features, including the ability to perform VAMT proxy activation and to track and monitor several types of product keys.
ms.assetid: b11f0aee-7b60-44d1-be40-c960fc6c4c47
-keywords: ["vamt", "volume activation", "activation", "windows activation"]
+keywords: vamt, volume activation, activation, windows activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Use the Volume Activation Management Tool
-**Applies to**
+**Applies to**
- Windows 10
- Windows 8.1
- Windows 8
@@ -21,27 +22,26 @@ author: jdeckerMS
- Windows Server 2008 R2
**Looking for retail activation?**
-
- [Get Help Activating Microsoft Windows](http://go.microsoft.com/fwlink/p/?LinkId=618644)
The Volume Activation Management Tool (VAMT) provides several useful features, including the ability to perform VAMT proxy activation and to track and monitor several types of product keys.
-By using the VAMT, you can automate and centrally manage the volume, retail, and MAK activation process for Windows, Office, and select other Microsoft products. The VAMT can manage volume activation by using MAKs or KMS. It is a standard Microsoft Management Console snap-in, and it can be installed on any computer running Windows 10, Windows 8.1, Windows 8, Windows 7, Windows Server 2012 R2, Windows Server 2012, or Windows Server 2008 R2.
+By using the VAMT, you can automate and centrally manage the volume, retail, and MAK activation process for Windows, Office, and select other Microsoft products. The VAMT can manage volume activation by using MAKs or KMS. It is a standard Microsoft Management Console snap-in, and it can be
+installed on any computer running Windows 10, Windows 8.1, Windows 8, Windows 7, Windows Server 2012 R2, Windows Server 2012, or Windows Server 2008 R2.
The VAMT is distributed as part of the Windows Assessment and Deployment Kit (Windows ADK), which is a free download available from Microsoft Download Center. For more information, see [Windows Assessment and Deployment Kit (Windows ADK) for Windows 10](http://go.microsoft.com/fwlink/p/?LinkId=526740).
In Windows Server 2012 R2, you can install the VAMT directly from Server Manager without downloading the Windows ADK by selecting the Volume Activation Services role or the Remote Server Administration Tools/Role Administration Tools/Volume Activation Tools feature.
## Activating with the Volume Activation Management Tool
+
You can use the VAMT to complete the activation process in products by using MAK and retail keys, and you can work with computers individually or in groups. The VAMT enables two activation scenarios:
-
- **Online activation**. Online activation enables you to activate over the Internet any products that are installed with MAK, KMS host, or retail product keys. You can activate one or more connected computers within a network. This process requires that each product communicate activation information directly to Microsoft.
-
- **Proxy activation**. This activation method enables you to perform volume activation for products that are installed on client computers that do not have Internet access. The VAMT host computer distributes a MAK, KMS host key, or retail product key to one or more client products and collects the installation ID from each client product. The VAMT host sends the installation IDs to Microsoft on behalf of the client products and obtains the corresponding confirmation IDs. The VAMT host then installs the confirmation IDs on the client products to complete their activation.
-
By using this method, only the VAMT host computer requires Internet access. Proxy activation by using the VAMT is beneficial for isolated network segments and for cases where your organization has a mix of retail, MAK, and KMS-based activations.
## Tracking products and computers with the Volume Activation Management Tool
+
The VAMT provides an overview of the activation and licensing status of computers across your network, as shown in Figure 18. Several prebuilt reports are also available to help you proactively manage licensing.
@@ -49,6 +49,7 @@ The VAMT provides an overview of the activation and licensing status of computer
**Figure 18**. The VAMT showing the licensing status of multiple computers
## Tracking key usage with the Volume Activation Management Tool
+
The VAMT makes it easier to track the various keys that are issued to your organization. You can enter each key into VAMT, and then the VAMT can use those keys for online or proxy activation of clients. The tool can also describe what type of key it is and to which product group it belongs. The VAMT is the most convenient way to quickly determine how many activations remain on a MAK. Figure 19 shows an example of key types and usage.
@@ -56,28 +57,17 @@ The VAMT makes it easier to track the various keys that are issued to your organ
**Figure 19**. The VAMT showing key types and usage
## Other Volume Activation Management Tool features
+
The VAMT stores information in a Microsoft SQL Server database for performance and flexibility, and it provides a single graphical user interface for managing activations and performing other activation-related tasks, such as:
-
- **Adding and removing computers**. You can use the VAMT to discover computers in the local environment. The VAMT can discover computers by querying AD DS, workgroups, or individual computer names or IP addresses, or through a general LDAP query.
-
- **Discovering products**. You can use the VAMT to discover Windows, Windows Server, Office, and select other products that are installed on the client computers.
-
- **Managing activation data**. The VAMT stores activation data in a SQL Server database. The tool can export this data in XML format to other VAMT hosts or to an archive.
For more information, see:
-
- [Volume Activation Management Tool (VAMT) Overview](http://go.microsoft.com/fwlink/p/?LinkId=618266)
-
- [VAMT Step-by-Step Scenarios](http://go.microsoft.com/fwlink/p/?LinkId=618267)
## See also
- [Volume Activation for Windows 10](volume-activation-windows-10.md)
-
-
-
-
-
-
-
diff --git a/windows/deploy/use-vamt-in-windows-powershell.md b/windows/deploy/use-vamt-in-windows-powershell.md
index bda44f5b30..1247d95759 100644
--- a/windows/deploy/use-vamt-in-windows-powershell.md
+++ b/windows/deploy/use-vamt-in-windows-powershell.md
@@ -5,31 +5,24 @@ ms.assetid: 13e0ceec-d827-4681-a5c3-8704349e3ba9
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Use VAMT in Windows PowerShell
+
The Volume Activation Management Tool (VAMT) PowerShell cmdlets can be used to perform the same functions as the Vamt.exe command-line tool.
-
**To install PowerShell 3.0**
-
- VAMT PowerShell cmdlets require Windows PowerShell, which is included in Windows 10, Windows 8 and Windows Server® 2012. You can download PowerShell for Windows 7 or other operating systems from the [Microsoft Download Center](http://go.microsoft.com/fwlink/p/?LinkId=218356).
-
**To install the Windows Assessment and Deployment Kit**
-
- In addition to PowerShell, you must import the VAMT PowerShell module. The module is included in the VAMT 3.0 folder after you install the Windows Assessment and Deployment Kit (Windows ADK).
-
**To prepare the VAMT PowerShell environment**
-
1. To open PowerShell with administrative credentials, click **Start** and type “PowerShell” to locate the program. Right-click **Windows PowerShell**, and then click **Run as administrator**. To open PowerShell in Windows 7, click **Start**, click **All Programs**, click **Accessories**, click **Windows PowerShell**, right-click **Windows PowerShell**, and then click **Run as administrator**.
**Important**
If you are using a computer that has an 64-bit processor, select **Windows PowerShell (x86)**. VAMT PowerShell cmdlets are supported for the x86 architecture only. You must use an x86 version of Windows PowerShell to import the VAMT module, which are available in these directories:
-
- The x86 version of PowerShell is available in C:\\Windows\\SysWOW64\\WindowsPowerShell\\v1.0\\powershell.exe
-
- The x86 version of the PowerShell ISE is available in C:\\Windows\\SysWOW64\\WindowsPowerShell\\v1.0\\powershell\_ise.exe
-
2. For all supported operating systems you can use the VAMT PowerShell module included with the Windows ADK. By default, the module is installed with the Windows ADK in the VAMT folder. Change directories to the directory where VAMT is located.
For example, if the Windows ADK is installed in the default location of `C:\Program Files(x86)\Windows Kits\10`, type:
@@ -38,20 +31,18 @@ The Volume Activation Management Tool (VAMT) PowerShell cmdlets can be used to p
cd “C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\VAMT 3.0”
```
3. Import the VAMT PowerShell module. To import the module, type the following at a command prompt:
-
``` syntax
Import-Module .\VAMT.psd1
```
Where **Import-Module** imports a module only into the current session. To import the module into all sessions, add an **Import-Module** command to a Windows PowerShell profile. For more information about profiles, type `get-help about_profiles`.
## To Get Help for VAMT PowerShell cmdlets
-You can view all of the help sections for a VAMT PowerShell cmdlet, or you can view only the section that you are interested in. To view all of the Help content for a VAMT cmdlet, type:
+You can view all of the help sections for a VAMT PowerShell cmdlet, or you can view only the section that you are interested in. To view all of the Help content for a VAMT cmdlet, type:
``` ps1
get-help -all
```
For example, type:
-
``` ps1
get-help get-VamtProduct -all
```
@@ -62,24 +53,18 @@ The update-help cmdlet is not supported for VAMT PowerShell cmdlets. To view onl
**To view VAMT PowerShell Help sections**
1. To get the syntax to use with a cmdlet, type the following at a command prompt:
-
``` ps1
get-help
```
For example, type:
-
``` ps1
get-help get-VamtProduct
```
-
2. To see examples using a cmdlet, type:
-
``` ps1
get-help -examples
```
-
For example, type:
-
``` ps1
get-help get-VamtProduct -examples
- ```
\ No newline at end of file
+ ```
diff --git a/windows/deploy/use-web-services-in-mdt-2013.md b/windows/deploy/use-web-services-in-mdt-2013.md
index c8532e5a75..6fbe628335 100644
--- a/windows/deploy/use-web-services-in-mdt-2013.md
+++ b/windows/deploy/use-web-services-in-mdt-2013.md
@@ -2,39 +2,29 @@
title: Use web services in MDT (Windows 10)
description: In this topic, you will learn how to create a simple web service that generates computer names and then configure MDT to use that service during your Windows 10 deployment.
ms.assetid: 8f47535e-0551-4ccb-8f02-bb97539c6522
-keywords: ["deploy, web apps"]
+keywords: deploy, web apps
ms.prod: W10
ms.mktglfcycl: deploy
+ms.pagetype: mdt
ms.sitesec: library
author: mtniehaus
---
# Use web services in MDT
-
In this topic, you will learn how to create a simple web service that generates computer names and then configure MDT to use that service during your Windows 10 deployment. Web services provide a powerful way to assign settings during a deployment. Simply put, web services are web applications that run code on the server side, and MDT has built-in functions to call these web services.
-
Using a web service in MDT is straightforward, but it does require that you have enabled the Web Server (IIS) role on the server. Developing web services involves a little bit of coding, but for most web services used with MDT, you can use the free Microsoft Visual Studio Express 2013 for Web.
## Create a sample web service
-
In these steps we assume you have installed Microsoft Visual Studio Express 2013 for Web on PC0001 (the Windows 10 client) and downloaded the [MDT Sample Web Service](http://go.microsoft.com/fwlink/p/?LinkId=619363) from the Microsoft Download Center and extracted it to C:\\Projects.
-
1. On PC0001, using Visual Studio Express 2013 for Web, open the C:\\Projects\\MDTSample\\ MDTSample.sln solution file.
-
2. On the ribbon bar, verify that Release is selected.
-
3. In the **Debug** menu, select the **Build MDTSample** action.
-
4. On MDT01, create a folder structure for **E:\\MDTSample\\bin**.
-
5. From PC0001, copy the C:\\Projects\\MDTSample\\obj\\Release\\MDTSample.dll file to the **E:\\MDTSample\\bin** folder on MDT01.
-
6. From PC0001, copy the following files from C:\\Projects\\MDTSample file to the **E:\\MDTSample** folder on MDT01:
-
1. Web.config
-
2. mdtsample.asmx
@@ -43,23 +33,14 @@ Figure 15. The sample project in Microsoft Visual Studio Express 2013 for Web.
## Create an application pool for the web service
-
This section assumes that you have enabled the Web Server (IIS) role on MDT01.
-
1. On MDT01, using Server Manager, install the **IIS Management Console** role (available under Web Server (IIS) / Management Tools).
-
2. Using Internet Information Services (IIS) Manager, expand the **MDT01 (CONTOSO\\Administrator)** node. If prompted with the "Do you want to get started with Microsoft Web Platform?" question, select the **Do not show this message** check box and then click **No**.
-
3. Right-click **Application Pools**, select **Add Application Pool**, and configure the new application pool with the following settings:
-
1. Name: MDTSample
-
2. .NET Framework version: .NET Framework 4.0.30319
-
3. Manage pipeline mode: Integrated
-
4. Select the **Start application pool immediately** check box.
-
5. Click **OK**.
@@ -68,13 +49,9 @@ Figure 16. The new MDTSample application.
## Install the web service
-
1. On MDT01, using Internet Information Services (IIS) Manager, expand **Sites**, right-click **Default Web Site**, and select **Add Application**. Use the following settings for the application:
-
1. Alias: MDTSample
-
2. Application pool: MDTSample
-
3. Physical Path: E:\\MDTSample
@@ -82,9 +59,7 @@ Figure 16. The new MDTSample application.
Figure 17. Adding the MDTSample web application.
2. In the **Default Web Site** node, select the MDTSample web application, and in the right pane, double-click **Authentication**. Use the following settings for the **Authentication** dialog box:
-
1. Anonymous Authentication: Enabled
-
2. ASP.NET Impersonation: Disabled
@@ -93,19 +68,14 @@ Figure 18. Configuring Authentication for the MDTSample web service.
## Test the web service in Internet Explorer
-
1. On PC0001, using Internet Explorer, navigate to: **http://MDT01/MDTSample/mdtsample.asmx**.
-
2. Click the **GetComputerName** link.
Figure 19. The MDT Sample web service.
-
3. On the **GetComputerName** page, type in the following settings, and click **Invoke**:
-
1. Model: Hewlett-Packard
-
2. SerialNumber: 123456789
@@ -114,37 +84,29 @@ Figure 20. The result from the MDT Sample web service.
## Test the web service in the MDT simulation environment
-
After verifying the web service using Internet Explorer, you are ready to do the same test in the MDT simulation environment.
1. On PC0001, edit the CustomSettings.ini file in the **C:\\MDT** folder to look like the following:
-
``` syntax
[Settings]
Priority=Default, GetComputerName
-
[Default]
OSInstall=YES
-
[GetComputerName]
WebService=http://mdt01/MDTSample/mdtsample.asmx/GetComputerName
Parameters=Model,SerialNumber
OSDComputerName=string
```
-
Figure 21. The updated CustomSettings.ini file.
2. Save the CustomSettings.ini file.
-
3. Using an elevated Windows PowerShell prompt (run as Administrator), run the following commands. Press **Enter** after each command:
-
``` syntax
Set-Location C:\MDT
.\Gather.ps1
```
-
4. Review the ZTIGather.log in the **C:\\MININT\\SMSOSD\\OSDLOGS** folder.
@@ -153,7 +115,6 @@ Figure 22. The OSDCOMPUTERNAME value obtained from the web service.
## Related topics
-
[Set up MDT for BitLocker](set-up-mdt-2013-for-bitlocker.md)
[Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
@@ -167,12 +128,4 @@ Figure 22. The OSDCOMPUTERNAME value obtained from the web service.
[Assign applications using roles in MDT](assign-applications-using-roles-in-mdt-2013.md)
[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt-2013.md)
-
-
-
-
-
-
-
-
-
+
\ No newline at end of file
diff --git a/windows/deploy/vamt-known-issues.md b/windows/deploy/vamt-known-issues.md
index a6d136bd55..1e014a3e46 100644
--- a/windows/deploy/vamt-known-issues.md
+++ b/windows/deploy/vamt-known-issues.md
@@ -5,25 +5,16 @@ ms.assetid: 8992f1f3-830a-4ce7-a248-f3a6377ab77f
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# VAMT Known Issues
+
The following list contains the current known issues with the Volume Activation Management Tool (VAMT) 3.0.
-
- The VAMT Windows Management Infrastructure (WMI) remote operations may take longer to execute if the target computer is in a sleep or standby state.
-
- Recovery of Non-Genuine computers is a two-step process. VAMT can be used to install a new product key and activate the computer. However, the computer itself must visit the [Windows Genuine Advantage](http://go.microsoft.com/fwlink/p/?linkid=182914) Web site to revalidate the computer's Genuine status. Upon successfully completing this step, the computer will be restored to full functionality. For more information on recovering Non-Genuine Windows computers, go to [Windows Volume Activation](http://go.microsoft.com/fwlink/p/?linkid=184668).
-
- When opening a Computer Information List (.cil file) saved in a previous version of VAMT, the edition information is not shown for each product in the center pane. Users must update the product status again to obtain the edition information.
-
- The remaining activation count can only be retrieved for MAKs.
-
-
-
-
-
-
-
diff --git a/windows/deploy/vamt-requirements.md b/windows/deploy/vamt-requirements.md
index 4c152fa860..9da49547b0 100644
--- a/windows/deploy/vamt-requirements.md
+++ b/windows/deploy/vamt-requirements.md
@@ -5,13 +5,16 @@ ms.assetid: d14d152b-ab8a-43cb-a8fd-2279364007b9
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# VAMT Requirements
+
This topic includes info about the product key and system requirements for VAMT.
## Product Key Requirements
+
The Volume Activation Management Tool (VAMT) can be used to perform activations using any of the following types of product keys.
|Product key type |Where to obtain |
@@ -20,6 +23,7 @@ The Volume Activation Management Tool (VAMT) can be used to perform activations
|Retail product keys |Obtained at time of product purchase. |
## System Requirements
+
The following table lists the system requirements for the VAMT host computer.
|Item |Minimum system requirement |
@@ -31,7 +35,8 @@ The following table lists the system requirements for the VAMT host computer.
|Display |1024x768 or higher resolution monitor |
|Network |Connectivity to remote computers via Windows® Management Instrumentation (TCP/IP) and Microsoft® Activation Web Service on the Internet via HTTPS |
|Operating System |Windows 7, Windows 8, Windows 8.1, Windows 10, Windows Server 2008 R2, or Windows Server 2012. |
-|Additional Requirements |- Connection to a SQL Server database. For more info, see [Install VAMT](install-vamt.md).
- PowerShell 3.0: For Windows 8, Windows 8.1, Windows 10, and Windows Server® 2012, PowerShell is included in the installation. For previous versions of Windows and Windows Server, you must download PowerShell 3.0. To download PowerShell, go to [Download Windows PowerShell 3.0](http://go.microsoft.com/fwlink/p/?LinkId=218356).
- If installing on Windows Server 2008 R2, you must also install .NET Framework 3.51.
|
+|Additional Requirements |- Connection to a SQL Server database. For more info, see [Install VAMT](install-vamt.md).
- PowerShell 3.0: For Windows 8, Windows 8.1, Windows 10, and Windows Server® 2012, PowerShell is included in the installation. For previous versions of Windows and
+Windows Server, you must download PowerShell 3.0. To download PowerShell, go to [Download Windows PowerShell 3.0](http://go.microsoft.com/fwlink/p/?LinkId=218356).
- If installing on Windows Server 2008 R2, you must also install .NET Framework 3.51.
|
## Related topics
-- [Install and Configure VAMT](install-configure-vamt.md)
\ No newline at end of file
+- [Install and Configure VAMT](install-configure-vamt.md)
diff --git a/windows/deploy/vamt-step-by-step.md b/windows/deploy/vamt-step-by-step.md
index f1140f50a6..e886684243 100644
--- a/windows/deploy/vamt-step-by-step.md
+++ b/windows/deploy/vamt-step-by-step.md
@@ -5,10 +5,12 @@ ms.assetid: 455c542c-4860-4b57-a1f0-7e2d28e11a10
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# VAMT Step-by-Step Scenarios
+
This section provides step-by-step instructions on implementing the Volume Activation Management Tool (VAMT) in typical environments. VAMT supports many common scenarios; the scenarios in this section describe some of the most common to get you started.
## In this Section
@@ -21,12 +23,5 @@ This section provides step-by-step instructions on implementing the Volume Activ
## Related topics
- [Introduction to VAMT](introduction-vamt.md)
-
-
-
-
-
-
-
diff --git a/windows/deploy/volume-activation-management-tool.md b/windows/deploy/volume-activation-management-tool.md
index 9c084effad..04af72f880 100644
--- a/windows/deploy/volume-activation-management-tool.md
+++ b/windows/deploy/volume-activation-management-tool.md
@@ -5,34 +5,30 @@ ms.assetid: 1df0f795-f41c-473b-850c-e98af1ad2f2a
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Volume Activation Management Tool (VAMT) Technical Reference
+
The Volume Activation Management Tool (VAMT) enables network administrators and other IT professionals to automate and centrally manage the Windows®, Microsoft® Office, and select other Microsoft products volume and retail-activation process.
-
VAMT can manage volume activation using Multiple Activation Keys (MAKs) or the Windows Key Management Service (KMS). VAMT is a standard Microsoft Management Console (MMC) snap-in that requires the Microsoft Management Console (MMC) 3.0. VAMT can be installed on any computer that has one of the following Windows operating systems:
-
- Windows® 7
-
- Windows 8
-
- Windows 8.1
-
- Windows 10
-
- Windows Server 2008 R2
-
- Windows Server® 2012
-
- Windows Server 2012 R2
**Important**
-VAMT is designed to manage volume activation for: Windows Vista, Windows 7, Windows 8, Windows 8.1, Windows 10, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Microsoft Office 2010, and Microsoft Office 2013. Computers installed with volume editions of **Windows XP** or **Windows Server 2003** cannot be managed using VAMT. However, Office 2010 and Office 2013 products installed on these two operating systems can still be managed.
+VAMT is designed to manage volume activation for: Windows Vista, Windows 7, Windows 8, Windows 8.1, Windows 10, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Microsoft Office 2010, and Microsoft Office 2013. Computers installed with volume editions of
+**Windows XP** or **Windows Server 2003** cannot be managed using VAMT. However, Office 2010 and Office 2013 products installed on these two operating systems can still be managed.
VAMT is only available in an EN-US (x86) package.
## In this Section
+
|Topic |Description |
|------|------------|
|[Introduction to VAMT](introduction-vamt.md) |Provides a description of VAMT and common usages. |
@@ -44,14 +40,4 @@ VAMT is only available in an EN-US (x86) package.
|[Manage VAMT Data](manage-vamt-data.md) |Describes how to save, import, export, and merge a Computer Information List (CILX) file using VAMT. |
|[VAMT Step-by-Step Scenarios](vamt-step-by-step.md) |Provides step-by-step instructions for using VAMT in typical environments. |
|[VAMT Known Issues](vamt-known-issues.md) |Lists known issues in VAMT. |
-
-
-
-
-
-
-
-
-
-
-
+
\ No newline at end of file
diff --git a/windows/deploy/volume-activation-windows-10.md b/windows/deploy/volume-activation-windows-10.md
index 6801b087cd..e57043d4ca 100644
--- a/windows/deploy/volume-activation-windows-10.md
+++ b/windows/deploy/volume-activation-windows-10.md
@@ -2,16 +2,17 @@
title: Volume Activation for Windows 10 (Windows 10)
description: This guide is designed to help organizations that are planning to use volume activation to deploy and activate Windows 10, including organizations that have used volume activation for earlier versions of Windows.
ms.assetid: 6e8cffae-7322-4fd3-882a-cde68187aef2
-keywords: ["vamt", "volume activation", "activation", "windows activation"]
+keywords: vamt, volume activation, activation, windows activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: activation
author: jdeckerMS
---
# Volume Activation for Windows 10
-**Applies to**
+**Applies to**
- Windows 10
- Windows 8.1
- Windows 8
@@ -21,66 +22,42 @@ author: jdeckerMS
- Windows Server 2008 R2
**Looking for volume licensing information?**
-
- [Download the Volume Licensing Reference Guide for Windows 10 Desktop Operating System](http://go.microsoft.com/fwlink/p/?LinkId=620104)
**Looking for retail activation?**
-
- [Get Help Activating Microsoft Windows](http://go.microsoft.com/fwlink/p/?LinkId=618644)
This guide is designed to help organizations that are planning to use volume activation to deploy and activate Windows 10, including organizations that have used volume activation for earlier versions of Windows.
-
*Volume activation* is the process that Microsoft volume licensing customers use to automate and manage the activation of Windows operating systems, Microsoft Office, and other Microsoft products across large organizations. Volume licensing is available to customers who purchase software under various volume programs (such as Open and Select) and to participants in programs such as the Microsoft Partner Program and MSDN Subscriptions.
Volume activation is a configurable solution that helps automate and manage the product activation process on computers running Windows operating systems that have been licensed under a volume licensing program. Volume activation is also used with other software from Microsoft (most notably the Office suites) that are sold under volume licensing agreements and that support volume activation.
This guide provides information and step-by-step guidance to help you choose a volume activation method that suits your environment, and then to configure that solution successfully. This guide describes the volume activation features that are available in Windows 10 and Windows Server 2012 R2 and the tools that are provided in these versions of Windows and Windows Server to manage volume activation.
-Because most organizations will not immediately switch all computers to Windows 10, practical volume activation strategies must also take in to account how to work with the Windows 8, Windows 7, Windows Server 2012, and Windows Server 2008 R2Windows Server 2008 R2 operating systems. This guide discusses how the new volume activation tools can support earlier operating systems, but it does not discuss the tools that are provided with earlier operating system versions.
+Because most organizations will not immediately switch all computers to Windows 10, practical volume activation strategies must also take in to account how to work with the Windows 8, Windows 7, Windows Server 2012, and Windows Server 2008 R2Windows Server 2008 R2 operating systems. This guide
+discusses how the new volume activation tools can support earlier operating systems, but it does not discuss the tools that are provided with earlier operating system versions.
Volume activation—and the need for activation itself—is not new, and this guide does not review all of its concepts and history. You can find additional background in the appendices of this guide. For more information, see [Volume Activation Overview](http://go.microsoft.com/fwlink/p/?LinkId=618209) in the TechNet Library.
If you would like additional information about planning a volume activation deployment specifically for Windows 7 and Windows Server 2008 R2, please see the [Volume Activation Planning Guide for Windows 7](http://go.microsoft.com/fwlink/p/?LinkId=618210).
To successfully plan and implement a volume activation strategy, you must:
-
- Learn about and understand product activation.
-
- Review and evaluate the available activation types or models.
-
- Consider the connectivity of the clients to be activated.
-
- Choose the method or methods to be used with each type of client.
-
- Determine the types and number of product keys you will need.
-
- Determine the monitoring and reporting needs in your organization.
-
- Install and configure the tools required to support the methods selected.
Keep in mind that the method of activation does not change an organization’s responsibility to the licensing requirements. You must ensure that all software used in your organization is properly licensed and activated in accordance with the terms of the licensing agreements in place.
**In this guide:**
-
- [Plan for volume activation](plan-for-volume-activation-client.md)
-
- [Activate using Key Management Service](activate-using-key-management-service-vamt.md)
-
- [Activate using Active Directory-based activation](activate-using-active-directory-based-activation-client.md)
-
- [Activate clients running Windows 10](activate-windows-10-clients-vamt.md)
-
- [Monitor activation](monitor-activation-client.md)
-
- [Use the Volume Activation Management Tool](use-the-volume-activation-management-tool-client.md)
-
- [Appendix: Information sent to Microsoft during activation](appendix-information-sent-to-microsoft-during-activation-client.md)
-
-
-
-
-
-
-
-
-
+
\ No newline at end of file
diff --git a/windows/keep-secure/access-credential-manager-as-a-trusted-caller.md b/windows/keep-secure/access-credential-manager-as-a-trusted-caller.md
index 0a360b14e3..f6f7140989 100644
--- a/windows/keep-secure/access-credential-manager-as-a-trusted-caller.md
+++ b/windows/keep-secure/access-credential-manager-as-a-trusted-caller.md
@@ -5,21 +5,19 @@ ms.assetid: a51820d2-ca5b-47dd-8e9b-d7008603db88
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Access Credential Manager as a trusted caller
-
**Applies to**
-
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Access Credential Manager as a trusted caller** security policy setting.
## Reference
-
The **Access Credential Manager as a trusted caller** policy setting is used by Credential Manager during backup and restore. No accounts should have this privilege because it is assigned only to the Winlogon service. Saved credentials of users may be compromised if this privilege is given to other entities.
Constant: SeTrustedCredManAccessPrivilege
@@ -27,7 +25,6 @@ Constant: SeTrustedCredManAccessPrivilege
### Possible values
- User-defined list of accounts
-
- Not defined
### Best practices
@@ -40,52 +37,17 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Use
### Default values
-The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
-
-
-
-
-
-
-
-
-
-
-
-Default domain policy |
-Not defined |
-
-
-Default domain controller policy |
-Not defined |
-
-
-Stand-alone server default settings |
-Not defined |
-
-
-Domain controller effective default settings |
-Not defined |
-
-
-Member server effective default settings |
-Not defined |
-
-
-Client computer effective default settings |
-Not defined |
-
-
-
-
+| Server type or GPO | Default value |
+| - | - |
+| Default domain policy | Not defined |
+| Default domain controller policy | Not defined |
+| Stand-alone server default settings | Not defined |
+| Domain controller effective default settings | Not defined |
+| Member server effective default settings | Not defined |
+| Client computer effective default settings | Not defined |
-
## Policy management
-
This section describes features, tools, and guidance to help you manage this policy.
A restart of the computer is not required for this policy setting to be effective.
@@ -95,20 +57,15 @@ Any change to the user rights assignment for an account becomes effective the ne
### Group Policy
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
## Security considerations
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
@@ -124,15 +81,5 @@ Do not define the **Access Credential Manager as a trusted caller** policy setti
None. Not defined is the default configuration.
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
-
-
+
\ No newline at end of file
diff --git a/windows/keep-secure/access-this-computer-from-the-network.md b/windows/keep-secure/access-this-computer-from-the-network.md
index 0c6e340409..00a88b6ba8 100644
--- a/windows/keep-secure/access-this-computer-from-the-network.md
+++ b/windows/keep-secure/access-this-computer-from-the-network.md
@@ -5,25 +5,22 @@ ms.assetid: f6767bc2-83d1-45f1-847c-54f5362db022
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Access this computer from the network
-
**Applies to**
-
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Access this computer from the network** security policy setting.
## Reference
-
The **Access this computer from the network** policy setting determines which users can connect to the device from the network. This capability is required by a number of network protocols, including Server Message Block (SMB)-based protocols, NetBIOS, Common Internet File System (CIFS), and Component Object Model Plus (COM+).
Users, devices, and service accounts gain or lose the **Access this computer from network** user right by being explicitly or implicitly added or removed from a security group that has been granted this user right. For example, a user account or a machine account may be explicitly added to a custom security group or a built-in security group, or it may be implicitly added by Windows to a computed security group such as Domain Users, Authenticated Users, or Enterprise Domain Controllers.
-
By default, user accounts and machine accounts are granted the **Access this computer from network** user right when computed groups such as Authenticated Users, and for domain controllers, the Enterprise Domain Controllers group, are defined in the default domain controllers Group Policy Object (GPO).
Constant: SeNetworkLogonRight
@@ -31,15 +28,12 @@ Constant: SeNetworkLogonRight
### Possible values
- User-defined list of accounts
-
- Not defined
### Best practices
- On desktop devices or member servers, grant this right only to users and administrators.
-
- On domain controllers, grant this right only to authenticated users, enterprise domain controllers, and administrators.
-
- This setting includes the **Everyone** group to ensure backward compatibility. Upon Windows upgrade, after you have verified that all users and groups are correctly migrated, you should remove the **Everyone** group and use the **Authenticated Users** group instead.
### Location
@@ -50,56 +44,21 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Use
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
-
-
-
-
-
-
-
-
-
-
-Default domain policy |
-Not defined |
-
-
-Default domain controller policy |
-Everyone, Administrators, Authenticated Users, Enterprise Domain Controllers, Pre-Windows 2000 Compatible Access |
-
-
-Stand-alone server default settings |
-Everyone, Administrators, Users, Backup Operators |
-
-
-Domain controller effective default settings |
-Everyone, Administrators, Authenticated Users, Enterprise Domain Controllers, Pre-Windows 2000 Compatible Access |
-
-
-Member server effective default settings |
-Everyone, Administrators, Users, Backup Operators |
-
-
-Client computer effective default settings |
-Everyone, Administrators, Users, Backup Operators |
-
-
-
-
+|Server type of GPO | Default value |
+| - | - |
+| Default domain policy | Not defined |
+| Default domain controller policy | Everyone, Administrators, Authenticated Users, Enterprise Domain Controllers, Pre-Windows 2000 Compatible Access |
+| Stand-alone server default settings |Everyone, Administrators, Users, Backup Operators |
+| Domain controller effective default settings | Everyone, Administrators, Authenticated Users, Enterprise Domain Controllers, Pre-Windows 2000 Compatible Access |
+| Member server effective default settings | Everyone, Administrators, Users, Backup Operators |
+| Client computer effective default settings |Everyone, Administrators, Users, Backup Operators |
-
## Policy management
-
When modifying this user right, the following actions might cause users and services to experience network access issues:
- Removing the Enterprise Domain Controllers security group
-
- Removing the Authenticated Users group or an explicit group that allows users, computers, and service accounts the user right to connect to computers over the network
-
- Removing all user and machine accounts
A restart of the device is not required for this policy setting to be effective.
@@ -111,18 +70,14 @@ Any change to the user rights assignment for an account becomes effective the ne
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
## Security considerations
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
@@ -131,27 +86,16 @@ Users who can connect from their device to the network can access resources on t
### Countermeasure
-Restrict the **Access this computer from the network** user right to only those users and groups who require access to the computer. For example, if you configure this policy setting to the **Administrators** and **Users** groups, users who log on to the domain can access resources that are shared from servers in the domain if members of the **Domain Users** group are included in the local **Users** group.
-
-**Note**
-If you are using IPsec to help secure network communications in your organization, ensure that a group that includes machine accounts is given this right. This right is required for successful computer authentication. Assigning this right to **Authenticated Users** or **Domain Computers** meets this requirement.
+Restrict the **Access this computer from the network** user right to only those users and groups who require access to the computer. For example, if you configure this policy setting to the **Administrators** and **Users** groups, users who log on to the domain can access resources that are shared
+from servers in the domain if members of the **Domain Users** group are included in the local **Users** group.
+> **Note** If you are using IPsec to help secure network communications in your organization, ensure that a group that includes machine accounts is given this right. This right is required for successful computer authentication. Assigning this right to **Authenticated Users** or **Domain Computers** meets this requirement.
-
### Potential impact
If you remove the **Access this computer from the network** user right on domain controllers for all users, no one can log on to the domain or use network resources. If you remove this user right on member servers, users cannot connect to those servers through the network. If you have installed optional components such as ASP.NET or Internet Information Services (IIS), you may need to assign this user right to additional accounts that are required by those components. It is important to verify that authorized users are assigned this user right for the devices that they need to access the network.
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/account-lockout-duration.md b/windows/keep-secure/account-lockout-duration.md
index 56ba277f4f..9b8fd5a9f4 100644
--- a/windows/keep-secure/account-lockout-duration.md
+++ b/windows/keep-secure/account-lockout-duration.md
@@ -5,29 +5,25 @@ ms.assetid: a4167bf4-27c3-4a9b-8ef0-04e3c6ec3aa4
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Account lockout duration
-
**Applies to**
-
- Windows 10
Describes the best practices, location, values, and security considerations for the **Account lockout duration** security policy setting.
## Reference
-
The **Account lockout duration** policy setting determines the number of minutes that a locked-out account remains locked out before automatically becoming unlocked. The available range is from 1 through 99,999 minutes. A value of 0 specifies that the account will be locked out until an administrator explicitly unlocks it. If **Account lockout threshold** is set to a number greater than zero, **Account lockout duration** must be greater than or equal to the value of [Reset account lockout counter after](reset-account-lockout-counter-after.md).
-
This policy setting is dependent on the **Account lockout threshold** policy setting that is defined, and it must be greater than or equal to the value specified for the [Reset account lockout counter after](reset-account-lockout-counter-after.md) policy setting.
### Possible values
- A user-defined number of minutes from 0 through 99,999
-
- Not defined
If [Account lockout threshold](account-lockout-threshold.md) is configured, after the specified number of failed attempts, the account will be locked out. If th **Account lockout duration** is set to 0, the account will remain locked until an administrator unlocks it manually.
@@ -42,50 +38,17 @@ It is advisable to set **Account lockout duration** to approximately 30 minutes
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
-
-
-
-
-
-
-
-
-
-Default domain policy |
-Not defined |
-
-
-Default domain controller policy |
-Not defined |
-
-
-Stand-alone server default settings |
-Not applicable |
-
-
-Domain controller effective default settings |
-Not defined |
-
-
-Member server effective default settings |
-Not defined |
-
-
-Client computer effective default settings |
-Not applicable |
-
-
-
-
+| Server type or Group Policy Object (GPO) | Default value |
+| - | - |
+| Default domain policy | Not defined |
+| Default domain controller policy | Not defined |
+| Stand-alone server default settings | Not applicable |
+| Domain controller effective default settings | Not defined |
+| Member server effective default settings | Not defined |
+| Client computer effective default settings | Not applicable |
-
## Security considerations
-
More than a few unsuccessful password submissions during an attempt to log on to a computer might represent an attacker's attempts to determine an account password by trial and error. The Windows and Windows Server operating systems can track logon attempts, and you can configure the operating system to disable the account for a preset period of time after a specified number of failed attempts. Account lockout policy settings control the threshold for this response and what action to take after the threshold is reached.
### Vulnerability
@@ -102,14 +65,6 @@ Configuring the **Account lockout duration** policy setting to 0 so that account
## Related topics
-
[Account Lockout Policy](account-lockout-policy.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/account-lockout-policy.md b/windows/keep-secure/account-lockout-policy.md
index a8156f485c..edf3c1a723 100644
--- a/windows/keep-secure/account-lockout-policy.md
+++ b/windows/keep-secure/account-lockout-policy.md
@@ -5,14 +5,13 @@ ms.assetid: eb968c28-17c5-405f-b413-50728cb7b724
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Account Lockout Policy
-
**Applies to**
-
- Windows 10
Describes the Account Lockout Policy settings and links to information about each policy setting.
@@ -23,46 +22,14 @@ The following topics provide a discussion of each policy setting's implementatio
## In this section
-
-
-
-
-
-
-
-
-
-
-
-[Account lockout duration](account-lockout-duration.md) |
-Describes the best practices, location, values, and security considerations for the Account lockout duration security policy setting. |
-
-
-[Account lockout threshold](account-lockout-threshold.md) |
-Describes the best practices, location, values, and security considerations for the Account lockout threshold security policy setting. |
-
-
-[Reset account lockout counter after](reset-account-lockout-counter-after.md) |
-Describes the best practices, location, values, and security considerations for the Reset account lockout counter after security policy setting. |
-
-
-
-
+| Topic | Description |
+| - | - |
+| [Account lockout duration](account-lockout-duration.md) | Describes the best practices, location, values, and security considerations for the **Account lockout duration** security policy setting. |
+| [Account lockout threshold](account-lockout-threshold.md) | Describes the best practices, location, values, and security considerations for the **Account lockout threshold** security policy setting. |
+| [Reset account lockout counter after](reset-account-lockout-counter-after.md) | Describes the best practices, location, values, and security considerations for the **Reset account lockout counter after** security policy setting. |
-
## Related topics
-
[Configure security policy settings](how-to-configure-security-policy-settings.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/account-lockout-threshold.md b/windows/keep-secure/account-lockout-threshold.md
index 93e40cfc90..56fedf53b7 100644
--- a/windows/keep-secure/account-lockout-threshold.md
+++ b/windows/keep-secure/account-lockout-threshold.md
@@ -5,35 +5,30 @@ ms.assetid: 4904bb40-a2bd-4fef-a102-260ba8d74e30
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Account lockout threshold
-
**Applies to**
-
- Windows 10
Describes the best practices, location, values, and security considerations for the **Account lockout threshold** security policy setting.
## Reference
-
The **Account lockout threshold** policy setting determines the number of failed sign-in attempts that will cause a user account to be locked. A locked account cannot be used until you reset it or until the number of minutes specified by the [Account lockout duration](account-lockout-duration.md) policy setting expires. You can set a value from 1 through 999 failed sign-in attempts, or you can specify that the account will never be locked by setting the value to 0. If **Account lockout threshold** is set to a number greater than zero, **Account lockout duration** must be greater than or equal to the value of [Reset account lockout counter after](reset-account-lockout-counter-after.md).
Failed password attempts on workstations or member servers that have been locked by using CTRL+ALT+DELETE or password-protected screen savers do not count as failed sign-in attempts unless [Interactive logon: Require Domain Controller authentication to unlock workstation](interactive-logon-require-domain-controller-authentication-to-unlock-workstation.md) is set to **Enabled**. If Interactive logon: Require Domain Controller authentication to unlock workstation is enabled, repeated failed password attempts to unlock the workstation will count against the account lockout threshold.
Brute force password attacks can be automated to try thousands or even millions of password combinations for any or all user accounts. Limiting the number of failed sign-ins that can be performed nearly eliminates the effectiveness of such attacks.
-
However, it is important to note that a denial-of-service (DoS) attack could be performed on a domain that has an account lockout threshold configured. A malicious user could programmatically attempt a series of password attacks against all users in the organization. If the number of attempts is greater than the value of **Account lockout threshold**, the attacker could potentially lock every account.
### Possible values
It is possible to configure the following values for the **Account lockout threshold** policy setting:
-
- A user-defined number from 0 through 999
-
- Not defined
Because vulnerabilities can exist when this value is configured and when it is not, organizations should weigh their identified threats and the risks that they are trying to mitigate. For information these settings, see [Countermeasure](#bkmk-countermeasure) in this topic
@@ -41,12 +36,8 @@ Because vulnerabilities can exist when this value is configured and when it is n
### Best practices
The threshold that you select is a balance between operational efficiency and security, and it depends on your organization's risk level. To allow for user error and to thwart brute force attacks, a setting above 4 and below 10 could be an acceptable starting point for your organization.
-
-**Important**
-Implementation of this policy setting is dependent on your operational environment; threat vectors, deployed operating systems, and deployed apps. For more information, see [Implementation considerations](#bkmk-impleconsiderations) in this topic.
-
+> **Important:** Implementation of this policy setting is dependent on your operational environment; threat vectors, deployed operating systems, and deployed apps. For more information, see [Implementation considerations](#bkmk-impleconsiderations) in this topic.
-
### Location
**Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Account Lockout Policy**
@@ -55,47 +46,15 @@ Implementation of this policy setting is dependent on your operational environme
The following table lists the actual and effective default policy values. Default values are also listed on the property page for the policy setting.
-
-
-
-
-
-
-
-
-
-
-Default domain policy |
-0 invalid sign-in attempts |
-
-
-Default domain controller policy |
-Not defined |
-
-
-Stand-alone server default settings |
-0 invalid sign-in attempts |
-
-
-Domain controller effective default settings |
-0 invalid sign-in attempts |
-
-
-Member server effective default settings |
-0 invalid sign-in attempts |
-
-
-Effective GPO default settings on client computers |
-0 invalid sign-in attempts |
-
-
-
-
+| Server type or Group Policy Object (GPO) | Default value |
+| - | - |
+| Default domain policy | 0 invalid sign-in attempts |
+| Default domain controller policy | Not defined |
+| Stand-alone server default settings | 0 invalid sign-in attempts |
+| Domain controller effective default settings | 0 invalid sign-in attempts |
+| Member server effective default settings |0 invalid sign-in attempts |
+| Effective GPO default settings on client computers |0 invalid sign-in attempts |
-
### Policy management
This section describes features and tools that are available to help you manage this policy setting.
@@ -107,43 +66,30 @@ None. Changes to this policy setting become effective without a computer restart
### Implementation considerations
Implementation of this policy setting is dependent on your operational environment. You should consider threat vectors, deployed operating systems, and deployed apps, for example:
-
- The likelihood of an account theft or a DoS attack is based on the security design for your systems and environment. You should set the account lockout threshold in consideration of the known and perceived risk of those threats.
-
- When negotiating encryption types between clients, servers, and domain controllers, the Kerberos protocol can automatically retry account sign-in attempts that count toward the threshold limits that you set in this policy setting. In environments where different versions of the operating system are deployed, encryption type negotiation increases.
-
- Not all apps that are used in your environment effectively manage how many times a user can attempt to sign-in. For instance, if a connection drops repeatedly when a user is running the app, all subsequent failed sign-in attempts count toward the account lockout threshold.
## Security considerations
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
Brute force password attacks can use automated methods to try millions of password combinations for any user account. The effectiveness of such attacks can be almost eliminated if you limit the number of failed sign-in attempts that can be performed.
-
However, a DoS attack could be performed on a domain that has an account lockout threshold configured. An attacker could programmatically attempt a series of password attacks against all users in the organization. If the number of attempts is greater than the account lockout threshold, the attacker might be able to lock every account without needing any special privileges or being authenticated in the network.
-**Note**
-Offline password attacks are not countered by this policy setting.
-
+> **Note:** Offline password attacks are not countered by this policy setting.
-
### Countermeasure
Because vulnerabilities can exist when this value is configured and when it is not configured, two distinct countermeasures are defined. Organizations should weigh the choice between the two, based on their identified threats and the risks that they want to mitigate. The two countermeasure options are:
-
- Configure the **Account lockout threshold** setting to 0. This configuration ensures that accounts will not be locked, and it will prevent a DoS attack that intentionally attempts to lock accounts. This configuration also helps reduce Help Desk calls because users cannot accidentally lock themselves out of their accounts. Because it does not prevent a brute force attack, this configuration should be chosen only if both of the following criteria are explicitly met:
-
- The password policy setting requires all users to have complex passwords of 8 or more characters.
-
- A robust audit mechanism is in place to alert administrators when a series of failed sign-ins occur in the environment.
-
- Configure the **Account lockout threshold** policy setting to a sufficiently high value to provide users with the ability to accidentally mistype their password several times before the account is locked, but ensure that a brute force password attack still locks the account.
A good recommendation for such a configuration is 50 invalid sign-in attempts, which prevents accidental account lockouts and reduces the number of Help Desk calls, but does not prevent a DoS attack. We recommend this option if your organization cannot implement complex password requirements and an audit policy that alerts administrators to a series of failed sign-in attempts.
-
Using this type of policy must be accompanied by a process to unlock locked accounts. It must be possible to implement this policy whenever it is needed to help mitigate massive lockouts caused by an attack on your systems.
### Potential impact
@@ -155,15 +101,5 @@ If you configure the **Account lockout threshold** policy setting to 0, there is
If you configure this policy setting to a number greater than 0, an attacker can easily lock any accounts for which the account name is known. This is especially dangerous considering that no credentials other than access to the network are necessary to lock the accounts.
## Related topics
-
-
[Account Lockout Policy](account-lockout-policy.md)
-
-
-
-
-
-
-
-
-
+
\ No newline at end of file
diff --git a/windows/keep-secure/account-policies.md b/windows/keep-secure/account-policies.md
index 3aab5ebc1d..487d575c7f 100644
--- a/windows/keep-secure/account-policies.md
+++ b/windows/keep-secure/account-policies.md
@@ -5,69 +5,30 @@ ms.assetid: 711b3797-b87a-4cd9-a2e3-1f8ef18688fb
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Account Policies
-
**Applies to**
-
- Windows 10
An overview of account policies in Windows and provides links to policy descriptions.
All account policies settings applied by using Group Policy are applied at the domain level. Default values are present in the built-in default domain controller policy for Password Policy settings, Account Lockout Policy settings, and Kerberos Policy settings. The domain account policy becomes the default local account policy of any device that is a member of the domain. If these policies are set at any level below the domain level in Active Directory Domain Services (AD DS), they affect only local accounts on member servers.
-
-**Note**
-Each domain can have only one account policy. The account policy must be defined in the default domain policy or in a new policy that is linked to the root of the domain and given precedence over the default domain policy, which is enforced by the domain controllers in the domain. These domain-wide account policy settings (Password Policy, Account Lockout Policy, and Kerberos Policy) are enforced by the domain controllers in the domain; therefore, domain controllers always retrieve the values of these account policy settings from the default domain policy Group Policy Object (GPO).
-
+> **Note:** Each domain can have only one account policy. The account policy must be defined in the default domain policy or in a new policy that is linked to the root of the domain and given precedence over the default domain policy, which is enforced by the domain controllers in the domain. These domain-wide account policy settings (Password Policy, Account Lockout Policy, and Kerberos Policy) are enforced by the domain controllers in the domain; therefore, domain controllers always retrieve the values of these account policy settings from the default domain policy Group Policy Object (GPO).
-
The only exception is when another account policy is defined for an organizational unit (OU). The account policy settings for the OU affect the local policy on any computers that are contained in the OU. For example, if an OU policy defines a maximum password age that differs from the domain-level account policy, the OU policy will be applied and enforced only when users log on to the local computer. The default local computer policies apply only to computers that are in a workgroup or in a domain where neither an OU account policy nor a domain policy applies.
## In this section
-
-
-
-
-
-
-
-
-
-
-
-[Password Policy](password-policy.md) |
-An overview of password policies for Windows and links to information for each policy setting. |
-
-
-[Account Lockout Policy](account-lockout-policy.md) |
-Describes the Account Lockout Policy settings and links to information about each policy setting. |
-
-
-[Kerberos Policy](kerberos-policy.md) |
-Describes the Kerberos Policy settings and provides links to policy setting descriptions. |
-
-
-
-
+| Topic | Description |
+| - | - |
+| [Password Policy](password-policy.md) | An overview of password policies for Windows and links to information for each policy setting. |
+| [Account Lockout Policy](account-lockout-policy.md) | Describes the Account Lockout Policy settings and links to information about each policy setting. |
+| [Kerberos Policy](kerberos-policy.md) | Describes the Kerberos Policy settings and provides links to policy setting descriptions. |
-
## Related topics
-
[Configure security policy settings](how-to-configure-security-policy-settings.md)
-
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/accounts-administrator-account-status.md b/windows/keep-secure/accounts-administrator-account-status.md
index 280cd87d5b..6c992c3bcb 100644
--- a/windows/keep-secure/accounts-administrator-account-status.md
+++ b/windows/keep-secure/accounts-administrator-account-status.md
@@ -5,45 +5,35 @@ ms.assetid: 71a3bd48-1014-49e0-a936-bfe9433af23e
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Accounts: Administrator account status
-
**Applies to**
-
- Windows 10
Describes the best practices, location, values, and security considerations for the **Accounts: Administrator account status** security policy setting.
## Reference
-
This security setting determines whether the local administrator account is enabled or disabled.
If you try to enable the administrator account after it has been disabled, and if the current administrator password does not meet the password requirements, you cannot enable the account. In this case, an alternative member of the Administrators group must reset the password on the administrator account.
If you disable this policy setting, and one of the following conditions exists on the computer, the administrator account is not disabled.
-
1. No other local administrator account exists
-
2. The administrator account is currently in use
-
3. All other local administrator accounts are:
-
1. Disabled
-
2. Listed in the [Deny log on locally](deny-log-on-locally.md) User Rights Assignment
If the current administrator password does not meet the password requirements, you will not be able to enable the administrator account again after it has been disabled. In this case, another member of the Administrators group must set the password on the administrator account.
### Possible values
-
- Enabled
-
- Disabled
-
- Not defined
By default, this setting is **Not defined** on domain controllers and **Enabled** on stand-alone servers.
@@ -60,56 +50,20 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Sec
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
-
-
-
-
-
-
-
-
-
-Default Domain Policy |
-Not defined |
-
-
-Default Domain Controller Policy |
-Not defined |
-
-
-Stand-Alone Server Default Settings |
-Enabled |
-
-
-DC Effective Default Settings |
-Enabled |
-
-
-Member Server Effective Default Settings |
-Enabled |
-
-
-Client Computer Effective Default Settings |
-Disabled |
-
-
-
-
+| Server type or GPO | Default value |
+| Default Domain Policy | Not defined |
+| Default Domain Controller Policy |Not defined |
+| Stand-Alone Server Default Settings | Enabled |
+| DC Effective Default Settings | Enabled |
+| Member Server Effective Default Settings | Enabled |
+| Client Computer Effective Default Settings | Disabled |
-
## Policy management
-
Disabling the administrator account can become a maintenance issue under certain circumstances. Reasons that an organization might consider disabling the built-in administrator account include:
- For some organizations, periodically changing the passwords for local accounts can be a daunting management challenge.
-
- By default, the administrator account cannot be locked—no matter how many failed attempts to sign in a user accrues. This makes it a prime target for brute-force, password-guessing attacks.
-
- This account has a well-known security identifier (SID). Some non-Microsoft tools allow you to authenticate over the network by specifying the SID rather than the account name. This means that even if you rename the administrator account, a malicious user could start a brute-force attack by using the SID.
### Restart requirement
@@ -119,22 +73,18 @@ None. Changes to this policy become effective without a device restart when they
### Safe mode considerations
When you start a device in safe mode, the disabled administrator account is enabled only if the computer is non-domain joined and there are no other active local administrator accounts. If the computer is joined to a domain, the disabled administrator account is not enabled.
-
If the administrator account is disabled, you can still access the computer by using safe mode with the current administrative credentials. For example, if a failure occurs using a secure channel with a domain-joined computer, and there is no other local administrator account, you must restart the device in safe mode to fix the failure.
### How to access a disabled Administrator account
You can use the following methods to access a disabled Administrator account:
-
- When there is only one local administrator account that is disabled, start the device in safe mode (locally or over a network), and sign in by using the credentials for the administrator account on that computer.
-
-- When there are local administrator accounts in addition to the built-in account, start the computer in safe mode (locally or over a network), and sign in by using the credentials for the administrator account on that device. An alternate method is to sign in to Windows by using another local Administrator account that was created.
-
+- When there are local administrator accounts in addition to the built-in account, start the computer in safe mode (locally or over a network), and sign in by using the credentials for the administrator account on that device. An alternate method is to sign in to Windows by using another local
+Administrator account that was created.
- When multiple domain-joined servers have a disabled local Administrator account that can be accessed in safe mode, you can remotely run psexec by using the following command: **net user administrator /active: no**.
## Security considerations
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
@@ -144,25 +94,13 @@ The built-in administrator account cannot be locked out no matter how many faile
### Countermeasure
Disable the **Accounts: Administrator account status** setting so that the built-in Administrator account cannot be used in a normal system startup.
-
If it is very difficult to maintain a regular schedule for periodic password changes for local accounts, you can disable the built-in administrator account instead of relying on regular password changes to protect it from attack.
### Potential impact
Maintenance issues can arise under certain circumstances if you disable the administrator account. For example, if the secure channel between a member computer and the domain controller fails in a domain environment for any reason and there is no other local administrator account, you must restart in safe mode to fix the problem that caused the secure channel to fail.
-
If the current administrator password does not meet the password requirements, you cannot enable the administrator account after it is disabled. If this situation occurs, another member of the administrators group must set the password on the administrator account.
## Related topics
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/accounts-block-microsoft-accounts.md b/windows/keep-secure/accounts-block-microsoft-accounts.md
index facb9daf89..a482a7a88c 100644
--- a/windows/keep-secure/accounts-block-microsoft-accounts.md
+++ b/windows/keep-secure/accounts-block-microsoft-accounts.md
@@ -5,22 +5,20 @@ ms.assetid: 94c76f45-057c-4d80-8d01-033cf28ef2f7
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Accounts: Block Microsoft accounts
-
**Applies to**
-
- Windows 10
Describes the best practices, location, values, management, and security considerations for the **Accounts: Block Microsoft accounts** security policy setting.
## Reference
-
-This policy setting prevents users from adding new Microsoft accounts on a device
+This policy setting prevents users from adding new Microsoft accounts on a device.
If you click the **Users can’t add Microsoft accounts** setting option, users will not be able to switch a local account to a Microsoft account, or connect a domain account to a Microsoft account to drive sync, roaming, or other background services. This is the preferred option if you need to limit the use of Microsoft accounts in your enterprise. Users will still be able to add app-specific Microsoft accounts for use with consumer apps. To block this use, turn off the ability to install consumer apps or the Store.
@@ -29,11 +27,8 @@ If you click the **Users can’t add or log on with Microsoft accounts** setting
If you disable or do not configure this policy (recommended), users will be able to use Microsoft accounts with Windows.
### Possible values
-
- This policy is disabled
-
- Users can’t add Microsoft accounts
-
- Users can’t add or log on with Microsoft accounts
By default, this setting is not defined on domain controllers and disabled on stand-alone servers.
@@ -41,7 +36,6 @@ By default, this setting is not defined on domain controllers and disabled on st
### Best practices
- By disabling or not configuring this policy setting on the client computer, users will be able to use their Microsoft account, local account, or domain account for their sign-in session to Windows. It also enables the user to connect a local or domain account to a Microsoft account. This provides a convenient option for your users.
-
- If you need to limit the use of Microsoft accounts in your organization, click the **Users can’t add Microsoft accounts** setting option so that users will not be able to create new Microsoft accounts on a computer, switch a local account to a Microsoft account, or connect a domain account to a Microsoft account.
### Location
@@ -52,50 +46,17 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Sec
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
-
-
-
-
-
-
-
-
-
-Default Domain Policy |
-Not defined |
-
-
-Default Domain Controller Policy |
-Not defined |
-
-
-Stand-Alone Server Default Settings |
-Disabled |
-
-
-DC Effective Default Settings |
-Disabled |
-
-
-Member Server Effective Default Settings |
-Disabled |
-
-
-Client Computer Effective Default Settings |
-Disabled |
-
-
-
-
+| Server type or GPO | Default value |
+| - | - |
+| Default Domain Policy | Not defined |
+| Default Domain Controller Policy | Not defined |
+| Stand-Alone Server Default Settings | Disabled |
+| DC Effective Default Settings | Disabled |
+| Member Server Effective Default Settings | Disabled |
+| Client Computer Effective Default Settings | Disabled |
-
## Policy management
-
This section describes features and tools that are available to help you manage this policy.
### Restart requirement
@@ -104,7 +65,6 @@ None. Changes to this policy become effective without a device restart when they
## Security considerations
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of the countermeasure implementation.
### Vulnerability
@@ -121,14 +81,6 @@ Establishing greater control over accounts in your organization can give you mor
## Related topics
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/accounts-guest-account-status.md b/windows/keep-secure/accounts-guest-account-status.md
index 8636ac74e3..2e66ee3ae1 100644
--- a/windows/keep-secure/accounts-guest-account-status.md
+++ b/windows/keep-secure/accounts-guest-account-status.md
@@ -5,31 +5,26 @@ ms.assetid: 07e53fc5-b495-4d02-ab42-5b245d10d0ce
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Accounts: Guest account status
-
**Applies to**
-
- Windows 10
Describes the best practices, location, values, and security considerations for the **Accounts: Guest account status** security policy setting.
## Reference
-
The **Accounts: Guest account status** policy setting determines whether the Guest account is enabled or disabled.
-
This account allows unauthenticated network users to gain access to the system by logging on as a Guest with no password. Unauthorized users can access any resources that are accessible to the Guest account over the network. This means that any network shared folders with permissions that allow access to the Guest account, the Guests group, or the Everyone group will be accessible over the network. This can lead to the exposure or corruption of data.
### Possible values
- Enabled
-
- Disabled
-
- Not defined
### Best practices
@@ -44,50 +39,17 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Sec
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
-
-
-
-
-
-
-
-
-
-Default Domain Policy |
-Not defined |
-
-
-Default Domain Controller Policy |
-Not defined |
-
-
-Stand-Alone Server Default Settings |
-Disabled |
-
-
-DC Effective Default Settings |
-Disabled |
-
-
-Member Server Effective Default Settings |
-Disabled |
-
-
-Client Computer Effective Default Settings |
-Disabled |
-
-
-
-
+| Server type or GPO | Default value |
+| - | - |
+| Default Domain Policy | Not defined |
+| Default Domain Controller Policy | Not defined |
+| Stand-Alone Server Default Settings | Disabled |
+| DC Effective Default Settings | Disabled |
+| Member Server Effective Default Settings | Disabled |
+| Client Computer Effective Default Settings | Disabled |
-
## Security considerations
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
@@ -104,14 +66,6 @@ All network users must be authenticated before they can access shared resources.
## Related topics
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/accounts-limit-local-account-use-of-blank-passwords-to-console-logon-only.md b/windows/keep-secure/accounts-limit-local-account-use-of-blank-passwords-to-console-logon-only.md
index 50c2375ce6..9d8ddd27c9 100644
--- a/windows/keep-secure/accounts-limit-local-account-use-of-blank-passwords-to-console-logon-only.md
+++ b/windows/keep-secure/accounts-limit-local-account-use-of-blank-passwords-to-console-logon-only.md
@@ -5,25 +5,22 @@ ms.assetid: a1bfb58b-1ae8-4de9-832b-aa889a6e64bd
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Accounts: Limit local account use of blank passwords to console logon only
-
**Applies to**
-
- Windows 10
Describes the best practices, location, values, and security considerations for the **Accounts: Limit local account use of blank passwords to console logon only** security policy setting.
## Reference
-
The **Accounts: Limit local account use of blank passwords to console logon only** policy setting determines whether remote interactive logons by network services such as Remote Desktop Services, Telnet, and File Transfer Protocol (FTP) are allowed for local accounts that have blank passwords. If this policy setting is enabled, a local account must have a nonblank password to be used to perform an interactive or network logon from a remote client.
This policy setting does not affect interactive logons that are performed physically at the console or logons that use domain accounts. It is possible for non-Microsoft applications that use remote interactive logons to bypass this policy setting.
-
Blank passwords are a serious threat to computer security and they should be forbidden through both corporate policy and suitable technical measures. Nevertheless, if a user with the ability to create new accounts creates one that has bypassed your domain-based password policy settings, that account might have a blank password. For example, a user could build a stand-alone system, create one or more accounts with blank passwords, and then join the computer to the domain. The local accounts with blank passwords would still function. Anyone who knows the account name can then use accounts with blank passwords to log on to systems.
Devices that are not in physically secure locations should always enforce strong password policies for all local user accounts. Otherwise, anyone with physical access to the device can log on by using a user account that does not have a password. This is especially important for portable devices.
@@ -33,9 +30,7 @@ If you apply this security policy to the Everyone group, no one will be able to
### Possible values
- Enabled
-
- Disabled
-
- Not defined
### Best practices
@@ -50,50 +45,17 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Sec
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
-
-
-
-
-
-
-
-
-
-Default Domain Policy |
-Not defined |
-
-
-Default Domain Controller Policy |
-Not defined |
-
-
-Stand-Alone Server Default Settings |
-Enabled |
-
-
-DC Effective Default Settings |
-Enabled |
-
-
-Member Server Effective Default Settings |
-Enabled |
-
-
-Client Computer Effective Default Settings |
-Enabled |
-
-
-
-
+| Server type or GPO | Default value |
+| - | - |
+| Default Domain Policy | Not defined |
+| Default Domain Controller Policy | Not defined |
+| Stand-Alone Server Default Settings | Enabled |
+| DC Effective Default Settings | Enabled |
+| Member Server Effective Default Settings | Enabled |
+| Client Computer Effective Default Settings | Enabled |
-
## Policy management
-
This section describes features and tools that are available to help you manage this policy.
### Restart requirement
@@ -110,7 +72,6 @@ This policy setting can be configured by using the Group Policy Management Conso
## Security considerations
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
@@ -126,15 +87,4 @@ Enable the **Accounts: Limit local account use of blank passwords to console log
None. This is the default configuration.
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/accounts-rename-administrator-account.md b/windows/keep-secure/accounts-rename-administrator-account.md
index 235aa109e5..8873990424 100644
--- a/windows/keep-secure/accounts-rename-administrator-account.md
+++ b/windows/keep-secure/accounts-rename-administrator-account.md
@@ -5,21 +5,19 @@ ms.assetid: d21308eb-7c60-4e48-8747-62b8109844f9
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Accounts: Rename administrator account
-
**Applies to**
-
- Windows 10
This security policy reference topic for the IT professional describes the best practices, location, values, and security considerations for this policy setting.
## Reference
-
The **Accounts: Rename administrator account** policy setting determines whether a different account name is associated with the security identifier (SID) for the administrator account.
Because the administrator account exists on all Windows 10 for desktop editions (Home, Pro, Enterprise, and Education), renaming the account makes it slightly more difficult for attackers to guess this user name and password combination.
@@ -27,67 +25,30 @@ Because the administrator account exists on all Windows 10 for desktop editions
Rename the Administrator account by specifying a value for the **Accounts: Rename administrator account** policy setting.
### Possible values
-
- User-defined text
-
- Not defined
### Best practices
-
- Be sure to inform users who are authorized to use this account of the new account name.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
-
-
-
-
-
-
-
-
-
-Default Domain Policy |
-Not defined |
-
-
-Default Domain Controller Policy |
-Not defined |
-
-
-Stand-Alone Server Default Settings |
-Administrator |
-
-
-DC Effective Default Settings |
-Administrator |
-
-
-Member Server Effective Default Settings |
-Administrator |
-
-
-Client Computer Effective Default Settings |
-Administrator |
-
-
-
-
+| Server type or GPO | Default value |
+| - | - |
+| Default Domain Policy | Not defined |
+| Default Domain Controller Policy | Not defined |
+| Stand-Alone Server Default Settings | Administrator |
+| DC Effective Default Settings | Administrator |
+| Member Server Effective Default Settings | Administrator |
+| Client Computer Effective Default Settings | Administrator |
-
## Policy management
-
This section describes features and tools that are available to help you manage this policy.
### Restart requirement
@@ -104,7 +65,6 @@ This policy setting can be configured by using the Group Policy Management Conso
## Security considerations
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
@@ -123,14 +83,6 @@ You must provide users who are authorized to use this account with the new accou
## Related topics
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/accounts-rename-guest-account.md b/windows/keep-secure/accounts-rename-guest-account.md
index 97861315e1..f82b907968 100644
--- a/windows/keep-secure/accounts-rename-guest-account.md
+++ b/windows/keep-secure/accounts-rename-guest-account.md
@@ -5,33 +5,29 @@ ms.assetid: 9b8052b4-bbb9-4cc1-bfee-ce25390db707
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Accounts: Rename guest account
-
**Applies to**
-
- Windows 10
Describes the best practices, location, values, and security considerations for the **Accounts: Rename guest account** security policy setting.
## Reference
-
The **Accounts: Rename guest account** policy setting determines whether a different account name is associated with the security identifier (SID) for the Guest account.
### Possible values
- *User-defined text*
-
- Guest
### Best practices
1. For devices in unsecured locations, renaming the account makes it more difficult for unauthorized users to guess it.
-
2. For computers in secured or trusted locations, keeping the name of the account as Guest provides consistency among devices
### Location
@@ -42,50 +38,17 @@ Computer Configuration\\Windows Settings\\Security Settings
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
-
-
-
-
-
-
-
-
-
-Default Domain Policy |
-Guest |
-
-
-Default Domain Controller Policy |
-Guest |
-
-
-Stand-Alone Server Default Settings |
-Guest |
-
-
-DC Effective Default Settings |
-Guest |
-
-
-Member Server Effective Default Settings |
-Guest |
-
-
-Client Computer Effective Default Settings |
-User-defined text |
-
-
-
-
+| Server type or GPO | Default value |
+| - | - |
+| Default Domain Policy | Guest |
+| Default Domain Controller Policy | Guest |
+| Stand-Alone Server Default Settings | Guest |
+| DC Effective Default Settings | Guest |
+| Member Server Effective Default Settings | Guest |
+| Client Computer Effective Default Settings | *User-defined text* |
-
## Policy management
-
This section describes features and tools that are available to help you manage this policy.
### Restart requirement
@@ -102,12 +65,12 @@ This policy setting can be configured by using the Group Policy Management Conso
## Security considerations
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
-The guest account exists in all Windows server and client operating system versions beginning with Windows Server 2003 and Windows XP Professional. Because the account name is well known, it provides a vector for a malicious user to get access to network resources and attempt to elevate privileges or install software that could be used for a later attack on your system.
+The guest account exists in all Windows server and client operating system versions beginning with Windows Server 2003 and Windows XP Professional. Because the account name is well known, it provides a vector for a malicious user to get access to network resources and attempt to elevate privileges
+or install software that could be used for a later attack on your system.
### Countermeasure
@@ -119,14 +82,6 @@ There should be little impact because the Guest account is disabled by default i
## Related topics
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/act-as-part-of-the-operating-system.md b/windows/keep-secure/act-as-part-of-the-operating-system.md
index 7606abc181..5d4a39d466 100644
--- a/windows/keep-secure/act-as-part-of-the-operating-system.md
+++ b/windows/keep-secure/act-as-part-of-the-operating-system.md
@@ -5,35 +5,28 @@ ms.assetid: c1b7e084-a9f7-4377-b678-07cc913c8b0c
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Act as part of the operating system
-
**Applies to**
-
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Act as part of the operating system** security policy setting.
## Reference
-
The **Act as part of the operating system** policy setting determines whether a process can assume the identity of any user and thereby gain access to the resources that the user is authorized to access. Typically, only low-level authentication services require this user right. Potential access is not limited to what is associated with the user by default. The calling process may request that arbitrary additional privileges be added to the access token. The calling process may also build an access token that does not provide a primary identity for auditing in the system event logs.
-
Constant: SeTcbPrivilege
### Possible values
-
- User-defined list of accounts
-
- Not defined
### Best practices
-
- Do not assign this right to any user accounts. Only assign this user right to trusted users.
-
- If a service requires this user right, configure the service to log on by using the local System account, which inherently includes this user right. Do not create a separate account and assign this user right to it.
### Location
@@ -44,50 +37,17 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Use
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
-
-
-
-
-
-
-
-
-
-
-Default domain policy |
-Not defined |
-
-
-Default domain controller policy |
-Not defined |
-
-
-Stand-alone server default settings |
-Not defined |
-
-
-Domain controller effective default settings |
-Not defined |
-
-
-Member server effective default settings |
-Not defined |
-
-
-Client computer effective default settings |
-Not defined |
-
-
-
-
+| Server type or GPO | Default value |
+| - | - |
+| Default domain policy | Not defined |
+| Default domain controller policy| Not defined |
+| Stand-alone server default settings | Not defined |
+| Domain controller effective default settings | Not defined |
+| Member server effective default settings | Not defined |
+| Client computer effective default settings | Not defined |
-
## Policy management
-
A restart of the device is not required for this policy setting to be effective.
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
@@ -95,20 +55,15 @@ Any change to the user rights assignment for an account becomes effective the ne
### Group Policy
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
## Security considerations
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
@@ -124,15 +79,5 @@ Restrict the **Act as part of the operating system** user right to as few accoun
There should be little or no impact because the **Act as part of the operating system** user right is rarely needed by any accounts other than the Local System account.
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
-
-
+
\ No newline at end of file
diff --git a/windows/keep-secure/ad-ds-schema-extensions-to-support-tpm-backup.md b/windows/keep-secure/ad-ds-schema-extensions-to-support-tpm-backup.md
index 6916504ad6..214bc1763d 100644
--- a/windows/keep-secure/ad-ds-schema-extensions-to-support-tpm-backup.md
+++ b/windows/keep-secure/ad-ds-schema-extensions-to-support-tpm-backup.md
@@ -5,21 +5,19 @@ ms.assetid: beb7097c-e674-4eab-b8e2-6f67c85d1f3f
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# AD DS schema extensions to support TPM backup
-
**Applies to**
-
- Windows 10
This topic provides more details about this change and provides template schema extensions that you can incorporate into your organization.
## Why a schema extension is needed
-
The TPM owner authorization value is now stored in a separate object which is linked to the Computer object. This value was stored as a property in the Computer object itself for the default Windows Server 2008 R2 schemas. Windows Server 2012 domain controllers have the default schema to backup TPM owner authorization information in the separate object. If you are not upgrading your domain controller to Windows Server 2012 you need to extend the schema to support this change. If Active Directory backup of the TPM owner authorization value is enabled in a Windows Server 2008 R2 environment without extending the schema, the TPM provisioning will fail and the TPM will remain in a Not Ready state for computers running Windows 8. The following are the two schema extensions that you can use to bring your Windows Server 2008 R2 domain to parity with Windows Server 2012:
### TpmSchemaExtension.ldf
@@ -48,11 +46,9 @@ This schema extension brings parity with the Windows Server 2012 schema and is r
# http://support.microsoft.com/default.aspx?scid=kb;en-us;237677
#
#===============================================================================
-
#===============================================================================
# New schema attributes
#===============================================================================
-
#
# ms-TPM-Srk-Pub-Thumbprint
# GUID: 19d706eb-4d76-44a2-85d6-1c342be3be37
@@ -72,7 +68,6 @@ schemaIdGuid:: 6wbXGXZNokSF1hw0K+O+Nw==
showInAdvancedViewOnly: TRUE
isMemberOfPartialAttributeSet: FALSE
rangeUpper: 20
-
#
# ms-TPM-Owner-Information-Temp
# GUID: c894809d-b513-4ff8-8811-f4f43f5ac7bc
@@ -92,7 +87,6 @@ rangeUpper: 128
schemaIdGuid:: nYCUyBO1+E+IEfT0P1rHvA==
showInAdvancedViewOnly: TRUE
isMemberOfPartialAttributeSet: FALSE
-
#
# ms-TPM-Tpm-Information-For-Computer
# GUID: ea1b7b93-5e48-46d5-bc6c-4df4fda78a35
@@ -113,7 +107,6 @@ schemaIdGuid:: k3sb6khe1Ua8bE30/aeKNQ==
showInAdvancedViewOnly: TRUE
isMemberOfPartialAttributeSet: FALSE
linkId: 2182
-
#
# ms-TPM-TpmInformation-For-Computer-BL
# GUID: 14fa84c9-8ecd-4348-bc91-6d3ced472ab7
@@ -134,41 +127,33 @@ schemaIdGuid:: yYT6FM2OSEO8kW087Ucqtw==
showInAdvancedViewOnly: TRUE
systemOnly: TRUE
linkId: 2183
-
#
# Commit the new attributes
#
-
dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-
-
#
# Modify the Computer schema to support the TPM link
#
-
dn: CN=computer,CN=Schema,CN=Configuration,DC=X
changetype: modify
add: mayContain
mayContain: msTPM-TpmInformationForComputer
-
-
#
# Commit the modification to the computer class
#
-
dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-
-
#===============================================================================
# New schema classes
#===============================================================================
-
#
# ms-TPM-Information-Objects-Container
# GUID: e027a8bd-6456-45de-90a3-38593877ee74
@@ -189,7 +174,6 @@ schemaIdGUID:: vagn4FZk3kWQozhZOHfudA==
defaultSecurityDescriptor: D:(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)(A;;LOLCCCRP;;;DC)
defaultHidingValue: TRUE
defaultObjectCategory: CN=ms-TPM-Information-Objects-Container,CN=Schema,CN=Configuration,DC=X
-
#
# ms-TPM-Information-Object
# GUID: 85045b6a-47a6-4243-a7cc-6890701f662c
@@ -218,21 +202,17 @@ defaultObjectCategory: CN=ms-TPM-Information-Object,CN=Schema,CN=Configuration,D
# NOTE: If the 'defaultSecurityDescriptor' value above is changed,
# also change the other '.ldf' files in this directory, as appropriate.
#
-
#
# Commit the new TPM object class
#
-
dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-
-
#===============================================================================
# New objects
#===============================================================================
-
#
# Add the TPM container to its location in the directory
#
@@ -246,12 +226,8 @@ You should be aware that only the Computer object that has created the TPM objec
### TpmSchemaExtensionACLChanges.ldf
This schema update modifies the ACLs on the TPM object to be less restrictive so that any subsequent operating system which takes ownership of the computer object can update the owner authorization value in AD DS.
-
-**Important**
-After implementing this schema update, any computer in the domain can update the OwnerAuth of the TPM object (although it cannot read the OwnerAuth). When using this extension, perform a regular backup of the TPM objects and enable auditing to track the changes for these objects.
-
+> **Important** After implementing this schema update, any computer in the domain can update the OwnerAuth of the TPM object (although it cannot read the OwnerAuth). When using this extension, perform a regular backup of the TPM objects and enable auditing to track the changes for these objects.
-
``` syntax
#===============================================================================
#
@@ -268,7 +244,6 @@ After implementing this schema update, any computer in the domain can update the
#
# This conversion does not apply to any 'ms-TPM-Information-Object' that
# was created before the conversion.
-
#
# Change History:
# 12/2011 - Created
@@ -283,7 +258,6 @@ After implementing this schema update, any computer in the domain can update the
# http://support.microsoft.com/default.aspx?scid=kb;en-us;237677
#
#===============================================================================
-
#
# Modify the TPM-Information-Object class schema 'defaultSecurityDescriptor' to
# allow any Domain Computer to write its properties (including the TPM OwnerAuth
@@ -293,29 +267,19 @@ After implementing this schema update, any computer in the domain can update the
# with the value in the TPM-Information-Object class description in the
# 'TpmSchemaExtension.ldf' file
#
-
dn: CN=ms-TPM-Information-Object,CN=Schema,CN=Configuration,DC=X
changetype: modify
replace: defaultSecurityDescriptor
defaultSecurityDescriptor: D:(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPWPLO;;;DC)
-
-
#
# Commit the modification to the TPM-Information-Object schema
#
-
dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-
```
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/add-apps-to-protected-list-using-custom-uri.md b/windows/keep-secure/add-apps-to-protected-list-using-custom-uri.md
index 4936bb7028..3f9700cfb4 100644
--- a/windows/keep-secure/add-apps-to-protected-list-using-custom-uri.md
+++ b/windows/keep-secure/add-apps-to-protected-list-using-custom-uri.md
@@ -1,6 +1,6 @@
---
title: Add multiple apps to your enterprise data protection (EDP) Protected Apps list (Windows 10)
-description: Add multiple apps to your enterprise data protection (EDP) Protected Apps list at the same time, by using the Microsoft Intune Custom URI functionality and the AppLocker Group Policy.
+description: Add multiple apps to your enterprise data protection (EDP) Protected Apps list at the same time, by using the Microsoft Intune Custom URI functionality and the AppLocker.
ms.assetid: b50db35d-a2a9-4b78-a95d-a1b066e66880
keywords: ["EDP", "Enterprise Data Protection", "protected apps", "protected app list"]
ms.prod: W10
@@ -17,7 +17,7 @@ author: eross-msft
[Some information relates to pre-released product, which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.]
-Add multiple apps to your enterprise data protection (EDP) **Protected Apps** list at the same time, by using the Microsoft Intune Custom URI functionality and the AppLocker Group Policy. For more info about how to create a custom URI using Intune, see [Windows 10 custom policy settings in Microsoft Intune](http://go.microsoft.com/fwlink/p/?LinkID=691330).
+Add multiple apps to your enterprise data protection (EDP) **Protected Apps** list at the same time, by using the Microsoft Intune Custom URI functionality and AppLocker. For more info about how to create a custom URI using Intune, see [Windows 10 custom policy settings in Microsoft Intune](http://go.microsoft.com/fwlink/p/?LinkID=691330).
**Important**
Results can be unpredictable if you configure your policy using both the UI and the Custom URI method together. We recommend using a single method for each policy.
@@ -26,7 +26,7 @@ If you only want to add one app at a time, you can follow the instructions in th
**To add Universal Windows Platform (UWP) apps**
-1. Go to the AppLocker Group Policy UI by opening a command line window and running secpol.msc. The local security policy MMC snap-in opens showing the **Security Settings**.
+1. Go to the AppLocker UI by opening a command line window and running secpol.msc. The local security policy MMC snap-in opens showing the **Security Settings**.
2. Double-click **Application Control Policies**, double-click **AppLocker**, right-click **Packaged app Rules**, and then click **Automatically Generate Rules**.
The **Automatically Generate Packaged app Rules** wizard opens, letting you create EDP-protected app polices for all of the installed apps on the device or for packaged apps within a specific folder.
@@ -69,7 +69,7 @@ After saving the policy, you’ll need to deploy it to your employee’s devices
**To add Classic Windows applications**
-1. Go to the AppLocker Group Policy UI by opening a command line window and running secpol.msc. The local security policy MMC snap-in opens showing the **Security Settings**.
+1. Go to the AppLocker UI by opening a command line window and running secpol.msc. The local security policy MMC snap-in opens showing the **Security Settings**.
2. Double-click **Application Control Policies**, double-click **AppLocker**, right-click **Executable Rules**, and then click **Automatically Generate Rules**.
The **Automatically Generate Executable Rules** wizard opens, letting you create EDP-protected app polices by analyzing the files within a specific folder.
diff --git a/windows/keep-secure/add-rules-for-packaged-apps-to-existing-applocker-rule-set.md b/windows/keep-secure/add-rules-for-packaged-apps-to-existing-applocker-rule-set.md
index 6a390e94d9..c05eb4ebd2 100644
--- a/windows/keep-secure/add-rules-for-packaged-apps-to-existing-applocker-rule-set.md
+++ b/windows/keep-secure/add-rules-for-packaged-apps-to-existing-applocker-rule-set.md
@@ -5,14 +5,13 @@ ms.assetid: 758c2a9f-c2a3-418c-83bc-fd335a94097f
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Add rules for packaged apps to existing AppLocker rule-set
-
**Applies to**
-
- Windows 10
This topic for IT professionals describes how to update your existing AppLocker policies for packaged apps using the Remote Server Administration Toolkit (RSAT).
@@ -20,12 +19,5 @@ This topic for IT professionals describes how to update your existing AppLocker
You can create packaged app rules for the computers running Windows Server 2012 or Windows 8 and later in your domain by updating your existing AppLocker rule set. All you need is a computer running at least Windows 8. Download and install the Remote Server Administration Toolkit (RSAT) from the Microsoft Download Center.
RSAT comes with the Group Policy Management Console which allows you to edit the GPO or GPOs where your existing AppLocker policy are authored. RSAT has the necessary files required to author packaged app rules. Packaged app rules will be ignored on computers running Windows 7 and earlier but will be enforced on those computers in your domain running at least Windows Server 2012 and Windows 8.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/add-workstations-to-domain.md b/windows/keep-secure/add-workstations-to-domain.md
index c16e08f043..7cdeb90a8b 100644
--- a/windows/keep-secure/add-workstations-to-domain.md
+++ b/windows/keep-secure/add-workstations-to-domain.md
@@ -5,23 +5,20 @@ ms.assetid: b0c21af4-c928-4344-b1f1-58ef162ad0b3
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Add workstations to domain
-
**Applies to**
-
- Windows 10
Describes the best practices, location, values, policy management and security considerations for the **Add workstations to domain** security policy setting.
## Reference
-
This policy setting determines which users can add a device to a specific domain. For it to take effect, it must be assigned so that it applies to at least one domain controller. A user who is assigned this user right can add up to ten workstations to the domain.
-
Adding a machine account to the domain allows the device to participate in Active Directory-based networking.
Constant: SeMachineAccountPrivilege
@@ -29,7 +26,6 @@ Constant: SeMachineAccountPrivilege
### Possible values
- User-defined list of accounts
-
- Not Defined
### Best practices
@@ -46,50 +42,17 @@ By default, this setting allows access for Authenticated Users on domain control
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
-
-
-
-
-
-
-
-
-
-
-Default Domain Policy |
-Not Defined |
-
-
-Default Domain Controller Policy |
-Not Defined |
-
-
-Stand-Alone Server Default Settings |
-Not Defined |
-
-
-Domain Controller Effective Default Settings |
-Authenticated Users |
-
-
-Member Server Effective Default Settings |
-Not Defined |
-
-
-Client Computer Effective Default Settings |
-Not Defined |
-
-
-
-
-
+| Server type or GPO | Default value |
+| - | - |
+| Default Domain Policy | Not Defined |
+| Default Domain Controller Policy | Not Defined |
+| Stand-Alone Server Default Settings | Not Defined |
+| Domain Controller Effective Default Settings | Authenticated Users |
+| Member Server Effective Default Settings | Not Defined |
+| Client Computer Effective Default Settings | Not Defined |
## Policy management
-
Users can also join a computer to a domain if they have the Create Computer Objects permission for an organizational unit (OU) or for the Computers container in the directory. Users who are assigned this permission can add an unlimited number of devices to the domain regardless of whether they have the **Add workstations to domain** user right.
Furthermore, machine accounts that are created by means of the **Add workstations to domain** user right have Domain Administrators as the owner of the machine account. Machine accounts that are created by means of permissions on the computer’s container use the creator as the owner of the machine account. If a user has permissions on the container and also has the **Add workstation to domain** user right, the device is added based on the computer container permissions rather than the user right.
@@ -103,23 +66,20 @@ Any change to the user rights assignment for an account becomes effective the ne
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
## Security considerations
-
This policy has the following security considerations:
### Vulnerability
-The **Add workstations to domain** user right presents a moderate vulnerability. Users with this right could add a device to the domain that is configured in a way that violates organizational security policies. For example, if your organization does not want its users to have administrative privileges on their devices, users could install Windows on their computers and then add the computers to the domain. The user would know the password for the local administrator account, could log on with that account, and then add a personal domain account to the local Administrators group.
+The **Add workstations to domain** user right presents a moderate vulnerability. Users with this right could add a device to the domain that is configured in a way that violates organizational security policies. For example, if your organization does not want its users to have administrative
+privileges on their devices, users could install Windows on their computers and then add the computers to the domain. The user would know the password for the local administrator account, could log on with that account, and then add a personal domain account to the local Administrators group.
### Countermeasure
@@ -130,15 +90,6 @@ Configure this setting so that only authorized members of the IT team are allowe
For organizations that have never allowed users to set up their own computers and add them to the domain, this countermeasure has no impact. For those that have allowed some or all users to configure their own devices, this countermeasure forces the organization to establish a formal process for these procedures going forward. It does not affect existing computers unless they are removed from and then added to the domain.
## Related topics
-
-
-[User Rights Assignment](user-rights-assignment.md)
-
+- [User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/adjust-memory-quotas-for-a-process.md b/windows/keep-secure/adjust-memory-quotas-for-a-process.md
index c49d52f51b..4568ef9fe0 100644
--- a/windows/keep-secure/adjust-memory-quotas-for-a-process.md
+++ b/windows/keep-secure/adjust-memory-quotas-for-a-process.md
@@ -5,21 +5,19 @@ ms.assetid: 6754a2c8-6d07-4567-9af3-335fd8dd7626
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Adjust memory quotas for a process
-
**Applies to**
-
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Adjust memory quotas for a process** security policy setting.
## Reference
-
This privilege determines who can change the maximum memory that can be consumed by a process. This privilege is useful for system tuning on a group or user basis.
This user right is defined in the Default Domain Controller Group Policy Object (GPO) and in the local security policy of workstations and servers.
@@ -29,13 +27,11 @@ Constant: SeIncreaseQuotaPrivilege
### Possible values
- User-defined list of accounts
-
- Not Defined
### Best practices
1. Restrict the **Adjust memory quotas for a process** user right to only users who require the ability to adjust memory quotas to perform their jobs.
-
2. If this user right is necessary for a user account, it can be assigned to a local machine account instead of to a domain account.
### Location
@@ -48,62 +44,17 @@ By default, members of the Administrators, Local Service, and Network Service gr
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
-
-
-
-
-
-
-
-
-
-Default Domain Policy |
-Administrators
-Local Service
-Network Service |
-
-
-Default Domain Controller Policy |
-Administrators
-Local Service
-Network Service |
-
-
-Stand-Alone Server Default Settings |
-Administrators
-Local Service
-Network Service |
-
-
-Domain Controller Effective Default Settings |
-Administrators
-Local Service
-Network Service |
-
-
-Member Server Effective Default Settings |
-Administrators
-Local Service
-Network Service |
-
-
-Client Computer Effective Default Settings |
-Administrators
-Local Service
-Network Service |
-
-
-
-
+| Server type or GPO | Default value |
+| - | - |
+| Default Domain Policy | Administrators
Local Service
Network Service |
+| Default Domain Controller Policy | Administrators
Local Service
Network Service |
+| Stand-Alone Server Default Settings | Administrators
Local Service
Network Service |
+| Domain Controller Effective Default Settings | Administrators
Local Service
Network Service |
+| Member Server Effective Default Settings | Administrators
Local Service
Network Service |
+| Client Computer Effective Default Settings | Administrators
Local Service
Network Service |
-
## Policy management
-
A restart of the device is not required for this policy setting to be effective.
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
@@ -113,18 +64,14 @@ Any change to the user rights assignment for an account becomes effective the ne
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
## Security considerations
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
@@ -140,15 +87,6 @@ Restrict the **Adjust memory quotas for a process** user right to users who requ
Organizations that have not restricted users to roles with limited privileges may find it difficult to impose this countermeasure. Also, if you have installed optional components such as ASP.NET or IIS, you may need to assign the **Adjust memory quotas for a process** user right to additional accounts that are required by those components. IIS requires that this privilege be explicitly assigned to the IWAM\_<ComputerName>, Network Service, and Service accounts. Otherwise, this countermeasure should have no impact on most computers. If this user right is necessary for a user account, it can be assigned to a local computer account instead of to a domain account.
## Related topics
-
-
-[User Rights Assignment](user-rights-assignment.md)
-
+- [User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/administer-applocker.md b/windows/keep-secure/administer-applocker.md
index f2aa9aa68d..232b69b1ef 100644
--- a/windows/keep-secure/administer-applocker.md
+++ b/windows/keep-secure/administer-applocker.md
@@ -5,14 +5,13 @@ ms.assetid: 511a3b6a-175f-4d6d-a6e0-c1780c02e818
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Administer AppLocker
-
**Applies to**
-
- Windows 10
This topic for IT professionals provides links to specific procedures to use when administering AppLocker policies.
@@ -20,89 +19,31 @@ This topic for IT professionals provides links to specific procedures to use whe
AppLocker helps administrators control how users can access and use files, such as executable files, packaged apps, scripts, Windows Installer files, and DLLs. Using AppLocker, you can:
- Define rules based on file attributes derived from the digital signature, including the publisher, product name, file name, and file version. For example, you can create rules based on the publisher attribute that is persistent through updates, or you can create rules for a specific version of a file.
-
- Assign a rule to a security group or an individual user.
-
- Create exceptions to rules. For example, you can create a rule that allows all Windows processes to run, except Registry Editor (regedit.exe).
-
- Use audit-only mode to deploy the policy and understand its impact before enforcing it.
-
- Import and export rules. The import and export affects the entire policy. For example, if you export a policy, all of the rules from all of the rule collections are exported, including the enforcement settings for the rule collections. If you import a policy, the existing policy is overwritten.
-
- Simplify creating and managing AppLocker rules by using AppLocker PowerShell cmdlets.
-
-**Note**
-For more info about enhanced capabilities of AppLocker to control Windows apps, see [Packaged apps and packaged app installer rules in AppLocker](packaged-apps-and-packaged-app-installer-rules-in-applocker.md).
-
+> **Note** For more info about enhanced capabilities of AppLocker to control Windows apps, see [Packaged apps and packaged app installer rules in AppLocker](packaged-apps-and-packaged-app-installer-rules-in-applocker.md).
-
## In this section
-
-
-
-
-
-
-
-
-
-
-
-[Maintain AppLocker policies](maintain-applocker-policies.md) |
-This topic describes how to maintain rules within AppLocker policies. |
-
-
-[Edit an AppLocker policy](edit-an-applocker-policy.md) |
-This topic for IT professionals describes the steps required to modify an AppLocker policy. |
-
-
-[Test and update an AppLocker policy](test-and-update-an-applocker-policy.md) |
-This topic discusses the steps required to test an AppLocker policy prior to deployment. |
-
-
-[Deploy AppLocker policies by using the enforce rules setting](deploy-applocker-policies-by-using-the-enforce-rules-setting.md) |
-This topic for IT professionals describes the steps to deploy AppLocker policies by using the enforcement setting method. |
-
-
-[Use the AppLocker Windows PowerShell cmdlets](use-the-applocker-windows-powershell-cmdlets.md) |
-This topic for IT professionals describes how each AppLocker Windows PowerShell cmdlet can help you administer your AppLocker application control policies. |
-
-
-[Use AppLocker and Software Restriction Policies in the same domain](use-applocker-and-software-restriction-policies-in-the-same-domain.md) |
-This topic for IT professionals describes concepts and procedures to help you manage your application control strategy using Software Restriction Policies and AppLocker. |
-
-
-[Optimize AppLocker performance](optimize-applocker-performance.md) |
-This topic for IT professionals describes how to optimize AppLocker policy enforcement. |
-
-
-[Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md) |
-This topic for IT professionals describes how to monitor app usage when AppLocker policies are applied. |
-
-
-[Manage packaged apps with AppLocker](manage-packaged-apps-with-applocker.md) |
-This topic for IT professionals describes concepts and lists procedures to help you manage Packaged apps with AppLocker as part of your overall application control strategy. |
-
-
-[Working with AppLocker rules](working-with-applocker-rules.md) |
-This topic for IT professionals describes AppLocker rule types and how to work with them for your application control policies. |
-
-
-[Working with AppLocker policies](working-with-applocker-policies.md) |
-This topic for IT professionals provides links to procedural topics about creating, maintaining, and testing AppLocker policies. |
-
-
-
-
-
+| Topic | Description |
+| - | - |
+| [Maintain AppLocker policies](maintain-applocker-policies.md) | This topic describes how to maintain rules within AppLocker policies. |
+| [Edit an AppLocker policy](edit-an-applocker-policy.md) | This topic for IT professionals describes the steps required to modify an AppLocker policy. |
+| [Test and update an AppLocker policy](test-and-update-an-applocker-policy.md) | This topic discusses the steps required to test an AppLocker policy prior to deployment. |
+| [Deploy AppLocker policies by using the enforce rules setting](deploy-applocker-policies-by-using-the-enforce-rules-setting.md) | This topic for IT professionals describes the steps to deploy AppLocker policies by using the enforcement setting method. |
+| [Use the AppLocker Windows PowerShell cmdlets](use-the-applocker-windows-powershell-cmdlets.md) | This topic for IT professionals describes how each AppLocker Windows PowerShell cmdlet can help you administer your AppLocker application control policies. |
+| [Use AppLocker and Software Restriction Policies in the same domain](use-applocker-and-software-restriction-policies-in-the-same-domain.md) | This topic for IT professionals describes concepts and procedures to help you manage your application control strategy using Software Restriction Policies and AppLocker. |
+| [Optimize AppLocker performance](optimize-applocker-performance.md) | This topic for IT professionals describes how to optimize AppLocker policy enforcement. |
+| [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md) | This topic for IT professionals describes how to monitor app usage when AppLocker policies are applied. |
+| [Manage packaged apps with AppLocker](manage-packaged-apps-with-applocker.md) | This topic for IT professionals describes concepts and lists procedures to help you manage Packaged apps with AppLocker as part of your overall application control strategy. |
+| [Working with AppLocker rules](working-with-applocker-rules.md) | This topic for IT professionals describes AppLocker rule types and how to work with them for your application control policies. |
+| [Working with AppLocker policies](working-with-applocker-policies.md) | This topic for IT professionals provides links to procedural topics about creating, maintaining, and testing AppLocker policies. |
## Using the MMC snap-ins to administer AppLocker
-
You can administer AppLocker policies by using the Group Policy Management Console to create or edit a Group Policy Object (GPO), or to create or edit an AppLocker policy on a local computer by using the Local Group Policy Editor snap-in or the Local Security Policy snap-in (secpol.msc).
### Administer Applocker using Group Policy
@@ -110,29 +51,17 @@ You can administer AppLocker policies by using the Group Policy Management Conso
You must have Edit Setting permission to edit a GPO. By default, members of the **Domain Admins** group, the **Enterprise Admins** group, and the **Group Policy Creator Owners** group have this permission. Also, the Group Policy Management feature must be installed on the computer.
1. Open the Group Policy Management Console (GPMC).
-
2. Locate the GPO that contains the AppLocker policy to modify, right-click the GPO, and then click **Edit**.
-
3. In the console tree, double-click **Application Control Policies**, double-click **AppLocker**, and then click the rule collection that you want to create the rule for.
### Administer AppLocker on the local PC
1. Click **Start**, type **local security policy**, and then click **Local Security Policy**.
-
2. If the **User Account Control** dialog box appears, confirm that the action it displays is what you want, and then click **Yes**.
-
3. In the console tree of the snap-in, double-click **Application Control Policies**, double-click **AppLocker**, and then click the rule collection that you want to create the rule for.
## Using Windows PowerShell to administer AppLocker
-
For how-to info about administering AppLocker with Windows PowerShell, see [Use the AppLocker Windows PowerShell Cmdlets](use-the-applocker-windows-powershell-cmdlets.md). For reference info and examples how to administer AppLocker with Windows PowerShell, see the [AppLocker cmdlets](http://technet.microsoft.com/library/hh847210.aspx).
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/administer-security-policy-settings.md b/windows/keep-secure/administer-security-policy-settings.md
index 5c25499e20..59bc1ce37f 100644
--- a/windows/keep-secure/administer-security-policy-settings.md
+++ b/windows/keep-secure/administer-security-policy-settings.md
@@ -5,14 +5,13 @@ ms.assetid: 7617d885-9d28-437a-9371-171197407599
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Administer security policy settings
-
**Applies to**
-
- Windows 10
This article discusses different methods to administer security policy settings on a local device or throughout a small- or medium-sized organization.
@@ -24,26 +23,19 @@ Security settings policies are rules that you can configure on a device, or mult
Security settings can control:
- User authentication to a network or device.
-
- The resources that users are permitted to access.
-
- Whether to record a user’s or group’s actions in the event log.
-
- Membership in a group.
For info about each setting, including descriptions, default settings, and management and security considerations, see [Security policy settings reference](security-policy-settings-reference.md).
To manage security configurations for multiple computers, you can use one of the following options:
-
- Edit specific security settings in a GPO.
-
- Use the Security Templates snap-in to create a security template that contains the security policies you want to apply, and then import the security template into a Group Policy Object. A security template is a file that represents a security configuration, and it can be imported to a GPO, or applied to a local device, or it can be used to analyze security.
## What’s changed in how settings are administered?
-
Over time, new ways to manage security policy settings have been introduced, which include new operating system features and the addition of new settings. The following table lists different means by which security policy settings can be administered.
-
@@ -99,30 +91,19 @@ Over time, new ways to manage security policy settings have been introduced, whi
-
-
## Using the Local Security Policy snap-in
-
The Local Security Policy snap-in (Secpol.msc) restricts the view of local policy objects to the following policies and features:
- Account Policies
-
- Local Policies
-
- Windows Firewall with Advanced Security
-
- Network List Manager Policies
-
- Public Key Policies
-
- Software Restriction Policies
-
- Application Control Policies
-
- IP Security Policies on Local Computer
-
- Advanced Audit Policy Configuration
Policies set locally might be overwritten if the computer is joined to the domain.
@@ -131,70 +112,47 @@ The Local Security Policy snap-in is part of the Security Configuration Manager
## Using the secedit command-line tool
-
The secedit command-line tool works with security templates and provides six primary functions:
- The **Configure** parameter helps you resolve security discrepancies between devices by applying the correct security template to the errant server.
-
- The **Analyze** parameter compares the server’s security configuration with the selected template.
-
- The **Import** parameter allows you to create a database from an existing template. The Security Configuration and Analysis tool does this also.
-
- The **Export** parameter allows you to export the settings from a database into a security settings template.
-
- The **Validate** parameter allows you to validate the syntax of each or any lines of text that you created or added to a security template. This ensures that if the template fails to apply syntax, the template will not be the issue.
-
- The **Generate Rollback** parameter saves the server’s current security settings into a security template so it can be used to restore most of the server’s security settings to a known state. The exceptions are that, when applied, the rollback template will not change access control list entries on files or registry entries that were changed by the most recently applied template.
## Using the Security Compliance Manager
-
The Security Compliance Manager is a downloadable tool that helps you plan, deploy, operate, and manage your security baselines for Windows client and server operating systems, and for Microsoft applications. It contains a complete database of recommended security settings, methods to customize your baselines, and the option to implement those settings in multiple formats—including XLS, GPOs, Desired Configuration Management (DCM) packs, or Security Content Automation Protocol (SCAP). The Security Compliance Manager is used to export the baselines to your environment to automate the security baseline deployment and compliance verification process.
**To administer security policies by using the Security Compliance Manager**
1. Download the most recent version. You can find out more info on the [Microsoft Security Guidance](http://blogs.technet.com/b/secguide/) blog.
-
2. Read the relevant security baseline documentation that is included in this tool.
-
3. Download and import the relevant security baselines. The installation process steps you through baseline selection.
-
4. Open the Help and follow instructions how to customize, compare, or merge your security baselines before deploying those baselines.
## Using the Security Configuration Wizard
-
-The Security Configuration Wizard (SCW) guides you through the process of creating, editing, applying, or rolling back a security policy. A security policy that you create with SCW is an .xml file that, when applied, configures services, network security, specific registry values, and audit policy. SCW is a role-based tool: You can use it to create a policy that enables services, firewall rules, and settings that are required for a selected server to perform specific roles. For example, a server might be a file server, a print server, or a domain controller.
+The Security Configuration Wizard (SCW) guides you through the process of creating, editing, applying, or rolling back a security policy. A security policy that you create with SCW is an .xml file that, when applied, configures services, network security, specific registry values, and audit policy.
+SCW is a role-based tool: You can use it to create a policy that enables services, firewall rules, and settings that are required for a selected server to perform specific roles. For example, a server might be a file server, a print server, or a domain controller.
The following are considerations for using SCW:
- SCW disables unnecessary services and provides Windows Firewall with Advanced Security support.
-
- Security policies that are created with SCW are not the same as security templates, which are files with an .inf extension. Security templates contain more security settings than those that can be set with SCW. However, it is possible to include a security template in an SCW security policy file.
-
- You can deploy security policies that you create with SCW by using Group Policy.
-
- SCW does not install or uninstall the features necessary for the server to perform a role. You can install server role-specific features through Server Manager.
-
- SCW detects server role dependencies. If you select a server role, it automatically selects dependent server roles.
-
- All apps that use the IP protocol and ports must be running on the server when you run SCW.
-
- In some cases, you must be connected to the Internet to use the links in the SCW help.
-
-**Note**
-The SCW is available only on Windows Server and only applicable to server installations.
-
+> **Note** The SCW is available only on Windows Server and only applicable to server installations.
-
The SCW can be accessed through Server Manager or by running scw.exe. The wizard steps you through server security configuration to:
- Create a security policy that can be applied to any server on your network.
-
- Edit an existing security policy.
-
- Apply an existing security policy.
-
- Roll back the last applied security policy.
The Security Policy Wizard configures services and network security based on the server’s role, as well as configures auditing and registry settings.
@@ -203,13 +161,11 @@ For more information about SCW, including procedures, see [Security Configuratio
## Working with the Security Configuration Manager
-
The Security Configuration Manager tool set allows you to create, apply, and edit the security for your local device, organizational unit, or domain.
For procedures on how to use the Security Configuration Manager, see [Security Configuration Manager](http://technet.microsoft.com/library/cc758219(WS.10).aspx).
The following table lists the features of the Security Configuration Manager.
-
@@ -244,9 +200,7 @@ The following table lists the features of the Security Configuration Manager.
-
-
### Security Configuration and Analysis
Security Configuration and Analysis is an MMC snap-in for analyzing and configuring local system security.
@@ -257,7 +211,8 @@ The state of the operating system and apps on a device is dynamic. For example,
Regular analysis enables you to track and ensure an adequate level of security on each computer as part of an enterprise risk management program. You can tune the security levels and, most importantly, detect any security flaws that may occur in the system over time.
-Security Configuration and Analysis enables you to quickly review security analysis results. It presents recommendations alongside of current system settings and uses visual flags or remarks to highlight any areas where the current settings do not match the proposed level of security. Security Configuration and Analysis also offers the ability to resolve any discrepancies that analysis reveals.
+Security Configuration and Analysis enables you to quickly review security analysis results. It presents recommendations alongside of current system settings and uses visual flags or remarks to highlight any areas where the current settings do not match the proposed level of security. Security
+Configuration and Analysis also offers the ability to resolve any discrepancies that analysis reveals.
### Security configuration
@@ -274,29 +229,17 @@ To apply a security template to your local device, you can use Security Configur
Security templates can be used to define:
- Account Policies
-
- Password Policy
-
- Account Lockout Policy
-
- Kerberos Policy
-
- Local Policies
-
- Audit Policy
-
- User Rights Assignment
-
- Security Options
-
- Event Log: Application, system, and security Event Log settings
-
- Restricted Groups: Membership of security-sensitive groups
-
- System Services: Startup and permissions for system services
-
- Registry: Permissions for registry keys
-
- File System: Permissions for folders and files
Each template is saved as a text-based .inf file. This enables you to copy, paste, import, or export some or all of the template attributes. With the exceptions of Internet Protocol security and public key policies, all security attributes can be contained in a security template.
@@ -308,17 +251,13 @@ Organizational units, domains, and sites are linked to Group Policy Objects. The
Security settings or security policies are rules that are configured on a device or multiple device for protecting resources on a device or network. Security settings can control:
- How users are authenticated to a network or device
-
- What resources users are authorized to use.
-
- Whether or not a user's or group's actions are recorded in the event log.
-
- Group membership.
You can change the security configuration on multiple computers in two ways:
- Create a security policy by using a security template with Security Templates, and then import the template through security settings to a Group Policy Object.
-
- Change a few select settings with security settings.
### Local Security Policy
@@ -328,19 +267,14 @@ A security policy is a combination of security settings that affect the security
With the local security policy, you can control:
- Who accesses your device.
-
- What resources users are authorized to use on your device.
-
- Whether or not a user’s or group's actions are recorded in the event log.
If your local device is joined to a domain, you are subject to obtaining a security policy from the domain's policy or from the policy of any organizational unit that you are a member of. If you are getting a policy from more than one source, conflicts are resolved in the following order of precedence.
1. Organizational unit policy
-
2. Domain policy
-
3. Site policy
-
4. Local computer policy
If you modify the security settings on your local device by using the local security policy, then you are directly modifying the settings on your device. Therefore, the settings take effect immediately, but this may only be temporary. The settings will actually remain in effect on your local device until the next refresh of Group Policy security settings, when the security settings that are received from Group Policy will override your local settings wherever there are conflicts.
@@ -350,13 +284,9 @@ If you modify the security settings on your local device by using the local secu
For procedures on how to use the Security Configuration Manager, see [Security Configuration Manager How To](http://technet.microsoft.com/library/cc784762(WS.10).aspx). This section contains information in this topic about:
- [Applying security settings](#bkmk-applysecsettings)
-
- [Importing and exporting security templates](#bkmk-impexpsectmpl)
-
- [Analyzing security and viewing results](#bkmk-anasecviewresults)
-
- [Resolving security discrepancies](#bkmk-resolvesecdiffs)
-
- [Automating security configuration tasks](#bkmk-autoseccfgtasks)
### Applying security settings
@@ -364,7 +294,6 @@ For procedures on how to use the Security Configuration Manager, see [Security C
Once you have edited the security settings, the settings are refreshed on the computers in the organizational unit linked to your Group Policy Object:
- When a device is restarted, the settings on that device will be refreshed.
-
- To force a device to refresh its security settings as well as all Group Policy settings, use gpupdate.exe.
**Precedence of a policy when more than one policy is applied to a computer**
@@ -372,22 +301,15 @@ Once you have edited the security settings, the settings are refreshed on the co
For security settings that are defined by more than one policy, the following order of precedence is observed:
1. Organizational Unit Policy
-
2. Domain Policy
-
3. Site Policy
-
4. Local computer Policy
-For example, a workstation that is joined to a domain will have its local security settings overridden by the domain policy wherever there is a conflict. Likewise, if the same workstation is a member of an Organizational Unit, the settings applied from the Organizational Unit's policy will override both the domain and local settings. If the workstation is a member of more than one Organizational Unit, then the Organizational Unit that immediately contains the workstation has the highest order of precedence.
-
-**Note**
-Use gpresult.exe to find out what policies are applied to a device and in what order.
-
+For example, a workstation that is joined to a domain will have its local security settings overridden by the domain policy wherever there is a conflict. Likewise, if the same workstation is a member of an Organizational Unit, the settings applied from the Organizational Unit's policy will override
+both the domain and local settings. If the workstation is a member of more than one Organizational Unit, then the Organizational Unit that immediately contains the workstation has the highest order of precedence.
+> **Note** Use gpresult.exe to find out what policies are applied to a device and in what order.
For domain accounts, there can be only one account policy that includes password policies, account lockout policies, and Kerberos policies.
-
-
**Persistence in security settings**
Security settings may still persist even if a setting is no longer defined in the policy that originally applied it.
@@ -395,9 +317,7 @@ Security settings may still persist even if a setting is no longer defined in th
Persistence in security settings occurs when:
- The setting has not been previously defined for the device.
-
- The setting is for a registry object.
-
- The setting is for a file system object.
All settings applied through local policy or a Group Policy Object are stored in a local database on your device. Whenever a security setting is modified, the computer saves the security setting value to the local database, which retains a history of all the settings that have been applied to the device. If a policy first defines a security setting and then no longer defines that setting, then the setting takes on the previous value in the database. If a previous value does not exist in the database, then the setting does not revert to anything and remains defined as is. This behavior is sometimes called "tattooing."
@@ -455,9 +375,7 @@ Security Configuration and Analysis displays the analysis results by security ar
-
-
If you choose to accept the current settings, the corresponding value in the base configuration is modified to match them. If you change the system setting to match the base configuration, the change will be reflected when you configure the system with Security Configuration and Analysis.
To avoid continued flagging of settings that you have investigated and determined to be reasonable, you can modify the base configuration. The changes are made to a copy of the template.
@@ -467,31 +385,16 @@ To avoid continued flagging of settings that you have investigated and determine
You can resolve discrepancies between analysis database and system settings by:
- Accepting or changing some or all of the values that are flagged or not included in the configuration, if you determine that the local system security levels are valid due to the context (or role) of that computer. These attribute values are then updated in the database and applied to the system when you click **Configure Computer Now**.
-
- Configuring the system to the analysis database values, if you determine the system is not in compliance with valid security levels.
-
- Importing a more appropriate template for the role of that computer into the database as the new base configuration and applying it to the system.
-
Changes to the analysis database are made to the stored template in the database, not to the security template file. The security template file will only be modified if you either return to Security Templates and edit that template or export the stored configuration to the same template file.
-
You should use **Configure Computer Now** only to modify security areas *not* affected by Group Policy settings, such as security on local files and folders, registry keys, and system services. Otherwise, when the Group Policy settings are applied, it will take precedence over local settings—such as account policies. In general, do not use **Configure Computer Now** when you are analyzing security for domain-based clients, since you will have to configure each client individually. In this case, you should return to Security Templates, modify the template, and reapply it to the appropriate Group Policy Object.
### Automating security configuration tasks
By calling the secedit.exe tool at a command prompt from a batch file or automatic task scheduler, you can use it to automatically create and apply templates, and analyze system security. You can also run it dynamically from a command prompt.
-
Secedit.exe is useful when you have multiple devices on which security must be analyzed or configured, and you need to perform these tasks during off-hours.
## Working with Group Policy tools
-
Group Policy is an infrastructure that allows you to specify managed configurations for users and computers through Group Policy settings and Group Policy Preferences. For Group Policy settings that affect only a local device or user, you can use the Local Group Policy Editor. You can manage Group Policy settings and Group Policy Preferences in an Active Directory Domain Services (AD DS) environment through the Group Policy Management Console (GPMC). Group Policy management tools also are included in the Remote Server Administration Tools pack to provide a way for you to administer Group Policy settings from your desktop.
-
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/advanced-security-audit-policy-settings.md b/windows/keep-secure/advanced-security-audit-policy-settings.md
index 41e24e9099..5b5faf0b14 100644
--- a/windows/keep-secure/advanced-security-audit-policy-settings.md
+++ b/windows/keep-secure/advanced-security-audit-policy-settings.md
@@ -5,14 +5,13 @@ ms.assetid: 93b28b92-796f-4036-a53b-8b9e80f9f171
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Advanced security audit policy settings
-
**Applies to**
-
- Windows 10
This reference for IT professionals provides information about the advanced audit policy settings that are available in Windows and the audit events that they generate.
@@ -20,15 +19,12 @@ This reference for IT professionals provides information about the advanced audi
The security audit policy settings under **Security Settings\\Advanced Audit Policy Configuration** can help your organization audit compliance with important business-related and security-related rules by tracking precisely defined activities, such as:
- A group administrator has modified settings or data on servers that contain finance information.
-
- An employee within a defined group has accessed an important file.
-
- The correct system access control list (SACL) is applied to every file and folder or registry key on a computer or file share as a verifiable safeguard against undetected access.
You can access these audit policy settings through the Local Security Policy snap-in (secpol.msc) on the local computer or by using Group Policy.
These advanced audit policy settings allow you to select only the behaviors that you want to monitor. You can exclude audit results for behaviors that are of little or no concern to you, or behaviors that create an excessive number of log entries. In addition, because security audit policies can be applied by using domain Group Policy Objects, audit policy settings can be modified, tested, and deployed to selected users and groups with relative simplicity.
-
Audit policy settings under **Security Settings\\Advanced Audit Policy Configuration** are available in the following categories:
**Account Logon**
@@ -36,11 +32,8 @@ Audit policy settings under **Security Settings\\Advanced Audit Policy Configura
Configuring policy settings in this category can help you document attempts to authenticate account data on a domain controller or on a local Security Accounts Manager (SAM). Unlike Logon and Logoff policy settings and events, which track attempts to access a particular computer, settings and events in this category focus on the account database that is used. This category includes the following subcategories:
- [Audit Credential Validation](audit-credential-validation.md)
-
- [Audit Kerberos Authentication Service](audit-kerberos-authentication-service.md)
-
- [Audit Kerberos Service Ticket Operations](audit-kerberos-service-ticket-operations.md)
-
- [Audit Other Logon/Logoff Events](audit-other-logonlogoff-events.md)
**Account Management**
@@ -48,15 +41,10 @@ Configuring policy settings in this category can help you document attempts to a
The security audit policy settings in this category can be used to monitor changes to user and computer accounts and groups. This category includes the following subcategories:
- [Audit Application Group Management](audit-application-group-management.md)
-
- [Audit Computer Account Management](audit-computer-account-management.md)
-
- [Audit Distribution Group Management](audit-distribution-group-management.md)
-
- [Audit Other Account Management Events](audit-other-account-management-events.md)
-
- [Audit Security Group Management](audit-security-group-management.md)
-
- [Audit User Account Management](audit-user-account-management.md)
**Detailed Tracking**
@@ -64,13 +52,9 @@ The security audit policy settings in this category can be used to monitor chang
Detailed Tracking security policy settings and audit events can be used to monitor the activities of individual applications and users on that computer, and to understand how a computer is being used. This category includes the following subcategories:
- [Audit DPAPI Activity](audit-dpapi-activity.md)
-
- [Audit PNP activity](audit-pnp-activity.md)
-
- [Audit Process Creation](audit-process-creation.md)
-
- [Audit Process Termination](audit-process-termination.md)
-
- [Audit RPC Events](audit-rpc-events.md)
**DS Access**
@@ -78,11 +62,8 @@ Detailed Tracking security policy settings and audit events can be used to monit
DS Access security audit policy settings provide a detailed audit trail of attempts to access and modify objects in Active Directory Domain Services (AD DS). These audit events are logged only on domain controllers. This category includes the following subcategories:
- [Audit Detailed Directory Service Replication](audit-detailed-directory-service-replication.md)
-
- [Audit Directory Service Access](audit-directory-service-access.md)
-
- [Audit Directory Service Changes](audit-directory-service-changes.md)
-
- [Audit Directory Service Replication](audit-directory-service-replication.md)
**Logon/Logoff**
@@ -90,25 +71,15 @@ DS Access security audit policy settings provide a detailed audit trail of attem
Logon/Logoff security policy settings and audit events allow you to track attempts to log on to a computer interactively or over a network. These events are particularly useful for tracking user activity and identifying potential attacks on network resources. This category includes the following subcategories:
- [Audit Account Lockout](audit-account-lockout.md)
-
- [Audit User/Device Claims](audit-user-device-claims.md)
-
- [Audit IPsec Extended Mode](audit-ipsec-extended-mode.md)
-
- [Audit Group Membership](audit-group-membership.md)
-
- [Audit IPsec Main Mode](audit-ipsec-main-mode.md)
-
- [Audit IPsec Quick Mode](audit-ipsec-quick-mode.md)
-
- [Audit Logoff](audit-logoff.md)
-
- [Audit Logon](audit-logon.md)
-
- [Audit Network Policy Server](audit-network-policy-server.md)
-
- [Audit Other Logon/Logoff Events](audit-other-logonlogoff-events.md)
-
- [Audit Special Logon](audit-special-logon.md)
**Object Access**
@@ -120,31 +91,18 @@ Proving that these audit policies are in effect to an external auditor is more d
This category includes the following subcategories:
- [Audit Application Generated](audit-application-generated.md)
-
- [Audit Certification Services](audit-certification-services.md)
-
- [Audit Detailed File Share](audit-detailed-file-share.md)
-
- [Audit File Share](audit-file-share.md)
-
- [Audit File System](audit-file-system.md)
-
- [Audit Filtering Platform Connection](audit-filtering-platform-connection.md)
-
- [Audit Filtering Platform Packet Drop](audit-filtering-platform-packet-drop.md)
-
- [Audit Handle Manipulation](audit-handle-manipulation.md)
-
- [Audit Kernel Object](audit-kernel-object.md)
-
- [Audit Other Object Access Events](audit-other-object-access-events.md)
-
- [Audit Registry](audit-registry.md)
-
- [Audit Removable Storage](audit-removable-storage.md)
-
- [Audit SAM](audit-sam.md)
-
- [Audit Central Access Policy Staging](audit-central-access-policy-staging.md)
**Policy Change**
@@ -152,15 +110,10 @@ This category includes the following subcategories:
Policy Change audit events allow you to track changes to important security policies on a local system or network. Because policies are typically established by administrators to help secure network resources, monitoring changes or attempts to change these policies can be an important aspect of security management for a network. This category includes the following subcategories:
- [Audit Audit Policy Change](audit-audit-policy-change.md)
-
- [Audit Authentication Policy Change](audit-authentication-policy-change.md)
-
- [Audit Authorization Policy Change](audit-authorization-policy-change.md)
-
- [Audit Filtering Platform Policy Change](audit-filtering-platform-policy-change.md)
-
- [Audit MPSSVC Rule-Level Policy Change](audit-mpssvc-rule-level-policy-change.md)
-
- [Audit Other Policy Change Events](audit-other-policy-change-events.md)
**Privilege Use**
@@ -168,9 +121,7 @@ Policy Change audit events allow you to track changes to important security poli
Permissions on a network are granted for users or computers to complete defined tasks. Privilege Use security policy settings and audit events allow you to track the use of certain permissions on one or more systems. This category includes the following subcategories:
- [Audit Non-Sensitive Privilege Use](audit-non-sensitive-privilege-use.md)
-
- [Audit Sensitive Privilege Use](audit-sensitive-privilege-use.md)
-
- [Audit Other Privilege Use Events](audit-other-privilege-use-events.md)
**System**
@@ -178,39 +129,21 @@ Permissions on a network are granted for users or computers to complete defined
System security policy settings and audit events allow you to track system-level changes to a computer that are not included in other categories and that have potential security implications. This category includes the following subcategories:
- [Audit IPsec Driver](audit-ipsec-driver.md)
-
- [Audit Other System Events](audit-other-system-events.md)
-
- [Audit Security State Change](audit-security-state-change.md)
-
- [Audit Security System Extension](audit-security-system-extension.md)
-
- [Audit System Integrity](audit-system-integrity.md)
**Global Object Access**
Global Object Access Auditing policy settings allow administrators to define computer system access control lists (SACLs) per object type for the file system or for the registry. The specified SACL is then automatically applied to every object of that type.
-
Auditors will be able to prove that every resource in the system is protected by an audit policy by viewing the contents of the Global Object Access Auditing policy settings. For example, if auditors see a policy setting called "Track all changes made by group administrators," they know that this policy is in effect.
Resource SACLs are also useful for diagnostic scenarios. For example, setting the Global Object Access Auditing policy to log all the activity for a specific user and enabling the policy to track "Access denied" events for the file system or registry can help administrators quickly identify which object in a system is denying a user access.
-**Note**
-If a file or folder SACL and a Global Object Access Auditing policy setting (or a single registry setting SACL and a Global Object Access Auditing policy setting) are configured on a computer, the effective SACL is derived from combining the file or folder SACL and the Global Object Access Auditing policy. This means that an audit event is generated if an activity matches the file or folder SACL or the Global Object Access Auditing policy.
-
+> **Note:** If a file or folder SACL and a Global Object Access Auditing policy setting (or a single registry setting SACL and a Global Object Access Auditing policy setting) are configured on a computer, the effective SACL is derived from combining the file or folder SACL and the Global Object
+Access Auditing policy. This means that an audit event is generated if an activity matches the file or folder SACL or the Global Object Access Auditing policy.
-
This category includes the following subcategories:
-
- [File System (Global Object Access Auditing)](file-system-global-object-access-auditing.md)
-
- [Registry (Global Object Access Auditing)](registry-global-object-access-auditing.md)
-
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/advanced-security-auditing-faq.md b/windows/keep-secure/advanced-security-auditing-faq.md
index b63076029e..eef52f8d63 100644
--- a/windows/keep-secure/advanced-security-auditing-faq.md
+++ b/windows/keep-secure/advanced-security-auditing-faq.md
@@ -5,69 +5,50 @@ ms.assetid: 80f8f187-0916-43c2-a7e8-ea712b115a06
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Advanced security auditing FAQ
-
**Applies to**
-
- Windows 10
This topic for the IT professional lists questions and answers about understanding, deploying, and managing security audit policies.
- [What is Windows security auditing and why might I want to use it?](#bkmk-1)
-
- [What is the difference between audit policies located in Local Policies\\Audit Policy and audit policies located in Advanced Audit Policy Configuration?](#bkmk-2)
-
- [What is the interaction between basic audit policy settings and advanced audit policy settings?](#bkmk-3)
-
- [How are audit settings merged by Group Policy?](#bkmk-4)
-
- [What is the difference between an object DACL and an object SACL?](#bkmk-14)
-
- [Why are audit policies applied on a per-computer basis rather than per user?](#bkmk-13)
-
- [What are the differences in auditing functionality between versions of Windows?](#bkmk-12)
-
- [Can I use advanced audit policy from a domain controller running Windows Server 2003 or Windows 2000 Server?](#bkmk-15)
-
- [What is the difference between success and failure events? Is something wrong if I get a failure audit?](#bkmk-5)
-
- [How can I set an audit policy that affects all objects on a computer?](#bkmk-6)
-
- [How do I figure out why someone was able to access a resource?](#bkmk-7)
-
- [How do I know when changes are made to access control settings, by whom, and what the changes were?](#bkmk-8)
-
- [How can I roll back security audit policies from the advanced audit policy to the basic audit policy?](#bkmk-19)
-
- [How can I monitor if changes are made to audit policy settings?](#bkmk-10)
-
- [How can I minimize the number of events that are generated?](#bkmk-16)
-
- [What are the best tools to model and manage audit policy?](#bkmk-17)
-
- [Where can I find information about all the possible events that I might receive?](#bkmk-11)
-
- [Where can I find more detailed information?](#bkmk-18)
## What is Windows security auditing and why might I want to use it?
-
Security auditing is a methodical examination and review of activities that may affect the security of a system. In the Windows operating systems, security auditing is more narrowly defined as the features and services that enable an administrator to log and review events for specified security-related activities.
Hundreds of events occur as the Windows operating system and the applications that run on it perform their tasks. Monitoring these events can provide valuable information to help administrators troubleshoot and investigate security-related activities.
## What is the difference between audit policies located in Local Policies\\Audit Policy and audit policies located in Advanced Audit Policy Configuration?
-
The basic security audit policy settings in **Security Settings\\Local Policies\\Audit Policy** and the advanced security audit policy settings in **Security Settings\\Advanced Audit Policy Configuration\\System Audit Policies** appear to overlap, but they are recorded and applied differently. When you apply basic audit policy settings to the local computer by using the Local Security Policy snap-in (secpol.msc), you are editing the effective audit policy, so changes made to basic audit policy settings will appear exactly as configured in Auditpol.exe.
There are a number of additional differences between the security audit policy settings in these two locations.
-There are nine basic audit policy settings under **Security Settings\\Local Policies\\Audit Policy** and settings under **Advanced Audit Policy Configuration**. The settings available in **Security Settings\\Advanced Audit Policy Configuration** address similar issues as the nine basic settings in **Local Policies\\Audit Policy**, but they allow administrators to be more selective in the number and types of events to audit. For example, the basic audit policy provides a single setting for account logon, and the advanced audit policy provides four. Enabling the single basic account logon setting would be the equivalent of setting all four advanced account logon settings. In comparison, setting a single advanced audit policy setting does not generate audit events for activities that you are not interested in tracking.
+There are nine basic audit policy settings under **Security Settings\\Local Policies\\Audit Policy** and settings under **Advanced Audit Policy Configuration**. The settings available in **Security Settings\\Advanced Audit Policy
+Configuration** address similar issues as the nine basic settings in **Local Policies\\Audit Policy**, but they allow administrators to be more selective in the number and types of events to audit. For example, the basic audit policy provides a single setting for account logon, and the advanced audit policy provides four. Enabling the single basic account logon setting would be the equivalent of setting all four advanced account logon settings. In comparison, setting a single advanced audit policy setting does not generate audit events for activities that you are not interested in tracking.
In addition, if you enable success auditing for the basic **Audit account logon events** setting, only success events will be logged for all account logon–related behaviors. In comparison, depending on the needs of your organization, you can configure success auditing for one advanced account logon setting, failure auditing for a second advanced account logon setting, success and failure auditing for a third advanced account logon setting, or no auditing.
@@ -75,73 +56,34 @@ The nine basic settings under **Security Settings\\Local Policies\\Audit Policy*
## What is the interaction between basic audit policy settings and advanced audit policy settings?
-
Basic audit policy settings are not compatible with advanced audit policy settings that are applied by using Group Policy. When advanced audit policy settings are applied by using Group Policy, the current computer's audit policy settings are cleared before the resulting advanced audit policy settings are applied. After you apply advanced audit policy settings by using Group Policy, you can only reliably set system audit policy for the computer by using the advanced audit policy settings.
Editing and applying the advanced audit policy settings in Local Security Policy modifies the local Group Policy Object (GPO), so changes made here may not be exactly reflected in Auditpol.exe if there are policies from other domain GPOs or logon scripts. Both types of policies can be edited and applied by using domain GPOs, and these settings will override any conflicting local audit policy settings. However, because the basic audit policy is recorded in the effective audit policy, that audit policy must be explicitly removed when a change is desired, or it will remain in the effective audit policy. Policy changes that are applied by using local or domain Group Policy settings are reflected as soon as the new policy is applied.
-**Important**
-Whether you apply advanced audit policies by using Group Policy or by using logon scripts, do not use both the basic audit policy settings under **Local Policies\\Audit Policy** and the advanced settings under **Security Settings\\Advanced Audit Policy Configuration**. Using both advanced and basic audit policy settings can cause unexpected results in audit reporting.
+> **Important** Whether you apply advanced audit policies by using Group Policy or by using logon scripts, do not use both the basic audit policy settings under **Local Policies\\Audit Policy** and the advanced settings under **Security Settings\\Advanced Audit Policy Configuration**. Using both advanced and basic audit policy settings can cause unexpected results in audit reporting.
If you use Advanced Audit Policy Configuration settings or use logon scripts to apply advanced audit policies, be sure to enable the **Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings** policy setting under **Local Policies\\Security Options**. This will prevent conflicts between similar settings by forcing basic security auditing to be ignored.
-
-
## How are audit settings merged by Group Policy?
-
By default, policy options that are set in GPOs and linked to higher levels of Active Directory sites, domains, and OUs are inherited by all OUs at lower levels. However, an inherited policy can be overridden by a GPO that is linked at a lower level.
For example, you might use a domain GPO to assign an organization-wide group of audit settings, but want a certain OU to get a defined group of additional settings. To accomplish this, you can link a second GPO to that specific lower-level OU. Therefore, a logon audit setting that is applied at the OU level will override a conflicting logon audit setting that is applied at the domain level (unless you have taken special steps to apply Group Policy loopback processing).
The rules that govern how Group Policy settings are applied propagate to the subcategory level of audit policy settings. This means that audit policy settings configured in different GPOs will be merged if no policy settings configured at a lower level exist. The following table illustrates this behavior.
-
-
-
-
-
-
-
-
-
-
-
-
-Detailed File Share Auditing |
-Success |
-Failure |
-Success |
-
-
-Process Creation Auditing |
-Disabled |
-Success |
-Disabled |
-
-
-Logon Auditing |
-Success |
-Failure |
-Failure |
-
-
-
-
+| Auditing subcategory | Setting configured in an OU GPO (higher priority) | Setting configured in a domain GPO (lower priority) | Resulting policy for the target computer |
+| - | - | - | -|
+| Detailed File Share Auditing | Success | Failure | Success |
+| Process Creation Auditing | Disabled | Success | Disabled |
+| Logon Auditing | Success | Failure | Failure |
## What is the difference between an object DACL and an object SACL?
-
All objects in Active Directory Domain Services (AD DS), and all securable objects on a local computer or on the network, have security descriptors to help control access to the objects. Security descriptors include information about who owns an object, who can access it and in what way, and what types of access are audited. Security descriptors contain the access control list (ACL) of an object, which includes all of the security permissions that apply to that object. An object's security descriptor can contain two types of ACLs:
- A discretionary access control list (DACL) that identifies the users and groups who are allowed or denied access
-
- A system access control list (SACL) that controls how access is audited
The access control model that is used in Windows is administered at the object level by setting different levels of access, or permissions, to objects. If permissions are configured for an object, its security descriptor contains a DACL with security identifiers (SIDs) for the users and groups that are allowed or denied access.
@@ -150,7 +92,6 @@ If auditing is configured for the object, its security descriptor also contains
## Why are audit policies applied on a per-computer basis rather than per user?
-
In security auditing in Windows, the computer, objects on the computer, and related resources are the primary recipients of actions by clients including applications, other computers, and users. In a security breach, malicious users can use alternate credentials to hide their identity, or malicious applications can impersonate legitimate users to perform undesired tasks. Therefore, the most consistent way to apply an audit policy is to focus on the computer and the objects and resources on that computer.
In addition, because audit policy capabilities can vary between computers running different versions of Windows, the best way to ensure that the audit policy is applied correctly is to base these settings on the computer instead of the user.
@@ -159,17 +100,14 @@ However, in cases where you want audit settings to apply only to specified group
## What are the differences in auditing functionality between versions of Windows?
-
Basic audit policy settings are available in all versions of Windows since Windows 2000, and they can be applied locally or by using Group Policy. Advanced audit policy settings were introduced in Windows Vista and Windows Server 2008, but the settings can only be applied by using logon scripts in those versions. Advanced audit policy settings, which were introduced in Windows 7 and Windows Server 2008 R2, can be configured and applied by using local and domain Group Policy settings.
## Can I use advanced audit policies from a domain controller running Windows Server 2003 or Windows 2000 Server?
-
To use advanced audit policy settings, your domain controller must be installed on a computer running Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, or Windows Server 2003 with Service Pack 2 (SP2). Windows 2000 Server is not supported.
## What is the difference between success and failure events? Is something wrong if I get a failure audit?
-
A success audit event is triggered when a defined action, such as accessing a file share, is completed successfully.
A failure audit event is triggered when a defined action, such as a user logon, is not completed successfully.
@@ -178,106 +116,71 @@ The appearance of failure audit events in the event log does not necessarily mea
## How can I set an audit policy that affects all objects on a computer?
-
System administrators and auditors increasingly want to verify that an auditing policy is applied to all objects on a system. This has been difficult to accomplish because the system access control lists (SACLs) that govern auditing are applied on a per-object basis. Thus, to verify that an audit policy has been applied to all objects, you would have to check every object to be sure that no changes have been made—even temporarily to a single SACL.
-
Introduced in Windows Server 2008 R2 and Windows 7, security auditing allows administrators to define global object access auditing policies for the entire file system or for the registry on a computer. The specified SACL is then automatically applied to every object of that type. This can be useful for verifying that all critical files, folders, and registry settings on a computer are protected, and for identifying when an issue with a system resource occurs. If a file or folder SACL and a global object access auditing policy (or a single registry setting SACL and a global object access auditing policy) are configured on a computer, the effective SACL is derived from combining the file or folder SACL and the global object access auditing policy. This means that an audit event is generated if an activity matches either the file or folder SACL or the global object access auditing policy.
## How do I figure out why someone was able to access a resource?
-
Often it is not enough to know simply that an object such as a file or folder was accessed. You may also want to know why the user was able to access this resource. You can obtain this forensic data by configuring the **Audit Handle Manipulation** setting with the **Audit File System** or with the **Audit Registry** audit setting.
## How do I know when changes are made to access control settings, by whom, and what the changes were?
-
To track access control changes on computers running Windows Server 2016 Technical Preview, Windows Server 2012 R2, Windows Server 2012 Windows 7, Windows Server 2008 R2, Windows Vista, or Windows Server 2008, you need to enable the following settings, which track changes to DACLs:
-
- **Audit File System** subcategory: Enable for success, failure, or success and failure
-
- **Audit Authorization Policy Change** setting: Enable for success, failure, or success and failure
-
- A SACL with **Write** and **Take ownership** permissions: Apply to the object that you want to monitor
In Windows XP and Windows Server 2003, you need to use the **Audit policy change** subcategory.
## How can I roll back security audit policies from the advanced audit policy to the basic audit policy?
-
Applying advanced audit policy settings replaces any comparable basic security audit policy settings. If you subsequently change the advanced audit policy setting to **Not configured**, you need to complete the following steps to restore the original basic security audit policy settings:
1. Set all Advanced Audit Policy subcategories to **Not configured**.
-
2. Delete all audit.csv files from the %SYSVOL% folder on the domain controller.
-
3. Reconfigure and apply the basic audit policy settings.
Unless you complete all of these steps, the basic audit policy settings will not be restored.
## How can I monitor if changes are made to audit policy settings?
-
Changes to security audit policies are critical security events. You can use the **Audit Audit Policy Change** setting to determine if the operating system generates audit events when the following types of activities take place:
- Permissions and audit settings on the audit policy object are changed
-
- The system audit policy is changed
-
- Security event sources are registered or unregistered
-
- Per-user audit settings are changed
-
- The value of **CrashOnAuditFail** is modified
-
- Audit settings on a file or registry key are changed
-
- A Special Groups list is changed
## How can I minimize the number of events that are generated?
-
Finding the right balance between auditing enough network and computer activity and auditing too little network and computer activity can be challenging. You can achieve this balance by identifying the most important resources, critical activities, and users or groups of users. Then design a security audit policy that targets these resources, activities, and users. Useful guidelines and recommendations for developing an effective security auditing strategy can be found in [Planning and deploying advanced security audit policies](planning-and-deploying-advanced-security-audit-policies.md).
## What are the best tools to model and manage audit policies?
-
The integration of advanced audit policy settings with domain Group Policy, introduced in Windows 7 and Windows Server 2008 R2, is designed to simplify the management and implementation of security audit policies in an organization's network. As such, tools used to plan and deploy Group Policy Objects for a domain can also be used to plan and deploy security audit policies.
-
On an individual computer, the Auditpol command-line tool can be used to complete a number of important audit policy–related management tasks.
In addition, there are a number of computer management products, such as the Audit Collection Services in the Microsoft System Center Operations Manager products, which can be used to collect and filter event data.
## Where can I find information about all the possible events that I might receive?
-
Users who examine the security event log for the first time can be a bit overwhelmed by the number of audit events that are stored there (which can quickly number in the thousands) and by the structured information that is included for each audit event. Additional information about these events, and the settings used to generate them, can be obtained from the following resources:
- [Windows 8 and Windows Server 2012 Security Event Details](http://www.microsoft.com/download/details.aspx?id=35753)
-
- [Security Audit Events for Windows 7 and Windows Server 2008 R2](http://go.microsoft.com/fwlink/p/?linkid=157780)
-
- [Security Audit Events for Windows Server 2008 and Windows Vista](http://go.microsoft.com/fwlink/p/?linkid=121868)
-
- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
## Where can I find more detailed information?
-
To learn more about security audit policies, see the following resources:
- [Planning and deploying advanced security audit policies](planning-and-deploying-advanced-security-audit-policies.md)
-
- [Security Monitoring and Attack Detection Planning Guide](http://social.technet.microsoft.com/wiki/contents/articles/325.advanced-security-auditing-in-windows-7-and-windows-server-2008-r2.aspx)
-
- [Security Audit Events for Windows 7 and Windows Server 2008 R2](http://go.microsoft.com/fwlink/p/?linkid=157780)
-
- [Security Audit Events for Windows Server 2008 and Windows Vista](http://go.microsoft.com/fwlink/p/?LinkId=121868)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/advanced-security-auditing.md b/windows/keep-secure/advanced-security-auditing.md
index df557dbfd4..5ed85a625d 100644
--- a/windows/keep-secure/advanced-security-auditing.md
+++ b/windows/keep-secure/advanced-security-auditing.md
@@ -5,61 +5,23 @@ ms.assetid: 6FE8AC10-F48E-4BBF-979B-43A5DFDC5DFC
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Advanced security audit policies
-
**Applies to**
-
- Windows 10
Advanced security audit policy settings are found in **Security Settings\\Advanced Audit Policy Configuration\\System Audit Policies** and appear to overlap with basic security audit policies, but they are recorded and applied differently.
-
When you apply basic audit policy settings to the local computer by using the Local Security Policy snap-in, you are editing the effective audit policy, so changes made to basic audit policy settings will appear exactly as configured in Auditpol.exe. In Windows 7 and later, advanced security audit policies can be controlled by using Group Policy.
## In this section
-
-
-
-
-
-
-
-
-
-
-
-[Planning and deploying advanced security audit policies](planning-and-deploying-advanced-security-audit-policies.md) |
-This topic for the IT professional explains the options that security policy planners must consider and the tasks they must complete to deploy an effective security audit policy in a network that includes advanced security audit policies. |
-
-
-[Advanced security auditing FAQ](advanced-security-auditing-faq.md) |
-This topic for the IT professional lists questions and answers about understanding, deploying, and managing security audit policies. |
-
-
-[Using advanced security auditing options to monitor dynamic access control objects](using-advanced-security-auditing-options-to-monitor-dynamic-access-control-objects.md) |
-This guide explains the process of setting up advanced security auditing capabilities that are made possible through settings and events that were introduced in Windows 8 and Windows Server 2012. |
-
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md) |
-This reference for IT professionals provides information about the advanced audit policy settings that are available in Windows and the audit events that they generate. |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+| Topic | Description |
+| - | - |
+| [Planning and deploying advanced security audit policies](planning-and-deploying-advanced-security-audit-policies.md) | This topic for the IT professional explains the options that security policy planners must consider and the tasks they must complete to deploy an effective security audit policy in a network that includes advanced security audit policies |
+| [Advanced security auditing FAQ](advanced-security-auditing-faq.md) | This topic for the IT professional lists questions and answers about understanding, deploying, and managing security audit policies.
+| [Using advanced security auditing options to monitor dynamic access control objects](using-advanced-security-auditing-options-to-monitor-dynamic-access-control-objects.md) | This guide explains the process of setting up advanced security auditing capabilities that are made possible through settings and events that were introduced in Windows 8 and Windows Server 2012.
+| [Advanced security audit policy settings](advanced-security-audit-policy-settings.md) | This reference for IT professionals provides information about the advanced audit policy settings that are available in Windows and the audit events that they generate.
diff --git a/windows/keep-secure/allow-log-on-locally.md b/windows/keep-secure/allow-log-on-locally.md
index 5201d11f22..fdfa7ab402 100644
--- a/windows/keep-secure/allow-log-on-locally.md
+++ b/windows/keep-secure/allow-log-on-locally.md
@@ -5,60 +5,46 @@ ms.assetid: d9e5e1f3-3bff-4da7-a9a2-4bb3e0c79055
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Allow log on locally
-
**Applies to**
-
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Allow log on locally** security policy setting.
## Reference
-
This policy setting determines which users can start an interactive session on the device. Users must have this user right to log on over a Remote Desktop Services session that is running on a Windows-based member device or domain controller.
-
-**Note**
-Users who do not have this right are still able to start a remote interactive session on the device if they have the **Allow logon through Remote Desktop Services** right.
-
+> **Note:** Users who do not have this right are still able to start a remote interactive session on the device if they have the **Allow logon through Remote Desktop Services** right.
-
Constant: SeInteractiveLogonRight
### Possible values
- User-defined list of accounts
-
- Not Defined
By default, the members of the following groups have this right on workstations and servers:
- Administrators
-
- Backup Operators
-
- Users
By default, the members of the following groups have this right on domain controllers:
- Account Operators
-
- Administrators
-
- Backup Operators
-
- Print Operators
-
- Server Operators
### Best practices
1. Restrict this user right to legitimate users who must log on to the console of the device.
-
2. If you selectively remove default groups, you can limit the abilities of users who are assigned to specific administrative roles in your organization.
### Location
@@ -69,74 +55,24 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Use
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
-
-
-
-
-
-
-
-
-
-
-Default Domain Policy |
-Not Defined |
-
-
-Default Domain Controller Policy |
-Account Operators
-Administrators
-Backup Operators
-Print Operators
-Server Operators |
-
-
-Stand-Alone Server Default Settings |
-Administrators
-Backup Operators
-Users |
-
-
-Domain Controller Effective Default Settings |
-Account Operators
-Administrators
-Backup Operators
-Print Operators
-Server Operators |
-
-
-Member Server Effective Default Settings |
-Administrators
-Backup Operators
-Users |
-
-
-Client Computer Effective Default Settings |
-Administrators
-Backup Operators
-Users |
-
-
-
-
+| Server type or GPO | Default value |
+| - | - |
+| Default Domain Policy| Not Defined |
+| Default Domain Controller Policy | Account Operators
Administrators
Backup Operators
Print Operators
Server Operators |
+| Stand-Alone Server Default Settings| Administrators
Backup Operators
Users |
+| Domain Controller Effective Default Settings | Account Operators
Administrators
Backup Operators
Print Operators
Server Operators |
+| Member Server Effective Default Settings | Administrators
Backup Operators
Users |
+| Client Computer Effective Default Settings | Administrators
Backup Operators
Users |
-
## Policy management
-
Restarting the device is not required to implement this change.
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
Modifying this setting might affect compatibility with clients, services, and applications. Use caution when removing service accounts that are used by components and by programs on member devices and on domain controllers in the domain from the default domain controller's policy. Also use caution when removing users or security groups that log on to the console of member devices in the domain, or removing service accounts that are defined in the local Security Accounts Manager (SAM) database of member devices or of workgroup devices.
-
If you want to grant a user account the ability to log on locally to a domain controller, you must make that user a member of a group that already has the **Allowed logon locally** system right or grant the right to that user account.
-
The domain controllers in the domain share the Default Domain Controllers Group Policy Object (GPO). When you grant an account the **Allow logon locally** right, you are allowing that account to log on locally to all domain controllers in the domain.
-
If the Users group is listed in the **Allow log on locally** setting for a GPO, all domain users can log on locally. The Users built-in group contains Domain Users as a member.
### Group Policy
@@ -144,16 +80,12 @@ If the Users group is listed in the **Allow log on locally** setting for a GPO,
Group Policy settings are applied through GPOs in the following order, which will overwrite settings on the local computer at the next Group Policy update:
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
## Security considerations
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
@@ -163,7 +95,6 @@ Any account with the **Allow log on locally** user right can log on to the conso
### Countermeasure
For domain controllers, assign the **Allow log on locally** user right only to the Administrators group. For other server roles, you may choose to add Backup Operators in addition to Administrators. For end-user computers, you should also assign this right to the Users group.
-
Alternatively, you can assign groups such as Account Operators, Server Operators, and Guests to the **Deny log on locally** user right.
### Potential impact
@@ -171,15 +102,6 @@ Alternatively, you can assign groups such as Account Operators, Server Operators
If you remove these default groups, you could limit the abilities of users who are assigned to specific administrative roles in your environment. If you have installed optional components such as ASP.NET or IIS, you may need to assign the **Allow log on locally** user right to additional accounts that are required by those components. IIS requires that this user right be assigned to the IUSR\_*<ComputerName>* account. You should confirm that delegated activities are not adversely affected by any changes that you make to the **Allow log on locally** user rights assignments.
## Related topics
-
-
-[User Rights Assignment](user-rights-assignment.md)
-
+- [User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/allow-log-on-through-remote-desktop-services.md b/windows/keep-secure/allow-log-on-through-remote-desktop-services.md
index 81cc1e9800..cc51c9cbea 100644
--- a/windows/keep-secure/allow-log-on-through-remote-desktop-services.md
+++ b/windows/keep-secure/allow-log-on-through-remote-desktop-services.md
@@ -5,21 +5,19 @@ ms.assetid: 6267c376-8199-4f2b-ae56-9c5424e76798
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Allow log on through Remote Desktop Services
-
**Applies to**
-
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Allow log on through Remote Desktop Services** security policy setting.
## Reference
-
This policy setting determines which users or groups can access the logon screen of a remote device through a Remote Desktop Services connection. It is possible for a user to establish a Remote Desktop Services connection to a particular server but not be able to log on to the console of that same server.
Constant: SeRemoteInteractiveLogonRight
@@ -27,7 +25,6 @@ Constant: SeRemoteInteractiveLogonRight
### Possible values
- User-defined list of accounts
-
- Not Defined
### Best practices
@@ -41,56 +38,20 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Use
### Default values
By default, members of the Administrators group have this right on domain controllers, workstations, and servers. The Remote Desktops Users group also has this right on workstations and servers.
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
-
-
-
-
-
-
-
-
-
-Default Domain Policy |
-Not Defined |
-
-
-Default Domain Controller Policy |
-Administrators |
-
-
-Stand-Alone Server Default Settings |
-Administrators
-Remote Desktop Users |
-
-
-Domain Controller Effective Default Settings |
-Administrators |
-
-
-Member Server Effective Default Settings |
-Administrators
-Remote Desktop Users |
-
-
-Client Computer Effective Default Settings |
-Administrators
-Remote Desktop Users |
-
-
-
-
-
+| Server type or GPO | Default value |
+| - | - |
+| Default Domain Policy | Not Defined |
+| Default Domain Controller Policy | Administrators |
+| Stand-Alone Server Default Settings | Administrators
Remote Desktop Users |
+| Domain Controller Effective Default Settings | Administrators |
+| Member Server Effective Default Settings | Administrators
Remote Desktop Users |
+| Client Computer Effective Default Settings | Administrators
Remote Desktop Users |
+
## Policy management
-
This section describes different features and tools available to help you manage this policy.
### Group Policy
@@ -108,16 +69,12 @@ Any change to the user rights assignment for an account becomes effective the ne
Group Policy settings are applied through GPOs in the following order, which will overwrite settings on the local computer at the next Group Policy update:
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
## Security considerations
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
@@ -128,11 +85,8 @@ Any account with the **Allow log on through Remote Desktop Services** user right
For domain controllers, assign the **Allow log on through Remote Desktop Services** user right only to the Administrators group. For other server roles and devices, add the Remote Desktop Users group. For servers that have the Remote Desktop (RD) Session Host role service enabled and do not run in Application Server mode, ensure that only authorized IT personnel who must manage the computers remotely belong to these groups.
-**Caution**
-For RD Session Host servers that run in Application Server mode, ensure that only users who require access to the server have accounts that belong to the Remote Desktop Users group because this built-in group has this logon right by default.
-
+> **Caution:** For RD Session Host servers that run in Application Server mode, ensure that only users who require access to the server have accounts that belong to the Remote Desktop Users group because this built-in group has this logon right by default.
-
Alternatively, you can assign the **Deny log on through Remote Desktop Services** user right to groups such as Account Operators, Server Operators, and Guests. However, be careful when you use this method because you could block access to legitimate administrators who also belong to a group that has the **Deny log on through Remote Desktop Services** user right.
### Potential impact
@@ -141,14 +95,6 @@ Removal of the **Allow log on through Remote Desktop Services** user right from
## Related topics
-
-[User Rights Assignment](user-rights-assignment.md)
-
+- [User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/applocker-architecture-and-components.md b/windows/keep-secure/applocker-architecture-and-components.md
index 04cbfb9e54..39e8bbf34c 100644
--- a/windows/keep-secure/applocker-architecture-and-components.md
+++ b/windows/keep-secure/applocker-architecture-and-components.md
@@ -5,14 +5,13 @@ ms.assetid: efdd8494-553c-443f-bd5f-c8976535135a
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# AppLocker architecture and components
-
**Applies to**
-
- Windows 10
This topic for IT professional describes AppLocker’s basic architecture and its major components.
@@ -35,14 +34,6 @@ Before a script file is run, the script host (for example. for .ps1 files the sc
## Related topics
-
-[AppLocker technical reference](applocker-technical-reference.md)
-
+- [AppLocker technical reference](applocker-technical-reference.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/applocker-functions.md b/windows/keep-secure/applocker-functions.md
index 70f5f69402..d3ab5362dd 100644
--- a/windows/keep-secure/applocker-functions.md
+++ b/windows/keep-secure/applocker-functions.md
@@ -5,100 +5,46 @@ ms.assetid: bf704198-9e74-4731-8c5a-ee0512df34d2
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# AppLocker functions
-
**Applies to**
-
- Windows 10
This topic for the IT professional lists the functions and security levels for the Software Restriction Policies (SRP) and AppLocker features.
## Functions
-
The following list includes the SRP functions beginning with Windows Server 2003 and AppLocker functions beginning with Windows Server 2008 R2 and links to current documentation on MSDN:
- [SaferGetPolicyInformation Function](http://go.microsoft.com/fwlink/p/?LinkId=159781)
-
- [SaferCreateLevel Function](http://go.microsoft.com/fwlink/p/?LinkId=159782)
-
- [SaferCloseLevel Function](http://go.microsoft.com/fwlink/p/?LinkId=159783)
-
- [SaferIdentifyLevel Function](http://go.microsoft.com/fwlink/p/?LinkId=159784)
-
- [SaferComputeTokenFromLevel Function](http://go.microsoft.com/fwlink/p/?LinkId=159785)
-
- [SaferGetLevelInformation Function](http://go.microsoft.com/fwlink/p/?LinkId=159787)
-
- [SaferRecordEventLogEntry Function](http://go.microsoft.com/fwlink/p/?LinkId=159789)
-
- [SaferiIsExecutableFileType Function](http://go.microsoft.com/fwlink/p/?LinkId=159790)
## Security level ID
-
AppLocker and SRP use the security level IDs to stipulate the access requirements to files listed in policies. The following table shows those security levels supported in SRP and AppLocker.
-
-
-
-
-
-
-
-
-
-
-
-SAFER_LEVELID_FULLYTRUSTED |
-Supported |
-Supported |
-
-
-SAFER_LEVELID_NORMALUSER |
-Supported |
-Not supported |
-
-
-SAFER_LEVELID_CONSTRAINED |
-Supported |
-Not supported |
-
-
-SAFER_LEVELID_UNTRUSTED |
-Supported |
-Not supported |
-
-
-SAFER_LEVELID_DISALLOWED |
-Supported |
-Supported |
-
-
-
-
+| Security level ID | SRP | AppLocker |
+| - | - | - |
+| SAFER_LEVELID_FULLYTRUSTED | Supported | Supported |
+| SAFER_LEVELID_NORMALUSER | Supported | Not supported |
+| SAFER_LEVELID_CONSTRAINED | Supported | Not supported |
+| SAFER_LEVELID_UNTRUSTED | Supported | Not supported |
+| SAFER_LEVELID_DISALLOWED | Supported | Supported |
-
In addition, URL zone ID is not supported in AppLocker.
## Related topics
-
-[AppLocker technical reference](applocker-technical-reference.md)
-
+- [AppLocker technical reference](applocker-technical-reference.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/applocker-overview.md b/windows/keep-secure/applocker-overview.md
index 1e78269e28..6918af6f1e 100644
--- a/windows/keep-secure/applocker-overview.md
+++ b/windows/keep-secure/applocker-overview.md
@@ -5,14 +5,13 @@ ms.assetid: 94b57864-2112-43b6-96fb-2863c985dc9a
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# AppLocker
-
**Applies to**
-
- Windows 10
This topic provides a description of AppLocker and can help you decide if your organization can benefit from deploying AppLocker application control policies. AppLocker helps you control which apps and files users can run. These include executable files, scripts, Windows Installer files, dynamic-link libraries (DLLs), packaged apps, and packaged app installers.
@@ -20,15 +19,10 @@ This topic provides a description of AppLocker and can help you decide if your o
AppLocker can help you:
- Define rules based on file attributes that persist across app updates, such as the publisher name (derived from the digital signature), product name, file name, and file version. You can also create rules based on the file path and hash.
-
- Assign a rule to a security group or an individual user.
-
- Create exceptions to rules. For example, you can create a rule that allows all users to run all Windows binaries, except the Registry Editor (regedit.exe).
-
- Use audit-only mode to deploy the policy and understand its impact before enforcing it.
-
- Create rules on a staging server, test them, then export them to your production environment and import them into a Group Policy Object.
-
- Simplify creating and managing AppLocker rules by using Windows PowerShell.
AppLocker helps reduce administrative overhead and helps reduce the organization's cost of managing computing resources by decreasing the number of Help Desk calls that result from users running unapproved apps. AppLocker addresses the following app security scenarios:
@@ -55,16 +49,13 @@ AppLocker helps reduce administrative overhead and helps reduce the organization
## New and changed functionality
-
To find out what's new in AppLocker for Windows 10, see [What's new in AppLocker?](../whats-new/applocker.md)
## When to use AppLocker
-
In many organizations, information is the most valuable asset, and ensuring that only approved users have access to that information is imperative. Access control technologies, such as Active Directory Rights Management Services (AD RMS) and access control lists (ACLs), help control what users are allowed to access.
However, when a user runs a process, that process has the same level of access to data that the user has. As a result, sensitive information could easily be deleted or transmitted out of the organization if a user knowingly or unknowingly runs malicious software. AppLocker can help mitigate these types of security breaches by restricting the files that users or groups are allowed to run.
-
Software publishers are beginning to create more apps that can be installed by non-administrative users. This could jeopardize an organization's written security policy and circumvent traditional app control solutions that rely on the inability of users to install apps. By creating an allowed list of approved files and apps, AppLocker helps prevent such per-user apps from running. Because AppLocker can control DLLs, it is also useful to control who can install and run ActiveX controls.
AppLocker is ideal for organizations that currently use Group Policy to manage their PCs.
@@ -72,42 +63,29 @@ AppLocker is ideal for organizations that currently use Group Policy to manage t
The following are examples of scenarios in which AppLocker can be used:
- Your organization's security policy dictates the use of only licensed software, so you need to prevent users from running unlicensed software and also restrict the use of licensed software to authorized users.
-
- An app is no longer supported by your organization, so you need to prevent it from being used by everyone.
-
- The potential that unwanted software can be introduced in your environment is high, so you need to reduce this threat.
-
- The license to an app has been revoked or it is expired in your organization, so you need to prevent it from being used by everyone.
-
- A new app or a new version of an app is deployed, and you need to prevent users from running the old version.
-
- Specific software tools are not allowed within the organization, or only specific users should have access to those tools.
-
- A single user or small group of users needs to use a specific app that is denied for all others.
-
- Some computers in your organization are shared by people who have different software usage needs, and you need to protect specific apps.
-
- In addition to other measures, you need to control the access to sensitive data through app usage.
AppLocker can help you protect the digital assets within your organization, reduce the threat of malicious software being introduced into your environment, and improve the management of application control and the maintenance of application control policies.
## System requirements
-
AppLocker policies can only be configured on and applied to computers that are running on the supported versions and editions of the Windows operating system. Group Policy is required to distribute Group Policy Objects that contain AppLocker policies. For more info, see [Requirements to Use AppLocker](requirements-to-use-applocker.md).
AppLocker rules can be created on domain controllers.
## Installing AppLocker
-
AppLocker is included with enterprise-level editions of Windows. You can author AppLocker rules for a single computer or for a group of computers. For a single computer, you can author the rules by using the Local Security Policy editor (secpol.msc). For a group of computers, you can author the rules within a Group Policy Object by using the Group Policy Management Console (GPMC).
-**Note**
-The GPMC is available in client computers running Windows only by installing the Remote Server Administration Tools. On computer running Windows Server, you must install the Group Policy Management feature.
-
+> **Note:** The GPMC is available in client computers running Windows only by installing the Remote Server Administration Tools. On computer running Windows Server, you must install the Group Policy Management feature.
-
### Using AppLocker on Server Core
AppLocker on Server Core installations is not supported.
@@ -131,111 +109,29 @@ For additional information about specific security issues, see [Security conside
When you use AppLocker to create application control policies, you should be aware of the following security considerations:
- Who has the rights to set AppLocker policies?
-
- How do you validate that the policies are enforced?
-
- What events should you audit?
For reference in your security planning, the following table identifies the baseline settings for a PC with AppLocker installed:
-
-
-
-
-
-
-
-
-
-
-Accounts created |
-None |
-
-
-Authentication method |
-Not applicable |
-
-
-Management interfaces |
-AppLocker can be managed by using a Microsoft Management Console snap-in, Group Policy Management, and Windows PowerShell |
-
-
-Ports opened |
-None |
-
-
-Minimum privileges required |
-Administrator on the local computer; Domain Admin, or any set of rights that allow you to create, edit and distribute Group Policy Objects. |
-
-
-Protocols used |
-Not applicable |
-
-
-Scheduled Tasks |
-Appidpolicyconverter.exe is put in a scheduled task to be run on demand. |
-
-
-Security Policies |
-None required. AppLocker creates security policies. |
-
-
-System Services required |
-Application Identity service (appidsvc) runs under LocalServiceAndNoImpersonation. |
-
-
-Storage of credentials |
-None |
-
-
-
-
+| Setting | Default value |
+| - | - |
+| Accounts created | None |
+| Authentication method | Not applicable |
+| Management interfaces | AppLocker can be managed by using a Microsoft Management Console snap-in, Group Policy Management, and Windows PowerShell |
+| Ports opened | None |
+| Minimum privileges required | Administrator on the local computer; Domain Admin, or any set of rights that allow you to create, edit and distribute Group Policy Objects. |
+| Protocols used | Not applicable |
+| Scheduled Tasks | Appidpolicyconverter.exe is put in a scheduled task to be run on demand. |
+| Security Policies | None required. AppLocker creates security policies. |
+| System Services required |Application Identity service (appidsvc) runs under LocalServiceAndNoImpersonation. |
+| Storage of credentials | None |
-
## In this section
-
-
-
-
-
-
-
-
-
-
-
-[Administer AppLocker](administer-applocker.md) |
-This topic for IT professionals provides links to specific procedures to use when administering AppLocker policies. |
-
-
-[AppLocker design guide](applocker-policies-design-guide.md) |
-This topic for the IT professional introduces the design and planning steps required to deploy application control policies by using AppLocker. |
-
-
-[AppLocker deployment guide](applocker-policies-deployment-guide.md) |
-This topic for IT professionals introduces the concepts and describes the steps required to deploy AppLocker policies. |
-
-
-[AppLocker technical reference](applocker-technical-reference.md) |
-This overview topic for IT professionals provides links to the topics in the technical reference. |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+| Topic | Description |
+| - | - |
+| [Administer AppLocker](administer-applocker.md) | This topic for IT professionals provides links to specific procedures to use when administering AppLocker policies. |
+| [AppLocker design guide](applocker-policies-design-guide.md) | This topic for the IT professional introduces the design and planning steps required to deploy application control policies by using AppLocker. |
+| [AppLocker deployment guide](applocker-policies-deployment-guide.md) | This topic for IT professionals introduces the concepts and describes the steps required to deploy AppLocker policies. |
+| [AppLocker technical reference](applocker-technical-reference.md) | This overview topic for IT professionals provides links to the topics in the technical reference. |
diff --git a/windows/keep-secure/applocker-policies-deployment-guide.md b/windows/keep-secure/applocker-policies-deployment-guide.md
index 4f51483547..f0bce74c2a 100644
--- a/windows/keep-secure/applocker-policies-deployment-guide.md
+++ b/windows/keep-secure/applocker-policies-deployment-guide.md
@@ -5,14 +5,14 @@ ms.assetid: 38632795-be13-46b0-a7af-487a4340bea1
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
+
# AppLocker deployment guide
-
**Applies to**
-
- Windows 10
This topic for IT professionals introduces the concepts and describes the steps required to deploy AppLocker policies.
@@ -23,81 +23,31 @@ This guide covers the use of Software Restriction Policies (SRP) in conjunction
## Prerequisites to deploying AppLocker policies
-
The following are prerequisites or recommendations to deploying policies:
- Understand the capabilities of AppLocker:
-
- [AppLocker](applocker-overview.md)
-
- Document your application control policy deployment plan by addressing these tasks:
-
- [Understand the AppLocker policy deployment process](understand-the-applocker-policy-deployment-process.md)
-
- [Understand AppLocker policy design decisions](understand-applocker-policy-design-decisions.md)
-
- [Determine your application control objectives](determine-your-application-control-objectives.md)
-
- [Create list of apps deployed to each business group](create-list-of-applications-deployed-to-each-business-group.md)
-
- [Select types of rules to create](select-types-of-rules-to-create.md)
-
- [Determine Group Policy Structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md)
-
- [Plan for AppLocker policy management](plan-for-applocker-policy-management.md)
-
- [Create your AppLocker planning document](create-your-applocker-planning-document.md)
## Contents of this guide
-
This guide provides steps based on your design and planning investigation for deploying application control policies created and maintained by AppLocker for computers running any of the supported versions of Windows listed in [Requirements to use AppLocker](requirements-to-use-applocker.md).
## In this section
-
-
-
-
-
-
-
-
-
-
-
-[Understand the AppLocker policy deployment process](understand-the-applocker-policy-deployment-process.md) |
-This planning and deployment topic for the IT professional describes the process for using AppLocker when deploying application control policies. |
-
-
-[Requirements for Deploying AppLocker Policies](requirements-for-deploying-applocker-policies.md) |
-This deployment topic for the IT professional lists the requirements that you need to consider before you deploy AppLocker policies. |
-
-
-[Use Software Restriction Policies and AppLocker policies](using-software-restriction-policies-and-applocker-policies.md) |
-This topic for the IT professional describes how to use Software Restriction Policies (SRP) and AppLocker policies in the same Windows deployment. |
-
-
-[Create Your AppLocker policies](create-your-applocker-policies.md) |
-This overview topic for the IT professional describes the steps to create an AppLocker policy and prepare it for deployment. |
-
-
-[Deploy the AppLocker policy into production](deploy-the-applocker-policy-into-production.md) |
-This topic for the IT professional describes the tasks that should be completed before you deploy AppLocker application control settings. |
-
-
-
-
-
-
-
-
-
-
-
-
-
+| Topic | Description |
+| - | - |
+| [Understand the AppLocker policy deployment process](understand-the-applocker-policy-deployment-process.md) | This planning and deployment topic for the IT professional describes the process for using AppLocker when deploying application control policies. |
+| [Requirements for Deploying AppLocker Policies](requirements-for-deploying-applocker-policies.md) | This deployment topic for the IT professional lists the requirements that you need to consider before you deploy AppLocker policies. |
+| [Use Software Restriction Policies and AppLocker policies](using-software-restriction-policies-and-applocker-policies.md) | This topic for the IT professional describes how to use Software Restriction Policies (SRP) and AppLocker policies in the same Windows deployment. |
+| [Create Your AppLocker policies](create-your-applocker-policies.md) | This overview topic for the IT professional describes the steps to create an AppLocker policy and prepare it for deployment. |
+| [Deploy the AppLocker policy into production](deploy-the-applocker-policy-into-production.md) | This topic for the IT professional describes the tasks that should be completed before you deploy AppLocker application control settings. |
diff --git a/windows/keep-secure/applocker-policies-design-guide.md b/windows/keep-secure/applocker-policies-design-guide.md
index 13f4d2f528..7954db3edb 100644
--- a/windows/keep-secure/applocker-policies-design-guide.md
+++ b/windows/keep-secure/applocker-policies-design-guide.md
@@ -5,14 +5,13 @@ ms.assetid: 1c8e4a7b-3164-4eb4-9277-11b1d5a09c7b
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# AppLocker design guide
-
**Applies to**
-
- Windows 10
This topic for the IT professional introduces the design and planning steps required to deploy application control policies by using AppLocker.
@@ -22,62 +21,17 @@ This guide provides important designing and planning information for deploying a
This guide does not cover the deployment of application control policies by using Software Restriction Policies (SRP). However, SRP is discussed as a deployment option in conjunction with AppLocker policies. For info about these options, see [Determine your application control objectives](determine-your-application-control-objectives.md).
To understand if AppLocker is the correct application control solution for your organization, see [Understand AppLocker policy design decisions](understand-applocker-policy-design-decisions.md).
-
## In this section
-
-
-
-
-
-
-
-
-
-
-
-[Understand AppLocker policy design decisions](understand-applocker-policy-design-decisions.md) |
-This topic for the IT professional lists the design questions, possible answers, and ramifications of the decisions when you plan a deployment of application control policies by using AppLocker within a Windows operating system environment. |
-
-
-[Determine your application control objectives](determine-your-application-control-objectives.md) |
-This topic helps you with the decisions you need to make to determine what applications to control and how to control them by comparing Software Restriction Policies (SRP) and AppLocker. |
-
-
-[Create a list of apps deployed to each business group](create-list-of-applications-deployed-to-each-business-group.md) |
-This topic describes the process of gathering app usage requirements from each business group in order to implement application control policies by using AppLocker. |
-
-
-[Select the types of rules to create](select-types-of-rules-to-create.md) |
-This topic lists resources you can use when selecting your application control policy rules by using AppLocker. |
-
-
-[Determine the Group Policy structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md) |
-This overview topic describes the process to follow when you are planning to deploy AppLocker rules. |
-
-
-[Plan for AppLocker policy management](plan-for-applocker-policy-management.md) |
-This topic for describes the decisions you need to make to establish the processes for managing and maintaining AppLocker policies. |
-
-
-[Create your AppLocker planning document](create-your-applocker-planning-document.md) |
-This planning topic for the IT professional summarizes the information you need to research and include in your AppLocker planning document. |
-
-
-
-
+| Topic | Description |
+| - | - |
+| [Understand AppLocker policy design decisions](understand-applocker-policy-design-decisions.md) | This topic for the IT professional lists the design questions, possible answers, and ramifications of the decisions when you plan a deployment of application control policies by using AppLocker within a Windows operating system environment. |
+| [Determine your application control objectives](determine-your-application-control-objectives.md) | This topic helps you with the decisions you need to make to determine what applications to control and how to control them by comparing Software Restriction Policies (SRP) and AppLocker. |
+| [Create a list of apps deployed to each business group](create-list-of-applications-deployed-to-each-business-group.md) | This topic describes the process of gathering app usage requirements from each business group in order to implement application control policies by using AppLocker. |
+| [Select the types of rules to create](select-types-of-rules-to-create.md) | This topic lists resources you can use when selecting your application control policy rules by using AppLocker. |
+| [Determine the Group Policy structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md) | This overview topic describes the process to follow when you are planning to deploy AppLocker rules. |
+| [Plan for AppLocker policy management](plan-for-applocker-policy-management.md) | This topic for describes the decisions you need to make to establish the processes for managing and maintaining AppLocker policies. |
+| [Create your AppLocker planning document](create-your-applocker-planning-document.md) | This planning topic for the IT professional summarizes the information you need to research and include in your AppLocker planning document. |
-
After careful design and detailed planning, the next step is to deploy AppLocker policies. [AppLocker Deployment Guide](applocker-policies-deployment-guide.md) covers the creation and testing of policies, deploying the enforcement setting, and managing and maintaining the policies.
-
-
-
-
-
-
-
-
-
+
\ No newline at end of file
diff --git a/windows/keep-secure/applocker-policy-use-scenarios.md b/windows/keep-secure/applocker-policy-use-scenarios.md
index 6420217c2e..ce30809f52 100644
--- a/windows/keep-secure/applocker-policy-use-scenarios.md
+++ b/windows/keep-secure/applocker-policy-use-scenarios.md
@@ -5,14 +5,13 @@ ms.assetid: 33f71578-89f0-4063-ac04-cf4f4ca5c31f
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# AppLocker policy use scenarios
-
**Applies to**
-
- Windows 10
This topic for the IT professional lists the various application control scenarios in which AppLocker policies can be effectively implemented.
@@ -37,46 +36,27 @@ AppLocker can help you improve the management of application control and the mai
5. **Manageability improvement**
- AppLocker policies can be modified and deployed through your existing Group Policy infrastructure and can work in conjunction with policies created by using Software Restriction Policies. As you manage ongoing change in your support of a business group's apps, you can modify policies and use the AppLocker cmdlets to test the policies for the expected results. You can also design application control policies for situations in which users share computers.
+ AppLocker policies can be modified and deployed through your existing Group Policy infrastructure and can work in conjunction with policies created by using Software Restriction Policies. As you manage ongoing change in your support of a business group's apps, you can modify policies and use
+ the AppLocker cmdlets to test the policies for the expected results. You can also design application control policies for situations in which users share computers.
### Use scenarios
The following are examples of scenarios in which AppLocker can be used:
- Your organization implements a policy to standardize the applications used within each business group, so you need to determine the expected usage compared to the actual usage.
-
- The security policy for application usage has changed, and you need to evaluate where and when those deployed apps are being accessed.
-
- Your organization's security policy dictates the use of only licensed software, so you need to determine which apps are not licensed or prevent unauthorized users from running licensed software.
-
- An app is no longer supported by your organization, so you need to prevent it from being used by everyone.
-
- Your organization needs to restrict the use of Universal Windows apps to just those your organization approves of or develops.
-
- The potential that unwanted software can be introduced in your environment is high, so you need to reduce this threat.
-
- The license to an app has been revoked or is expired in your organization, so you need to prevent it from being used by everyone.
-
- A new app or a new version of an app is deployed, and you need to allow certain groups to use it.
-
- Specific software tools are not allowed within the organization, or only specific users have access to those tools.
-
- A single user or small group of users needs to use a specific app that is denied for all others.
-
- Some computers in your organization are shared by people who have different software usage needs.
-
- In addition to other measures, you need to control the access to sensitive data through app usage.
## Related topics
-
-
-[AppLocker technical reference](applocker-technical-reference.md)
-
+- [AppLocker technical reference](applocker-technical-reference.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/applocker-processes-and-interactions.md b/windows/keep-secure/applocker-processes-and-interactions.md
index 65ed48a32a..0243055da8 100644
--- a/windows/keep-secure/applocker-processes-and-interactions.md
+++ b/windows/keep-secure/applocker-processes-and-interactions.md
@@ -5,21 +5,19 @@ ms.assetid: 0beec616-6040-4be7-8703-b6c919755d8e
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# AppLocker processes and interactions
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the process dependencies and interactions when AppLocker evaluates and enforces rules.
## How policies are implemented by AppLocker
-
AppLocker policies are collections of AppLocker rules that might contain any one of the enforcement settings configured. When applied, each rule is evaluated within the policy and the collection of rules is applied according to the enforcement setting and according to your Group Policy structure.
The AppLocker policy is enforced on a computer through the Application Identity service, which is the engine that evaluates the policies. If the service is not running, policies will not be enforced. The Application Identity service returns the information from the binary—even if product or binary names are empty—to the results pane of the Local Security Policy snap-in.
@@ -27,9 +25,7 @@ The AppLocker policy is enforced on a computer through the Application Identity
AppLocker policies are stored in a security descriptor format according to Application Identity service requirements. It uses file path, hash, or fully qualified binary name attributes to form allow or deny actions on a rule. Each rule is stored as an access control entry (ACE) in the security descriptor and contains the following information:
- Either an allow or a deny ACE ("XA" or "XD" in security descriptor definition language (SDDL) form).
-
- The user security identifier (SID) that this rule is applicable to. (The default is the authenticated user SID, or "AU" in SDDL.)
-
- The rule condition containing the **appid** attributes.
For example, an SDDL for a rule that allows all files in the %windir% directory to run uses the following format: XA;;FX;;;AU;(APPID://PATH == "%windir%\\\*").
@@ -41,25 +37,17 @@ An AppLocker policy for DLLs and executable files is read and cached by kernel m
An AppLocker rule is a control placed on a file to govern whether or not it is allowed to run for a specific user or group. Rules apply to five different types, or collections, of files:
- An executable rule controls whether a user or group can run an executable file. Executable files most often have the .exe or .com file name extensions and apply to applications.
-
- A script rule controls whether a user or group can run scripts with a file name extension of .ps1, .bat, .cmd, .vbs, and .js.
-
- A Windows Installer rule controls whether a user or group can run files with a file name extension of .msi, mst and .msp (Windows Installer patch).
-
- A DLL rule controls whether a user or group can run files with a file name extension of .dll and .ocx.
-
- A packaged app and packaged app installer rule controls whether a user or group can run or install a packaged app. A Packaged app installer has the .appx extension.
There are three different types of conditions that can be applied to rules:
- A publisher condition on a rule controls whether a user or group can run files from a specific software publisher. The file must be signed.
-
- A path condition on a rule controls whether a user or group can run files from within a specific directory or its subdirectories.
-
- A file hash condition on a rule controls whether a user or group can run files with matching encrypted hashes.
-
-
- [Understanding AppLocker rule collections](understanding-applocker-rule-collections.md)
An AppLocker rule collection is a set of rules that apply to one of the following types: executable files, Windows Installer files, scripts, DLLs, and packaged apps.
@@ -69,25 +57,17 @@ There are three different types of conditions that can be applied to rules:
Rule conditions are criteria that the AppLocker rule is based on. Primary conditions are required to create an AppLocker rule. The three primary rule conditions are publisher, path, and file hash.
- [Understanding the publisher rule condition in AppLocker](understanding-the-publisher-rule-condition-in-applocker.md)
-
- [Understanding the path rule condition in AppLocker](understanding-the-path-rule-condition-in-applocker.md)
-
- [Understanding the file hash rule condition in AppLocker](understanding-the-file-hash-rule-condition-in-applocker.md)
-
- [Understanding AppLocker default rules](understanding-applocker-default-rules.md)
AppLocker includes default rules for each rule collection. These rules are intended to help ensure that the files that are required for Windows to operate properly are allowed in an AppLocker rule collection.
- [Executable rules in AppLocker](executable-rules-in-applocker.md)
-
- [Windows Installer rules in AppLocker](windows-installer-rules-in-applocker.md)
-
- [Script rules in AppLocker](script-rules-in-applocker.md)
-
- [DLL rules in AppLocker](dll-rules-in-applocker.md)
-
- [Packaged apps and packaged app installer rules in AppLocker](packaged-apps-and-packaged-app-installer-rules-in-applocker.md)
-
- [Understanding AppLocker rule exceptions](understanding-applocker-rule-exceptions.md)
You can apply AppLocker rules to individual users or a group of users. If you apply a rule to a group of users, all users in that group are affected by that rule. If you need to allow only a subset of a user group to use an application, you can create a special rule for that subset.
@@ -110,18 +90,9 @@ Group Policy can be used to create, modify, and distribute AppLocker policies in
- [Understand AppLocker rules and enforcement setting inheritance in Group Policy](understand-applocker-rules-and-enforcement-setting-inheritance-in-group-policy.md)
- When Group Policy is used to distribute AppLocker policies, rule collections that are not configured will be enforced. Group Policy does not overwrite or replace rules that are already present in a linked Group Policy Object (GPO) and applies the AppLocker rules in addition to existing rules. AppLocker processes the explicit deny rule configuration before the allow rule configuration, and for rule enforcement, the last write to the GPO is applied.
+ When Group Policy is used to distribute AppLocker policies, rule collections that are not configured will be enforced. Group Policy does not overwrite or replace rules that are already present in a linked Group Policy Object (GPO) and applies the AppLocker rules in addition to existing rules.
+ AppLocker processes the explicit deny rule configuration before the allow rule configuration, and for rule enforcement, the last write to the GPO is applied.
## Related topics
-
-[AppLocker technical reference](applocker-technical-reference.md)
-
-
-
-
-
-
-
-
-
+- [AppLocker technical reference](applocker-technical-reference.md)
diff --git a/windows/keep-secure/applocker-settings.md b/windows/keep-secure/applocker-settings.md
index 03daf2f9c0..77509f8e43 100644
--- a/windows/keep-secure/applocker-settings.md
+++ b/windows/keep-secure/applocker-settings.md
@@ -5,75 +5,29 @@ ms.assetid: 9cb4aa19-77c0-4415-9968-bd07dab86839
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# AppLocker settings
-
**Applies to**
-
- Windows 10
This topic for the IT professional lists the settings used by AppLocker.
The following table describes the settings and values used by AppLocker.
-
-
-
-
-
-
-
-
-
-
-Registry path |
-Policies are stored in \HKEY_LOCAL_Machine\Software\Policies\Microsoft\Windows\SrpV2 |
-
-
-Firewall ports |
-Not applicable |
-
-
-Security policies |
-Custom created, no default |
-
-
-Group Policy settings |
-Custom created, no default |
-
-
-Network ports |
-Not applicable |
-
-
-Service accounts |
-Not applicable |
-
-
-Performance counters |
-Not applicable |
-
-
-
-
+| Setting | Value |
+| - | - |
+| Registry path | Policies are stored in **HKEY_LOCAL_Machine\Software\Policies\Microsoft\Windows\SrpV2** |
+| Firewall ports | Not applicable |
+| Security policies | Custom created, no default |
+| Group Policy settings | Custom created, no default |
+| Network ports | Not applicable |
+| Service accounts | Not applicable |
+| Performance counters | Not applicable |
-
## Related topics
-
-[AppLocker technical reference](applocker-technical-reference.md)
-
-
-
-
-
-
-
-
-
+- [AppLocker technical reference](applocker-technical-reference.md)
diff --git a/windows/keep-secure/applocker-technical-reference.md b/windows/keep-secure/applocker-technical-reference.md
index 417a1e29d0..164a159782 100644
--- a/windows/keep-secure/applocker-technical-reference.md
+++ b/windows/keep-secure/applocker-technical-reference.md
@@ -5,85 +5,29 @@ ms.assetid: 2b2678f8-c46b-4e1d-b8c5-037c0be255ab
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# AppLocker technical reference
-
**Applies to**
-
- Windows 10
This overview topic for IT professionals provides links to the topics in the technical reference.
-
AppLocker advances the application control features and functionality of Software Restriction Policies. AppLocker contains new capabilities and extensions that allow you to create rules to allow or deny apps from running based on unique identities of files and to specify which users or groups can run those apps.
## In this section
-
-
-
-
-
-
-
-
-
-
-
-[What Is AppLocker?](what-is-applocker.md) |
-This topic for the IT professional describes what AppLocker is and how its features differ from Software Restriction Policies. |
-
-
-[Requirements to use AppLocker](requirements-to-use-applocker.md) |
-This topic for the IT professional lists software requirements to use AppLocker on the supported Windows operating systems. |
-
-
-[AppLocker policy use scenarios](applocker-policy-use-scenarios.md) |
-This topic for the IT professional lists the various application control scenarios in which AppLocker policies can be effectively implemented. |
-
-
-[How AppLocker works](how-applocker-works-techref.md) |
-This topic for the IT professional provides links to topics about AppLocker architecture and components, processes and interactions, rules and policies. |
-
-
-[AppLocker architecture and components](applocker-architecture-and-components.md) |
-This topic for IT professional describes AppLocker’s basic architecture and its major components. |
-
-
-[AppLocker processes and interactions](applocker-processes-and-interactions.md) |
-This topic for the IT professional describes the process dependencies and interactions when AppLocker evaluates and enforces rules. |
-
-
-[AppLocker functions](applocker-functions.md) |
-This topic for the IT professional lists the functions and security levels for the Software Restriction Policies (SRP) and AppLocker features. |
-
-
-[Security considerations for AppLocker](security-considerations-for-applocker.md) |
-This topic for the IT professional describes the security considerations you need to address when implementing AppLocker. |
-
-
-[Tools to Use with AppLocker](tools-to-use-with-applocker.md) |
-This topic for the IT professional describes the tools available to create and administer AppLocker policies. |
-
-
-[AppLocker Settings](applocker-settings.md) |
-This topic for the IT professional lists the settings used by AppLocker. |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+| Topic | Description |
+| - | - |
+| [What Is AppLocker?](what-is-applocker.md) | This topic for the IT professional describes what AppLocker is and how its features differ from Software Restriction Policies. |
+| [Requirements to use AppLocker](requirements-to-use-applocker.md) | This topic for the IT professional lists software requirements to use AppLocker on the supported Windows operating systems. |
+| [AppLocker policy use scenarios](applocker-policy-use-scenarios.md) | This topic for the IT professional lists the various application control scenarios in which AppLocker policies can be effectively implemented. |
+| [How AppLocker works](how-applocker-works-techref.md) | This topic for the IT professional provides links to topics about AppLocker architecture and components, processes and interactions, rules and policies. |
+| [AppLocker architecture and components](applocker-architecture-and-components.md) | This topic for IT professional describes AppLocker’s basic architecture and its major components. |
+| [AppLocker processes and interactions](applocker-processes-and-interactions.md) | This topic for the IT professional describes the process dependencies and interactions when AppLocker evaluates and enforces rules. |
+| [AppLocker functions](applocker-functions.md) | This topic for the IT professional lists the functions and security levels for the Software Restriction Policies (SRP) and AppLocker features. |
+| [Security considerations for AppLocker](security-considerations-for-applocker.md) | This topic for the IT professional describes the security considerations you need to address when implementing AppLocker. |
+| [Tools to Use with AppLocker](tools-to-use-with-applocker.md) | This topic for the IT professional describes the tools available to create and administer AppLocker policies. |
+| [AppLocker Settings](applocker-settings.md) | This topic for the IT professional lists the settings used by AppLocker. |
diff --git a/windows/keep-secure/apply-a-basic-audit-policy-on-a-file-or-folder.md b/windows/keep-secure/apply-a-basic-audit-policy-on-a-file-or-folder.md
index 23a70a9f8c..5828778660 100644
--- a/windows/keep-secure/apply-a-basic-audit-policy-on-a-file-or-folder.md
+++ b/windows/keep-secure/apply-a-basic-audit-policy-on-a-file-or-folder.md
@@ -5,51 +5,38 @@ ms.assetid: 565E7249-5CD0-4B2E-B2C0-B3A0793A51E2
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Apply a basic audit policy on a file or folder
-
**Applies to**
-
- Windows 10
You can apply audit policies to individual files and folders on your computer by setting the permission type to record successful access attempts or failed access attempts in the security log.
-
To complete this procedure, you must be logged on as a member of the built-in Administrators group or you must have been granted the **Manage auditing and security log** right.
**To apply or modify auditing policy settings for a local file or folder**
-1. 2.Right-click the file or folder that you want to audit, click **Properties**, and then click the **Security** tab.
+1. Right-click the file or folder that you want to audit, click **Properties**, and then click the **Security** tab.
2. Click **Advanced**.
3. In the **Advanced Security Settings** dialog box, click the **Auditing** tab, and then click **Continue**.
4. Do one of the following:
- To set up auditing for a new user or group, click **Add**. Click **Select a principal**, type the name of the user or group that you want, and then click **OK**.
- To remove auditing for an existing group or user, click the group or user name, click **Remove**, click **OK**, and then skip the rest of this procedure.
- To view or change auditing for an existing group or user, click its name, and then click **Edit.**
-
5. In the **Type** box, indicate what actions you want to audit by selecting the appropriate check boxes:
- To audit successful events, click **Success.**
- To audit failure events, click **Fail.**
- To audit all events, click **All.**
-**Important** Before setting up auditing for files and folders, you must enable object access auditing by defining auditing policy settings for the object access event category. If you do not enable object access auditing, you will receive an error message when you set up auditing for files and folders, and no files or folders will be audited.
-
+> **Important:** Before setting up auditing for files and folders, you must enable object access auditing by defining auditing policy settings for the object access event category. If you do not enable object access auditing, you will receive an error message when you set up auditing for files and folders, and no files or folders will be audited.
-
## Additional considerations
-
- After object access auditing is enabled, view the security log in Event Viewer to review the results of your changes.
- You can set up file and folder auditing only on NTFS drives.
- Because the security log is limited in size, select the files and folders to be audited carefully. Also, consider the amount of disk space that you want to devote to the security log. The maximum size for the security log is defined in Event Viewer.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-account-lockout.md b/windows/keep-secure/audit-account-lockout.md
index 0731e562be..6c7ebbb0e2 100644
--- a/windows/keep-secure/audit-account-lockout.md
+++ b/windows/keep-secure/audit-account-lockout.md
@@ -5,14 +5,13 @@ ms.assetid: da68624b-a174-482c-9bc5-ddddab38e589
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Account Lockout
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
@@ -26,37 +25,12 @@ Event volume: Low
Default setting: Success
-
-
-
-
-
-
-
-
-
-
-4625 |
-An account failed to log on. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4625 | An account failed to log on. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-application-generated.md b/windows/keep-secure/audit-application-generated.md
index 5fac3e3ba7..f7c31ca13a 100644
--- a/windows/keep-secure/audit-application-generated.md
+++ b/windows/keep-secure/audit-application-generated.md
@@ -5,14 +5,13 @@ ms.assetid: 6c58a365-b25b-42b8-98ab-819002e31871
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Application Generated
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the Advanced Security Audit policy setting, **Audit Application Generated**, which determines whether the operating system generates audit events when applications attempt to use the Windows Auditing application programming interfaces (APIs).
@@ -20,7 +19,6 @@ This topic for the IT professional describes the Advanced Security Audit policy
The following events can generate audit activity:
- Creation, deletion, or initialization of an application client context
-
- Application operations
Applications that are designed to use the Windows Auditing APIs can use this subcategory to log auditing events that are related to those APIs. The level, volume, relevance, and importance of these audit events depend on the application that generates them. The operating system logs the events as they are generated by the application.
@@ -29,49 +27,14 @@ Event volume: Depends on the installed app's use of the Windows Auditing APIs
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4665 |
-An attempt was made to create an application client context. |
-
-
-4666 |
-An application attempted an operation: |
-
-
-4667 |
-An application client context was deleted. |
-
-
-4668 |
-An application was initialized. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4665 | An attempt was made to create an application client context. |
+| 4666 | An application attempted an operation: |
+| 4667 | An application client context was deleted. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-application-group-management.md b/windows/keep-secure/audit-application-group-management.md
index 1dbeea62df..3055b72f6d 100644
--- a/windows/keep-secure/audit-application-group-management.md
+++ b/windows/keep-secure/audit-application-group-management.md
@@ -5,14 +5,13 @@ ms.assetid: 1bcaa41e-5027-4a86-96b7-f04eaf1c0606
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Application Group Management
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the advanced security audit policy setting, **Audit Application Group Management**, which determines whether the operating system generates audit events when application group management tasks are performed.
@@ -20,80 +19,25 @@ This topic for the IT professional describes the advanced security audit policy
Application group management tasks include:
- An application group is created, changed, or deleted.
-
- A member is added to or removed from an application group.
Event volume: Low
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4783 |
-A basic application group was created.
- |
-
-
-4784 |
-A basic application group was changed.
- |
-
-
-4785 |
-A member was added to a basic application group.
- |
-
-
-4786 |
-A member was removed from a basic application group.
- |
-
-
-4787 |
-A non-member was added to a basic application group.
- |
-
-
-4788 |
-A non-member was removed from a basic application group.
- |
-
-
-4789 |
-A basic application group was deleted.
- |
-
-
-4790 |
-An LDAP query group was created.
- |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4783 | A basic application group was created. |
+| 4784 | A basic application group was changed. |
+| 4785 | A member was added to a basic application group. |
+| 4786 | A member was removed from a basic application group. |
+| 4787 | A non-member was added to a basic application group. |
+| 4788 | A non-member was removed from a basic application group. |
+| 4789 | A basic application group was deleted. |
+| 4790 | An LDAP query group was created. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-audit-policy-change.md b/windows/keep-secure/audit-audit-policy-change.md
index 70984b9dcc..65b7d6261e 100644
--- a/windows/keep-secure/audit-audit-policy-change.md
+++ b/windows/keep-secure/audit-audit-policy-change.md
@@ -5,14 +5,13 @@ ms.assetid: 7153bf75-6978-4d7e-a821-59a699efb8a9
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Audit Policy Change
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the Advanced Security Audit policy setting, **Audit Audit Policy Change**, which determines whether the operating system generates audit events when changes are made to audit policy.
@@ -20,107 +19,37 @@ This topic for the IT professional describes the Advanced Security Audit policy
Changes to audit policy that are audited include:
- Changing permissions and audit settings on the audit policy object (by using **auditpol /set /sd**).
-
- Changing the system audit policy.
-
- Registering and unregistering security event sources.
-
- Changing per-user audit settings.
-
- Changing the value of **CrashOnAuditFail**.
-
- Changing audit settings on an object (for example, modifying the system access control list (SACL) for a file or registry key).
- **Note**
- SACL change auditing is performed when a SACL for an object has changed and the Policy Change category is configured. Discretionary access control list (DACL) and owner change auditing are performed when Object Access auditing is configured and the object's SACL is set for auditing of the DACL or owner change.
-
+ > **Note:** SACL change auditing is performed when a SACL for an object has changed and the Policy Change category is configured. Discretionary access control list (DACL) and owner change auditing are performed when Object Access auditing is configured and the object's SACL is set for auditing of the DACL or owner change.
-
- Changing anything in the Special Groups list.
-**Important**
-Changes to the audit policy are critical security events.
-
+> **Important:** Changes to the audit policy are critical security events.
-
Event volume: Low
Default: Success
-
-
-
-
-
-
-
-
-
-
-4715 |
-The audit policy (SACL) on an object was changed. |
-
-
-4719 |
-System audit policy was changed. |
-
-
-4817 |
-Auditing settings on an object were changed.
-
- Note
- This event is logged only on computers running the supported versions of the Windows operating system.
-
+| Event ID | Event message |
+| - | - |
+| 4715 | The audit policy (SACL) on an object was changed. |
+| 4719 | System audit policy was changed. |
+| 4817 | Auditing settings on an object were changed.
**Note: ** This event is logged only on computers running the supported versions of the Windows operating system. |
+| 4902 | The Per-user audit policy table was created. |
+| 4904 | An attempt was made to register a security event source. |
+| 4905 | An attempt was made to unregister a security event source. |
+| 4906 | The CrashOnAuditFail value has changed. |
+| 4907 | Auditing settings on object were changed. |
+| 4908 | Special Groups Logon table modified. |
+| 4912 | Per User Audit Policy was changed. |
- |
-
-
-4902 |
-The Per-user audit policy table was created. |
-
-
-4904 |
-An attempt was made to register a security event source. |
-
-
-4905 |
-An attempt was made to unregister a security event source. |
-
-
-4906 |
-The CrashOnAuditFail value has changed. |
-
-
-4907 |
-Auditing settings on object were changed. |
-
-
-4908 |
-Special Groups Logon table modified. |
-
-
-4912 |
-Per User Audit Policy was changed. |
-
-
-
-
-
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-audit-the-access-of-global-system-objects.md b/windows/keep-secure/audit-audit-the-access-of-global-system-objects.md
index ead3ed4c81..767ec7c30a 100644
--- a/windows/keep-secure/audit-audit-the-access-of-global-system-objects.md
+++ b/windows/keep-secure/audit-audit-the-access-of-global-system-objects.md
@@ -5,21 +5,19 @@ ms.assetid: 20d40a79-ce89-45e6-9bb4-148f83958460
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit: Audit the access of global system objects
-
**Applies to**
-
- Windows 10
Describes the best practices, location, values, and security considerations for the **Audit: Audit the access of global system objects** security policy setting.
## Reference
-
If you enable this policy setting, a default system access control list (SACL) is applied when the device creates system objects such as mutexes, events, semaphores, and MS-DOS® devices. If you also enable the [Audit object access](basic-audit-object-access.md) audit setting, access to these system objects is audited.
Global system objects, also known as "base system objects" or "base named objects," are temporary kernel objects that have had names assigned to them by the application or system component that created them. These objects are most commonly used to synchronize multiple applications or multiple parts of a complex application. Because they have names, these objects are global in scope and, therefore, visible to all processes on the device. These objects all have a security descriptor; but typically, they do not have a NULL SACL. If you enable this policy setting and it takes effect at startup time, the kernel assigns a SACL to these objects when they are created.
@@ -31,9 +29,7 @@ Enabling this policy setting can generate a large number of security events, esp
### Possible values
- Enabled
-
- Disabled
-
- Not defined
### Best practices
@@ -48,50 +44,17 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Sec
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
-
-
-
-
-
-
-
-
-
-Default Domain Policy |
-Not defined |
-
-
-Default Domain Controller Policy |
-Not defined |
-
-
-Stand-Alone Server Default Settings |
-Disabled |
-
-
-DC Effective Default Settings |
-Disabled |
-
-
-Member Server Effective Default Settings |
-Disabled |
-
-
-Client Computer Effective Default Settings |
-Disabled |
-
-
-
-
+| Server type or GPO | Default value |
+| - | - |
+| Default Domain Policy | Not defined |
+| Default Domain Controller Policy | Not defined |
+| Stand-Alone Server Default Settings | Disabled |
+| DC Effective Default Settings | Disabled |
+| Member Server Effective Default Settings | Disabled |
+| Client Computer Effective Default Settings | Disabled |
-
## Policy management
-
This section describes features and tools that are available to help you manage this policy.
### Restart requirement
@@ -107,121 +70,34 @@ All auditing capabilities are integrated in Group Policy. You can configure, dep
To audit attempts to access global system objects, you can use one of two security audit policy settings:
- [Audit Kernel Object](audit-kernel-object.md) in Advanced Security Audit Policy Settings\\Object Access
-
- [Audit object access](basic-audit-object-access.md) under Security Settings\\Local Policies\\Audit Policy
If possible, use the Advanced Security Audit Policy option to reduce the number of unrelated audit events that you generate.
If the [Audit Kernel Object](audit-kernel-object.md) setting is configured, the following events are generated:
-
-
-
-
-
-
-
-
-
-
-4659 |
-A handle to an object was requested with intent to delete. |
-
-
-4660 |
-An object was deleted. |
-
-
-4661 |
-A handle to an object was requested. |
-
-
-4663 |
-An attempt was made to access an object. |
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4659 | A handle to an object was requested with intent to delete. |
+| 4660 | An object was deleted. |
+| 4661 | A handle to an object was requested. |
+| 4663 | An attempt was made to access an object. |
+
+If the [Audit Kernel Object](audit-kernel-object.md) setting is configured, the following events are generated:
-
-
-If the [Audit Kernel Object](audit-kernel-object.md) setting is configured, the following events are generated.
-
-
-
-
-
-
-
-
-
-
-
-560 |
-Access was granted to an already existing object. |
-
-
-562 |
-A handle to an object was closed. |
-
-
-563 |
-An attempt was made to open an object with the intent to delete it.
-
- Note
- This is used by file systems when the FILE_DELETE_ON_CLOSE flag is specified in Createfile().
-
-
- |
-
-
-564 |
-A protected object was deleted. |
-
-
-565 |
-Access was granted to an already existing object type. |
-
-
-567 |
-A permission associated with a handle was used.
-
- Note
- A handle is created with certain granted permissions (Read, Write, and so on). When the handle is used, up to one audit is generated for each of the permissions that was used.
-
-
- |
-
-
-569 |
-The resource manager in Authorization Manager attempted to create a client context. |
-
-
-570 |
-A client attempted to access an object.
-
- Note
- An event will be generated for every attempted operation on the object.
-
-
- |
-
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 560 | Access was granted to an already existing object. |
+| 562 | A handle to an object was closed. |
+| 563 | An attempt was made to open an object with the intent to delete it.
**Note: **This is used by file systems when the FILE_DELETE_ON_CLOSE flag is specified in Createfile() |
+| 564 | A protected object was deleted. |
+| 565 | Access was granted to an already existing object type. |
+| 567 | A permission associated with a handle was used.
**Note:** A handle is created with certain granted permissions (Read, Write, and so on). When the handle is used, up to one audit is generated for each of the permissions that was used. |
+| 569 | The resource manager in Authorization Manager attempted to create a client context. |
+| 570 | A client attempted to access an object.
**Note: ** An event will be generated for every attempted operation on the object. |
## Security considerations
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
@@ -235,19 +111,8 @@ Enable the **Audit: Audit the access of global system objects** setting.
### Potential impact
If you enable the **Audit: Audit the access of global system objects** setting, a large number of security events could be generated, especially on busy domain controllers and application servers. Such an occurrence could cause servers to respond slowly and force the Security log to record numerous events of little significance. This policy setting can only be enabled or disabled, and there is no way to choose which events are recorded from this setting. Even organizations that have the resources to analyze events that are generated by this policy setting are not likely to have the source code or a description of what each named object is used for. Therefore, it is unlikely that most organizations would benefit by enabling this policy setting.
-
To reduce the number of audit events generated, use the advanced audit policy.
## Related topics
-
-[Security Options](security-options.md)
-
-
-
-
-
-
-
-
-
+- [Security Options](security-options.md)
diff --git a/windows/keep-secure/audit-audit-the-use-of-backup-and-restore-privilege.md b/windows/keep-secure/audit-audit-the-use-of-backup-and-restore-privilege.md
index ab4fd042a3..49b518da5a 100644
--- a/windows/keep-secure/audit-audit-the-use-of-backup-and-restore-privilege.md
+++ b/windows/keep-secure/audit-audit-the-use-of-backup-and-restore-privilege.md
@@ -5,29 +5,25 @@ ms.assetid: f656a2bb-e8d6-447b-8902-53df3a7756c5
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit: Audit the use of Backup and Restore privilege
-
**Applies to**
-
- Windows 10
Describes the best practices, location, values, and security considerations for the **Audit: Audit the use of Backup and Restore privilege** security policy setting.
## Reference
-
The **Audit: Audit the use of Backup and Restore privilege** policy setting determines whether to audit the use of all user rights, including Backup and Restore, when the **Audit privilege use** policy setting is configured. Enabling both policy settings generates an audit event for every file that is backed up or restored.
### Possible values
- Enabled
-
- Disabled
-
- Not defined
### Best practices
@@ -42,50 +38,17 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Sec
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
-
-
-
-
-
-
-
-
-
-Default Domain Policy |
-Not defined |
-
-
-Default Domain Controller Policy |
-Not defined |
-
-
-Stand-Alone Server Default Settings |
-Disabled |
-
-
-DC Effective Default Settings |
-Disabled |
-
-
-Member Server Effective Default Settings |
-Disabled |
-
-
-Client Computer Effective Default Settings |
-Disabled |
-
-
-
-
+| Server type or GPO | Default value |
+| - | - |
+| Default Domain Policy | Not defined |
+| Default Domain Controller Policy | Not defined |
+| Stand-Alone Server Default Settings | Disabled |
+| DC Effective Default Settings | Disabled |
+| Member Server Effective Default Settings | Disabled |
+| Client Computer Effective Default Settings | Disabled |
-
## Policy management
-
This section describes features and tools that are available to help you manage this policy.
### Restart requirement
@@ -102,7 +65,6 @@ Alternately, you can use the advanced audit policy, [Audit Sensitive Privilege U
## Security considerations
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
@@ -112,7 +74,6 @@ When the backup and restore function is used, it creates a copy of the file syst
### Countermeasure
Enable the **Audit: Audit the use of Backup and Restore privilege** setting. Alternatively, implement automatic log backup by configuring the **AutoBackupLogFiles** registry key. If you enable this option when the [Audit privilege use](basic-audit-privilege-use.md) setting is also enabled, an audit event is generated for every file that is backed up or restored. This information could help you to identify an account that was used to accidentally or maliciously restore data in an unauthorized manner.
-
For more information about configuring this key, see Microsoft Knowledge Base article [100879](http://go.microsoft.com/fwlink/p/?LinkId=100879).
### Potential impact
@@ -121,14 +82,6 @@ If you enable this policy setting, a large number of security events could be ge
## Related topics
-
-[Security Options](security-options.md)
-
+- [Security Options](security-options.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-authentication-policy-change.md b/windows/keep-secure/audit-authentication-policy-change.md
index 2a5dc7e290..e26a96a284 100644
--- a/windows/keep-secure/audit-authentication-policy-change.md
+++ b/windows/keep-secure/audit-authentication-policy-change.md
@@ -5,14 +5,13 @@ ms.assetid: aa9cea7a-aadf-47b7-b704-ac253b8e79be
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Authentication Policy Change
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes this Advanced Security Audit policy setting, **Audit Authentication Policy Change**, which determines whether the operating system generates audit events when changes are made to authentication policy.
@@ -20,26 +19,16 @@ This topic for the IT professional describes this Advanced Security Audit policy
Changes made to authentication policy include:
- Creation, modification, and removal of forest and domain trusts.
-
- Changes to Kerberos policy under **Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Kerberos Policy**.
- **Note**
- The audit event is logged when the policy is applied, not when settings are modified by the administrator.
-
+ > **Note:** The audit event is logged when the policy is applied, not when settings are modified by the administrator.
-
- When any of the following user rights is granted to a user or group:
-
- **Access this computer from the network**
-
- **Allow logon locally**
-
- **Allow logon through Remote Desktop**
-
- **Logon as a batch job**
-
- **Logon as a service**
-
- Namespace collision, such as when an added trust collides with an existing namespace name.
This setting is useful for tracking changes in domain-level and forest-level trust and privileges that are granted to user accounts or groups.
@@ -48,69 +37,20 @@ Event volume: Low
Default: Success
-
-
-
-
-
-
-
-
-
-
-4713 |
-Kerberos policy was changed. |
-
-
-4716 |
-Trusted domain information was modified. |
-
-
-4717 |
-System security access was granted to an account. |
-
-
-4718 |
-System security access was removed from an account. |
-
-
-4739 |
-Domain Policy was changed. |
-
-
-4864 |
-A namespace collision was detected. |
-
-
-4865 |
-A trusted forest information entry was added. |
-
-
-4866 |
-A trusted forest information entry was removed. |
-
-
-4867 |
-A trusted forest information entry was modified. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4713 | Kerberos policy was changed. |
+| 4716 | Trusted domain information was modified. |
+| 4717 | System security access was granted to an account. |
+| 4718 | System security access was removed from an account. |
+| 4739 | Domain Policy was changed. |
+| 4864 | A namespace collision was detected. |
+| 4865 | A trusted forest information entry was added. |
+| 4866 | A trusted forest information entry was removed. |
+| 4867 | A trusted forest information entry was modified. |
-
## Related topics
-
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+
+ - [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-authorization-policy-change.md b/windows/keep-secure/audit-authorization-policy-change.md
index 0194d0a071..3bff0a5dd9 100644
--- a/windows/keep-secure/audit-authorization-policy-change.md
+++ b/windows/keep-secure/audit-authorization-policy-change.md
@@ -5,14 +5,13 @@ ms.assetid: ca0587a2-a2b3-4300-aa5d-48b4553c3b36
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Authorization Policy Change
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the Advanced Security Audit policy setting, **Audit Authorization Policy Change**, which determines whether the operating system generates audit events when specific changes are made to the authorization policy.
@@ -20,60 +19,22 @@ This topic for the IT professional describes the Advanced Security Audit policy
Authorization policy changes that can be audited include:
- Assigning or removing user rights (privileges) such as **SeCreateTokenPrivilege**, except for the system access rights that are audited by using the [Audit Authentication Policy Change](audit-authentication-policy-change.md) subcategory.
-
- Changing the Encrypting File System (EFS) policy.
-Event volume: Low
+Event volume: Very high
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4704 |
-A user right was assigned. |
-
-
-4705 |
-A user right was removed. |
-
-
-4706 |
-A new trust was created to a domain. |
-
-
-4707 |
-A trust to a domain was removed. |
-
-
-4714 |
-Encrypted data recovery policy was changed. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4704 | A user right was assigned. |
+| 4705 | A user right was removed. |
+| 4706 | A new trust was created to a domain. |
+| 4707 | A trust to a domain was removed. |
+| 4714 | Encrypted data recovery policy was changed. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-central-access-policy-staging.md b/windows/keep-secure/audit-central-access-policy-staging.md
index 61ee3a28e8..e53abd2a09 100644
--- a/windows/keep-secure/audit-central-access-policy-staging.md
+++ b/windows/keep-secure/audit-central-access-policy-staging.md
@@ -5,14 +5,13 @@ ms.assetid: D9BB11CE-949A-4B48-82BF-30DC5E6FC67D
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Central Access Policy Staging
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the Advanced Security Audit policy setting, **Audit Central Access Policy Staging**, which determines permissions on a Central Access Policy.
@@ -21,37 +20,12 @@ Event volume: Medium
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4818 |
-Proposed Central Access Policy does not grant the same access permissions as the current Central Access Policy |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4818 | Proposed Central Access Policy does not grant the same access permissions as the current Central Access Policy |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-certification-services.md b/windows/keep-secure/audit-certification-services.md
index ea8af0a656..f23bdde027 100644
--- a/windows/keep-secure/audit-certification-services.md
+++ b/windows/keep-secure/audit-certification-services.md
@@ -5,14 +5,13 @@ ms.assetid: cdefc34e-fb1f-4eff-b766-17713c5a1b03
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Certification Services
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the Advanced Security Audit policy setting, **Audit Certification Services**, which determines whether the operating system generates events when Active Directory Certificate Services (AD CS) operations are performed.
@@ -20,25 +19,15 @@ This topic for the IT professional describes the Advanced Security Audit policy
Examples of AD CS operations include:
- AD CS starts, shuts down, is backed up, or is restored.
-
- Certificate revocation list (CRL)-related tasks are performed.
-
- Certificates are requested, issued, or revoked.
-
- Certificate manager settings for AD CS are changed.
-
- The configuration and properties of the certification authority (CA) are changed.
-
- AD CS templates are modified.
-
- Certificates are imported.
-
- A CA certificate is published to Active Directory Domain Services.
-
- Security permissions for AD CS role services are modified.
-
- Keys are archived, imported, or retrieved.
-
- The OCSP Responder Service is started or stopped.
Monitoring these operational events is important to ensure that AD CS role services are functioning properly.
@@ -47,157 +36,42 @@ Event volume: Low to medium on servers that host AD CS role services
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4868 |
-The certificate manager denied a pending certificate request. |
-
-
-4869 |
-Certificate Services received a resubmitted certificate request. |
-
-
-4870 |
-Certificate Services revoked a certificate. |
-
-
-4871 |
-Certificate Services received a request to publish the certificate revocation list (CRL). |
-
-
-4872 |
-Certificate Services published the certificate revocation list (CRL). |
-
-
-4873 |
-A certificate request extension changed. |
-
-
-4874 |
-One or more certificate request attributes changed. |
-
-
-4875 |
-Certificate Services received a request to shut down. |
-
-
-4876 |
-Certificate Services backup started. |
-
-
-4877 |
-Certificate Services backup completed. |
-
-
-4878 |
-Certificate Services restore started. |
-
-
-4879 |
-Certificate Services restore completed. |
-
-
-4880 |
-Certificate Services started. |
-
-
-4881 |
-Certificate Services stopped. |
-
-
-4882 |
-The security permissions for Certificate Services changed. |
-
-
-4883 |
-Certificate Services retrieved an archived key. |
-
-
-4884 |
-Certificate Services imported a certificate into its database. |
-
-
-4885 |
-The audit filter for Certificate Services changed. |
-
-
-4886 |
-Certificate Services received a certificate request. |
-
-
-4887 |
-Certificate Services approved a certificate request and issued a certificate. |
-
-
-4888 |
-Certificate Services denied a certificate request. |
-
-
-4889 |
-Certificate Services set the status of a certificate request to pending. |
-
-
-4890 |
-The certificate manager settings for Certificate Services changed. |
-
-
-4891 |
-A configuration entry changed in Certificate Services. |
-
-
-4892 |
-A property of Certificate Services changed. |
-
-
-4893 |
-Certificate Services archived a key. |
-
-
-4894 |
-Certificate Services imported and archived a key. |
-
-
-4895 |
-Certificate Services published the CA certificate to Active Directory Domain Services. |
-
-
-4896 |
-One or more rows have been deleted from the certificate database. |
-
-
-4897 |
-Role separation enabled: |
-
-
-4898 |
-Certificate Services loaded a template. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4868 | The certificate manager denied a pending certificate request. |
+| 4869 | Certificate Services received a resubmitted certificate request. |
+| 4870 | Certificate Services revoked a certificate. |
+| 4871 | Certificate Services received a request to publish the certificate revocation list (CRL). |
+| 4872 | Certificate Services published the certificate revocation list (CRL). |
+| 4873 | A certificate request extension changed. |
+| 4874 | One or more certificate request attributes changed. |
+| 4875 | Certificate Services received a request to shut down. |
+| 4876 | Certificate Services backup started. |
+| 4877 | Certificate Services backup completed. |
+| 4878 | Certificate Services restore started. |
+| 4879 | Certificate Services restore completed. |
+| 4880 | Certificate Services started. |
+| 4881 | Certificate Services stopped. |
+| 4882 | The security permissions for Certificate Services changed. |
+| 4883 | Certificate Services retrieved an archived key. |
+| 4884 | Certificate Services imported a certificate into its database. |
+| 4885 | The audit filter for Certificate Services changed. |
+| 4886 | Certificate Services received a certificate request. |
+| 4887 | Certificate Services approved a certificate request and issued a certificate. |
+| 4888 | Certificate Services denied a certificate request. |
+| 4889 | Certificate Services set the status of a certificate request to pending. |
+| 4890 | The certificate manager settings for Certificate Services changed. |
+| 4891 | A configuration entry changed in Certificate Services. |
+| 4892 | A property of Certificate Services changed. |
+| 4893 | Certificate Services archived a key. |
+| 4894 | Certificate Services imported and archived a key. |
+| 4895 | Certificate Services published the CA certificate to Active Directory Domain Services. |
+| 4896 | One or more rows have been deleted from the certificate database. |
+| 4897 | Role separation enabled: |
+| 4898 | Certificate Services loaded a template. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-computer-account-management.md b/windows/keep-secure/audit-computer-account-management.md
index a461349a08..5211936625 100644
--- a/windows/keep-secure/audit-computer-account-management.md
+++ b/windows/keep-secure/audit-computer-account-management.md
@@ -5,14 +5,13 @@ ms.assetid: 6c406693-57bf-4411-bb6c-ff83ce548991
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Computer Account Management
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the advanced security audit policy setting, **Audit Computer Account Management**, which determines whether the operating system generates audit events when a computer account is created, changed, or deleted.
@@ -23,45 +22,14 @@ Event volume: Low
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4741 |
-A computer account was created. |
-
-
-4742 |
-A computer account was changed. |
-
-
-4743 |
-A computer account was deleted. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4741 | A computer account was created. |
+| 4742 | A computer account was changed. |
+| 4743 | A computer account was deleted. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-credential-validation.md b/windows/keep-secure/audit-credential-validation.md
index 3a0818f62d..7f4232806f 100644
--- a/windows/keep-secure/audit-credential-validation.md
+++ b/windows/keep-secure/audit-credential-validation.md
@@ -5,14 +5,13 @@ ms.assetid: 6654b33a-922e-4a43-8223-ec5086dfc926
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Credential Validation
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
@@ -21,62 +20,24 @@ This topic for the IT professional describes the advanced security audit policy
These events occur on the computer that is authoritative for the credentials as follows:
- For domain accounts, the domain controller is authoritative.
-
- For local accounts, the local computer is authoritative.
Event volume: High on domain controllers
-Because domain accounts are used much more frequently than local accounts in enterprise environments, most of the Account Logon events in a domain environment occur on the domain controllers that are authoritative for the domain accounts. However, these events can occur on any computer, and they may occur in conjunction with or on separate computers from Logon and Logoff events.
+Because domain accounts are used much more frequently than local accounts in enterprise environments, most of the Account Logon events in a domain environment occur on the domain controllers that are authoritative for the domain accounts. However, these events can occur on any computer, and they
+may occur in conjunction with or on separate computers from Logon and Logoff events.
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4774 |
-An account was mapped for logon.
- |
-
-
-4775 |
-An account could not be mapped for logon.
- |
-
-
-4776 |
-The domain controller attempted to validate the credentials for an account.
- |
-
-
-4777 |
-The domain controller failed to validate the credentials for an account.
- |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4774 | An account was mapped for logon. |
+| 4775 | An account could not be mapped for logon. |
+| 4776 | The domain controller attempted to validate the credentials for an account. |
+| 4777 | The domain controller failed to validate the credentials for an account. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-detailed-directory-service-replication.md b/windows/keep-secure/audit-detailed-directory-service-replication.md
index 058f7ae1f1..ae2e46a570 100644
--- a/windows/keep-secure/audit-detailed-directory-service-replication.md
+++ b/windows/keep-secure/audit-detailed-directory-service-replication.md
@@ -2,6 +2,7 @@
title: Audit Detailed Directory Service Replication (Windows 10)
description: This topic for the IT professional describes the advanced security audit policy setting, Audit Detailed Directory Service Replication, which determines whether the operating system generates audit events that contain detailed tracking information about data that is replicated between domain controllers.
ms.assetid: 1b89c8f5-bce7-4b20-8701-42585c7ab993
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
@@ -10,9 +11,7 @@ author: brianlic-msft
# Audit Detailed Directory Service Replication
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the advanced security audit policy setting, **Audit Detailed Directory Service Replication**, which determines whether the operating system generates audit events that contain detailed tracking information about data that is replicated between domain controllers.
@@ -23,65 +22,19 @@ Event volume: These events can create a very high volume of event data.
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4928 |
-An Active Directory replica source naming context was established. |
-
-
-4929 |
-An Active Directory replica source naming context was removed. |
-
-
-4930 |
-An Active Directory replica source naming context was modified. |
-
-
-4931 |
-An Active Directory replica destination naming context was modified. |
-
-
-4934 |
-Attributes of an Active Directory object were replicated. |
-
-
-4935 |
-Replication failure begins. |
-
-
-4936 |
-Replication failure ends. |
-
-
-4937 |
-A lingering object was removed from a replica. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4928 | An Active Directory replica source naming context was established. |
+| 4929 | An Active Directory replica source naming context was removed. |
+| 4930 | An Active Directory replica source naming context was modified. |
+| 4931 | An Active Directory replica destination naming context was modified. |
+| 4934 | Attributes of an Active Directory object were replicated. |
+| 4935 | Replication failure begins. |
+| 4936 | Replication failure ends. |
+| 4937 | A lingering object was removed from a replica. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-detailed-file-share.md b/windows/keep-secure/audit-detailed-file-share.md
index fc3a48ffb3..f60e4dd5f2 100644
--- a/windows/keep-secure/audit-detailed-file-share.md
+++ b/windows/keep-secure/audit-detailed-file-share.md
@@ -5,60 +5,30 @@ ms.assetid: 60310104-b820-4033-a1cb-022a34f064ae
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Detailed File Share
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the Advanced Security Audit policy setting, **Audit Detailed File Share**, which allows you to audit attempts to access files and folders on a shared folder.
The Detailed File Share setting logs an event every time a file or folder is accessed, whereas the File Share setting only records one event for any connection established between a client computer and file share. Detailed File Share audit events include detailed information about the permissions or other criteria used to grant or deny access.
-
-**Note**
-There are no system access control lists (SACLs) for shared folders. If this policy setting is enabled, access to all shared files and folders on the system is audited.
-
+> **Note:** There are no system access control lists (SACLs) for shared folders. If this policy setting is enabled, access to all shared files and folders on the system is audited.
-
Event volume: High on a file server or domain controller because of SYSVOL network access required by Group Policy
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-5145 |
-A network share object was checked to see whether the client can be granted desired access. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 5145 | A network share object was checked to see whether the client can be granted desired access. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-directory-service-access.md b/windows/keep-secure/audit-directory-service-access.md
index 5977f8db1c..230dce9a69 100644
--- a/windows/keep-secure/audit-directory-service-access.md
+++ b/windows/keep-secure/audit-directory-service-access.md
@@ -5,60 +5,30 @@ ms.assetid: ba2562ba-4282-4588-b87c-a3fcb771c7d0
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Directory Service Access
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the advanced security audit policy setting, **Audit Directory Service Access**, which determines whether the operating system generates audit events when an Active Directory Domain Services (AD DS) object is accessed.
These events are similar to the Directory Service Access events in previous versions of the Windows Server operating systems.
-
-**Important**
-Audit events are generated only on objects with configured system access control lists (SACLs), and only when they are accessed in a manner that matches the SACL settings.
-
+> **Important:** Audit events are generated only on objects with configured system access control lists (SACLs), and only when they are accessed in a manner that matches the SACL settings.
-
Event volume: High on servers running AD DS role services; none on client computers
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4662 |
-An operation was performed on an object. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4662 | An operation was performed on an object. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-directory-service-changes.md b/windows/keep-secure/audit-directory-service-changes.md
index 5eb81446dc..361827a614 100644
--- a/windows/keep-secure/audit-directory-service-changes.md
+++ b/windows/keep-secure/audit-directory-service-changes.md
@@ -5,14 +5,13 @@ ms.assetid: 9f7c0dd4-3977-47dd-a0fb-ec2f17cad05e
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Directory Service Changes
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the advanced security audit policy setting, **Audit Directory Service Changes**, which determines whether the operating system generates audit events when changes are made to objects in Active Directory Domain Services (AD DS).
@@ -20,75 +19,31 @@ This topic for the IT professional describes the advanced security audit policy
The types of changes that are reported are:
- Create
-
- Delete
-
- Modify
-
- Move
-
- Undelete
Directory Service Changes auditing, where appropriate, indicates the old and new values of the changed properties of the objects that were changed.
-**Important**
-Audit events are generated only for objects with configured system access control lists (SACLs), and only when they are accessed in a manner that matches their SACL settings. Some objects and properties do not cause audit events to be generated due to settings on the object class in the schema.
-
+> **Important:** Audit events are generated only for objects with configured system access control lists (SACLs), and only when they are accessed in a manner that matches their SACL settings. Some objects and properties do not cause audit events to be generated due to settings on the object class in the schema.
-
This subcategory only logs events on domain controllers. Changes to Active Directory objects are important events to track in order to understand the state of the network policy.
Event volume: High on domain controllers; none on client computers
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-5136 |
-A directory service object was modified. |
-
-
-5137 |
-A directory service object was created. |
-
-
-5138 |
-A directory service object was undeleted. |
-
-
-5139 |
-A directory service object was moved. |
-
-
-5141 |
-A directory service object was deleted. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 5136 | A directory service object was modified. |
+| 5137 | A directory service object was created. |
+| 5138 | A directory service object was undeleted. |
+| 5139 | A directory service object was moved. |
+| 5141 | A directory service object was deleted. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-directory-service-replication.md b/windows/keep-secure/audit-directory-service-replication.md
index c316768163..9f09abada9 100644
--- a/windows/keep-secure/audit-directory-service-replication.md
+++ b/windows/keep-secure/audit-directory-service-replication.md
@@ -5,14 +5,13 @@ ms.assetid: b95d296c-7993-4e8d-8064-a8bbe284bd56
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Directory Service Replication
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the advanced security audit policy setting, **Audit Directory Service Replication**, which determines whether the operating system generates audit events when replication between two domain controllers begins and ends.
@@ -21,41 +20,13 @@ Event volume: Medium on domain controllers; none on client computers
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4932 |
-Synchronization of a replica of an Active Directory naming context has begun. |
-
-
-4933 |
-Synchronization of a replica of an Active Directory naming context has ended. |
-
-
-
-
+| Event ID | Event Message |
+| - | - |
+| 4932 | Synchronization of a replica of an Active Directory naming context has begun. |
+| 4933 | Synchronization of a replica of an Active Directory naming context has ended. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-distribution-group-management.md b/windows/keep-secure/audit-distribution-group-management.md
index 7dcf6a5049..1e259424ed 100644
--- a/windows/keep-secure/audit-distribution-group-management.md
+++ b/windows/keep-secure/audit-distribution-group-management.md
@@ -5,14 +5,13 @@ ms.assetid: d46693a4-5887-4a58-85db-2f6cba224a66
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Distribution Group Management
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the Advanced Security Audit policy setting, **Audit Distribution Group Management**, which determines whether the operating system generates audit events for specific distribution-group management tasks.
@@ -20,103 +19,34 @@ This topic for the IT professional describes the Advanced Security Audit policy
Tasks for distribution-group management that can be audited include:
- A distribution group is created, changed, or deleted.
-
- A member is added to or removed from a distribution group.
This subcategory to which this policy belongs is logged only on domain controllers.
-
-**Note**
-Distribution groups cannot be used to manage access control permissions.
-
+> **Note:** Distribution groups cannot be used to manage access control permissions.
-
Event volume: Low
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4744 |
-A security-disabled local group was created. |
-
-
-4745 |
-A security-disabled local group was changed. |
-
-
-4746 |
-A member was added to a security-disabled local group. |
-
-
-4747 |
-A member was removed from a security-disabled local group. |
-
-
-4748 |
-A security-disabled local group was deleted. |
-
-
-4749 |
-A security-disabled global group was created. |
-
-
-4750 |
-A security-disabled global group was changed. |
-
-
-4751 |
-A member was added to a security-disabled global group. |
-
-
-4752 |
-A member was removed from a security-disabled global group. |
-
-
-4753 |
-A security-disabled global group was deleted. |
-
-
-4759 |
-A security-disabled universal group was created. |
-
-
-4760 |
-A security-disabled universal group was changed. |
-
-
-4761 |
-A member was added to a security-disabled universal group. |
-
-
-4762 |
-A member was removed from a security-disabled universal group. |
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4744 | A security-disabled local group was created. |
+| 4745 | A security-disabled local group was changed. |
+| 4746 | A member was added to a security-disabled local group. |
+| 4747 | A member was removed from a security-disabled local group. |
+| 4748 | A security-disabled local group was deleted. |
+| 4749 | A security-disabled global group was created. |
+| 4750 | A security-disabled global group was changed. |
+| 4751 | A member was added to a security-disabled global group. |
+| 4752 | A member was removed from a security-disabled global group. |
+| 4753 | A security-disabled global group was deleted. |
+| 4759 | A security-disabled universal group was created. |
+| 4760 | A security-disabled universal group was changed. |
+| 4761 | A member was added to a security-disabled universal group. |
+| 4762 | A member was removed from a security-disabled universal group. |
+ ## Related topics
+
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-## Related topics
-
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-dpapi-activity.md b/windows/keep-secure/audit-dpapi-activity.md
index 310cb480c6..1e7c77ac71 100644
--- a/windows/keep-secure/audit-dpapi-activity.md
+++ b/windows/keep-secure/audit-dpapi-activity.md
@@ -5,19 +5,17 @@ ms.assetid: be4d4c83-c857-4e3d-a84e-8bcc3f2c99cd
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit DPAPI Activity
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
This topic for the IT professional describes the Advanced Security Audit policy setting, **Audit DPAPI Activity**, which determines whether the operating system generates audit events when encryption or decryption calls are made into the data protection application interface (DPAPI).
-
DPAPI is used to protect secret information such as stored passwords and key information. For more information about DPAPI, see [Windows Data Protection](http://go.microsoft.com/fwlink/p/?linkid=121720) (http://go.microsoft.com/fwlink/p/?linkid=121720).
Event volume: Low
@@ -26,49 +24,15 @@ Default: Not configured
If this policy setting is configured, the following events appear on computers running the supported versions of the Windows operating system as designated in the **Applies To** list at the beginning of this topic, in addition to Windows Server 2008 and Windows Vista.
-
-
-
-
-
-
-
-
-
-
-4692 |
-Backup of data protection master key was attempted. |
-
-
-4693 |
-Recovery of data protection master key was attempted. |
-
-
-4694 |
-Protection of auditable protected data was attempted. |
-
-
-4695 |
-Unprotection of auditable protected data was attempted. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4692 | Backup of data protection master key was attempted. |
+| 4693 | Recovery of data protection master key was attempted. |
+| 4694 | Protection of auditable protected data was attempted. |
+| 4695 | Unprotection of auditable protected data was attempted. |
-
## Related resource
-
-[Advanced Security Audit Policy Settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced Security Audit Policy Settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-file-share.md b/windows/keep-secure/audit-file-share.md
index 9eb592c046..8040bc118a 100644
--- a/windows/keep-secure/audit-file-share.md
+++ b/windows/keep-secure/audit-file-share.md
@@ -5,85 +5,36 @@ ms.assetid: 9ea985f8-8936-4b79-abdb-35cbb7138f78
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit File Share
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the Advanced Security Audit policy setting, **Audit File Share**, which determines whether the operating system generates audit events when a file share is accessed.
Audit events are not generated when shares are created, deleted, or when share permissions change.
-
-**Note**
-There are no system access control lists (SACLs) for shares; therefore, after this setting is enabled, access to all shares on the system will be audited.
-
+> **Note:** There are no system access control lists (SACLs) for shares; therefore, after this setting is enabled, access to all shares on the system will be audited.
-
Combined with File System auditing, File Share auditing enables you to track what content was accessed, the source (IP address and port) of the request, and the user account that was used for the access.
Event volume: High on a file server or domain controller (due to SYSVOL access by client computers for policy processing)
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-5140 |
-A network share object was accessed.
-
- Note
- This event is logged on computers running Windows 10, Windows Server 2016 Technical Preview, Windows Server 2008 R2, Windows Server 2008, Windows 7, or Windows Vista.
-
+| Event ID | Event message |
+| - |- |
+| 5140 | A network share object was accessed.
**Note:** This event is logged on computers running Windows 10, Windows Server 2016 Technical Preview, Windows Server 2008 R2, Windows Server 2008, Windows 7, or Windows Vista. |
+| 5142 | A network share object was added. |
+| 5143 | A network share object was modified. |
+| 5144 | A network share object was deleted. |
+| 5168 | SPN check for SMB/SMB2 failed. |
- |
-
-
-5142 |
-A network share object was added. |
-
-
-5143 |
-A network share object was modified. |
-
-
-5144 |
-A network share object was deleted. |
-
-
-5168 |
-SPN check for SMB/SMB2 failed. |
-
-
-
-
-
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-file-system.md b/windows/keep-secure/audit-file-system.md
index 66dfba0a30..53faccfac6 100644
--- a/windows/keep-secure/audit-file-system.md
+++ b/windows/keep-secure/audit-file-system.md
@@ -4,22 +4,19 @@ description: This topic for the IT professional describes the Advanced Security
ms.assetid: 6a71f283-b8e5-41ac-b348-0b7ec6ea0b1f
ms.prod: W10
ms.mktglfcycl: deploy
+ms.pagetype: security
ms.sitesec: library
author: brianlic-msft
---
# Audit File System
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
This topic for the IT professional describes the Advanced Security Audit policy setting, **Audit File System**, which determines whether the operating system generates audit events when users attempt to access file system objects.
-
Audit events are generated only for objects that have configured system access control lists (SACLs), and only if the type of access requested (such as Write, Read, or Modify) and the account making the request match the settings in the SACL.
-
If success auditing is enabled, an audit entry is generated each time any account successfully accesses a file system object that has a matching SACL. If failure auditing is enabled, an audit entry is generated each time any user unsuccessfully attempts to access a file system object that has a matching SACL.
These events are essential for tracking activity for file objects that are sensitive or valuable and require extra monitoring.
@@ -30,45 +27,14 @@ No audit events are generated for the default file system SACLs.
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4664 |
-An attempt was made to create a hard link. |
-
-
-4985 |
-The state of a transaction has changed. |
-
-
-5051 |
-A file was virtualized. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4664 | An attempt was made to create a hard link. |
+| 4985 | The state of a transaction has changed. |
+| 5051 | A file was virtualized. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-filtering-platform-connection.md b/windows/keep-secure/audit-filtering-platform-connection.md
index eac628b63b..a23961c6d9 100644
--- a/windows/keep-secure/audit-filtering-platform-connection.md
+++ b/windows/keep-secure/audit-filtering-platform-connection.md
@@ -5,14 +5,13 @@ ms.assetid: d72936e9-ff01-4d18-b864-a4958815df59
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Filtering Platform Connection
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the Advanced Security Audit policy setting, **Audit Filtering Platform Connection**, which determines whether the operating system generates audit events when connections are allowed or blocked by the Windows Filtering Platform.
@@ -22,84 +21,29 @@ Windows Filtering Platform (WFP) enables independent software vendors (ISVs) to
This security policy enables you to audit the following types of actions:
- The Windows Firewall service blocks an application from accepting incoming connections on the network.
-
- The Windows Filtering Platform allows or blocks a connection.
-
- The Windows Filtering Platform permits or blocks a bind to a local port.
-
- The Windows Filtering Platform permits or blocks an application or service from listening for incoming connections on a port.
Event volume: High
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-5031 |
-The Windows Firewall Service blocked an application from accepting incoming connections on the network. |
-
-
-5140 |
-A network share object was accessed. |
-
-
-5150 |
-The Windows Filtering Platform blocked a packet. |
-
-
-5151 |
-A more restrictive Windows Filtering Platform filter has blocked a packet. |
-
-
-5154 |
-The Windows Filtering Platform has permitted an application or service to listen on a port for incoming connections. |
-
-
-5155 |
-The Windows Filtering Platform has blocked an application or service from listening on a port for incoming connections. |
-
-
-5156 |
-The Windows Filtering Platform has allowed a connection. |
-
-
-5157 |
-The Windows Filtering Platform has blocked a connection. |
-
-
-5158 |
-The Windows Filtering Platform has permitted a bind to a local port. |
-
-
-5159 |
-The Windows Filtering Platform has blocked a bind to a local port. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 5031 | The Windows Firewall Service blocked an application from accepting incoming connections on the network. |
+| 5140 | A network share object was accessed. |
+| 5150 | The Windows Filtering Platform blocked a packet. |
+| 5151 | A more restrictive Windows Filtering Platform filter has blocked a packet. |
+| 5154 | The Windows Filtering Platform has permitted an application or service to listen on a port for incoming connections. |
+| 5155 | The Windows Filtering Platform has blocked an application or service from listening on a port for incoming connections. |
+| 5156 | The Windows Filtering Platform has allowed a connection. |
+| 5157 | The Windows Filtering Platform has blocked a connection. |
+| 5158 | The Windows Filtering Platform has permitted a bind to a local port. |
+| 5159 | The Windows Filtering Platform has blocked a bind to a local port. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-filtering-platform-packet-drop.md b/windows/keep-secure/audit-filtering-platform-packet-drop.md
index 2390c68fdd..fda5bc89e7 100644
--- a/windows/keep-secure/audit-filtering-platform-packet-drop.md
+++ b/windows/keep-secure/audit-filtering-platform-packet-drop.md
@@ -5,14 +5,13 @@ ms.assetid: 95457601-68d1-4385-af20-87916ddab906
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Filtering Platform Packet Drop
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the Advanced Security Audit policy setting, **Audit Filtering Platform Packet Drop**, which determines whether the operating system generates audit events when packets are dropped by the Windows Filtering Platform.
@@ -25,41 +24,13 @@ Event volume: High
Default setting: Not configured
-
-
-
-
-
-
-
-
-
-
-5152 |
-The Windows Filtering Platform blocked a packet. |
-
-
-5153 |
-A more restrictive Windows Filtering Platform filter has blocked a packet. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 5152 | The Windows Filtering Platform blocked a packet. |
+| 5153 | A more restrictive Windows Filtering Platform filter has blocked a packet. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-filtering-platform-policy-change.md b/windows/keep-secure/audit-filtering-platform-policy-change.md
index 98335becd4..97f04007ea 100644
--- a/windows/keep-secure/audit-filtering-platform-policy-change.md
+++ b/windows/keep-secure/audit-filtering-platform-policy-change.md
@@ -5,14 +5,13 @@ ms.assetid: 0eaf1c56-672b-4ea9-825a-22dc03eb4041
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Filtering Platform Policy Change
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the Advanced Security Audit policy setting, **Audit Filtering Platform Policy Change**, which determines whether the operating system generates audit events for certain IPsec and Windows Filtering Platform actions.
@@ -22,11 +21,8 @@ Windows Filtering Platform (WFP) enables independent software vendors (ISVs) to
This security policy setting determines whether the operating system generates audit events for:
- IPsec services status.
-
- Changes to IPsec settings.
-
- Status and changes to the Windows Filtering Platform engine and providers.
-
- IPsec Policy Agent service activities.
Event volume: Low
@@ -221,19 +217,9 @@ Default: Not configured
-
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-force-audit-policy-subcategory-settings-to-override.md b/windows/keep-secure/audit-force-audit-policy-subcategory-settings-to-override.md
index 4ebdec9654..2ceff2fa34 100644
--- a/windows/keep-secure/audit-force-audit-policy-subcategory-settings-to-override.md
+++ b/windows/keep-secure/audit-force-audit-policy-subcategory-settings-to-override.md
@@ -5,21 +5,19 @@ ms.assetid: 8ddc06bc-b6d6-4bac-9051-e0d77035bd4e
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings
-
**Applies to**
-
- Windows 10
Describes the best practices, location, values, and security considerations for the **Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings** security policy setting.
## Reference
-
You can manage your audit policy in a more precise way by using audit policy subcategories.
There are over 40 auditing subcategories that provide precise details about activities on a device. For info about these subcategories, see the [Advanced security audit policy settings](advanced-security-audit-policy-settings.md).
@@ -27,7 +25,6 @@ There are over 40 auditing subcategories that provide precise details about acti
### Possible values
- Enabled
-
- Disabled
### Best practices
@@ -42,50 +39,17 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Sec
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
-
-
-
-
-
-
-
-
-
-Default Domain Policy |
-Not defined |
-
-
-Default Domain Controller Policy |
-Not defined |
-
-
-Stand-Alone Server Default Settings |
-Enabled |
-
-
-DC Effective Default Settings |
-Enabled |
-
-
-Member Server Effective Default Settings |
-Enabled |
-
-
-Client Computer Effective Default Settings |
-Enabled |
-
-
-
-
+| Server type or GPO | Default value |
+| - | - |
+| Default Domain Policy | Not defined |
+| Default Domain Controller Policy | Not defined |
+| Stand-Alone Server Default Settings | Enabled |
+| DC Effective Default Settings | Enabled |
+| Member Server Effective Default Settings | Enabled |
+| Client Computer Effective Default Settings | Enabled |
-
## Policy management
-
This section describes features and tools that are available to help you manage this policy.
### Restart requirement
@@ -108,7 +72,6 @@ You can use auditpol.exe to display and manage audit policies from a command pro
## Security considerations
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
@@ -121,23 +84,12 @@ Enable audit policy subcategories as needed to track specific events.
### Potential impacts
-If you attempt to modify an audit setting by using Group Policy after enabling this setting through the command-line tools, the Group Policy audit setting is ignored in favor of the custom policy setting. To modify audit settings by using Group Policy, you must first disable the **SCENoApplyLegacyAuditPolicy** key.
-
-**Important**
-Be very cautious about audit settings that can generate a large volume of traffic. For example, if you enable success or failure auditing for all of the Privilege Use subcategories, the high volume of audit events that are generated can make it difficult to find other types of entries in the security event log. Such a configuration could also have a significant impact on system performance.
-
+If you attempt to modify an audit setting by using Group Policy after enabling this setting through the command-line tools, the Group Policy audit setting is ignored in favor of the custom policy setting. To modify audit settings by using Group Policy, you must first disable the
+**SCENoApplyLegacyAuditPolicy** key.
+> **Important:** Be very cautious about audit settings that can generate a large volume of traffic. For example, if you enable success or failure auditing for all of the Privilege Use subcategories, the high volume of audit events that are generated can make it difficult to find other types of entries in the security event log. Such a configuration could also have a significant impact on system performance.
-
## Related topics
-
-[Security Options](security-options.md)
-
+- [Security Options](security-options.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-group-membership.md b/windows/keep-secure/audit-group-membership.md
index d135909f8c..bfbd5e7887 100644
--- a/windows/keep-secure/audit-group-membership.md
+++ b/windows/keep-secure/audit-group-membership.md
@@ -5,14 +5,13 @@ ms.assetid: 1CD7B014-FBD9-44B9-9274-CC5715DE58B9
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Group Membership
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the advanced security audit policy setting, **Audit Group Membership**, which enables you to audit group memberships when they are enumerated on the client PC.
@@ -20,48 +19,20 @@ This topic for the IT professional describes the advanced security audit policy
This policy allows you to audit the group membership information in the user's logon token. Events in this subcategory are generated on the computer on which a logon session is created.
For an interactive logon, the security audit event is generated on the computer that the user logged on to. For a network logon, such as accessing a shared folder on the network, the security audit event is generated on the computer hosting the resource.
-
-**Note** You must also enable the **Audit Logon** setting under **Advanced Audit Policy Configuration\\System Audit Policies\\Logon/Logoff**.
-
+> **Note:** You must also enable the **Audit Logon** setting under **Advanced Audit Policy Configuration\\System Audit Policies\\Logon/Logoff**.
-
Multiple events are generated if the group membership information cannot fit in a single security audit event
Event volume: High
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4627 |
-Group membership information. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4627 | Group membership information. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-handle-manipulation.md b/windows/keep-secure/audit-handle-manipulation.md
index e54f17a6f2..da8a48ee26 100644
--- a/windows/keep-secure/audit-handle-manipulation.md
+++ b/windows/keep-secure/audit-handle-manipulation.md
@@ -5,68 +5,34 @@ ms.assetid: 1fbb004a-ccdc-4c80-b3da-a4aa7a9f4091
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Handle Manipulation
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the Advanced Security Audit policy setting, **Audit Handle Manipulation**, which determines whether the operating system generates audit events when a handle to an object is opened or closed.
Only objects with configured system access control lists (SACLs) generate these events, and only if the attempted handle operation matches the SACL.
-**Important**
-Handle Manipulation events are generated only for object types where the corresponding File System or Registry Object Access subcategory is enabled. For more information, see [Audit File System](audit-file-system.md) or [Audit Registry](audit-registry.md).
-
+> **Important:** Handle Manipulation events are generated only for object types where the corresponding File System or Registry Object Access subcategory is enabled. For more information, see [Audit File System](audit-file-system.md) or [Audit Registry](audit-registry.md).
Event volume: High, depending on how SACLs are configured
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4656 |
-A handle to an object was requested. |
-
-
-4658 |
-The handle to an object was closed. |
-
-
-4690 |
-An attempt was made to duplicate a handle to an object. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4656 | A handle to an object was requested. |
+| 4658 | The handle to an object was closed. |
+| 4690 | An attempt was made to duplicate a handle to an object. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-ipsec-driver.md b/windows/keep-secure/audit-ipsec-driver.md
index 8945926bb1..7394906faa 100644
--- a/windows/keep-secure/audit-ipsec-driver.md
+++ b/windows/keep-secure/audit-ipsec-driver.md
@@ -5,14 +5,13 @@ ms.assetid: c8b8c02f-5ad0-4ee5-9123-ea8cdae356a5
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit IPsec Driver
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the Advanced Security Audit policy setting, **Audit IPsec Driver**, which determines whether the operating system generates audit events for the activities of the IPsec driver.
@@ -20,15 +19,10 @@ This topic for the IT professional describes the Advanced Security Audit policy
The IPsec driver, using the IP Filter List from the active IPsec policy, watches for outbound IP packets that must be secured and inbound IP packets that must be verified and decrypted. This security policy setting reports on the following activities of the IPsec driver:
- Startup and shutdown of IPsec services.
-
- Packets dropped due to integrity-check failure.
-
- Packets dropped due to replay-check failure.
-
- Packets dropped due to being in plaintext.
-
- Packets received with an incorrect Security Parameter Index (SPI). (This can indicate malfunctioning hardware or interoperability problems.)
-
- Failure to process IPsec filters.
A high rate of packet drops by the IPsec filter driver may indicate attempts to gain access to the network by unauthorized systems.
@@ -39,77 +33,22 @@ Event volume: Medium
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4960 |
-IPsec dropped an inbound packet that failed an integrity check. If this problem persists, it could indicate a network issue or that packets are being modified in transit to this computer. Verify that the packets sent from the remote computer are the same as those received by this computer. This error might also indicate interoperability problems with other IPsec implementations. |
-
-
-4961 |
-IPsec dropped an inbound packet that failed a replay check. If this problem persists, it could indicate a replay attack against this computer. |
-
-
-4962 |
-IPsec dropped an inbound packet that failed a replay check. The inbound packet had too low a sequence number to ensure it was not a replay. |
-
-
-4963 |
-IPsec dropped an inbound clear text packet that should have been secured. This is usually due to the remote computer changing its IPsec policy without informing this computer. This could also be a spoofing attack attempt. |
-
-
-4965 |
-IPsec received a packet from a remote computer with an incorrect Security Parameter Index (SPI). This is usually caused by malfunctioning hardware that is corrupting packets. If these errors persist, verify that the packets sent from the remote computer are the same as those received by this computer. This error may also indicate interoperability problems with other IPsec implementations. In that case, if connectivity is not impeded, then these events can be ignored. |
-
-
-5478 |
-IPsec Services has started successfully. |
-
-
-5479 |
-IPsec Services has been shut down successfully. The shutdown of IPsec Services can put the computer at greater risk of network attack or expose the computer to potential security risks. |
-
-
-5480 |
-IPsec Services failed to get the complete list of network interfaces on the computer. This poses a potential security risk because some of the network interfaces may not get the protection provided by the applied IPsec filters. Use the IP Security Monitor snap-in to diagnose the problem. |
-
-
-5483 |
-IPsec Services failed to initialize RPC server. IPsec Services could not be started. |
-
-
-5484 |
-IPsec Services has experienced a critical failure and has been shut down. The shutdown of IPsec Services can put the computer at greater risk of network attack or expose the computer to potential security risks. |
-
-
-5485 |
-IPsec Services failed to process some IPsec filters on a plug-and-play event for network interfaces. This poses a potential security risk because some of the network interfaces may not get the protection provided by the applied IPsec filters. Use the IP Security Monitor snap-in to diagnose the problem. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4960 | IPsec dropped an inbound packet that failed an integrity check. If this problem persists, it could indicate a network issue or that packets are being modified in transit to this computer. Verify that the packets sent from the remote computer are the same as those received by this computer. This error might also indicate interoperability problems with other IPsec implementations. |
+| 4961 | IPsec dropped an inbound packet that failed a replay check. If this problem persists, it could indicate a replay attack against this computer. |
+| 4962 | IPsec dropped an inbound packet that failed a replay check. The inbound packet had too low a sequence number to ensure it was not a replay. |
+| 4963 | IPsec dropped an inbound clear text packet that should have been secured. This is usually due to the remote computer changing its IPsec policy without informing this computer. This could also be a spoofing attack attempt. |
+| 4965 | IPsec received a packet from a remote computer with an incorrect Security Parameter Index (SPI). This is usually caused by malfunctioning hardware that is corrupting packets. If these errors persist, verify that the packets sent from the remote computer are the same as those received by this computer. This error may also indicate interoperability problems with other IPsec implementations. In that case, if connectivity is not impeded, then these events can be ignored. |
+| 5478 | IPsec Services has started successfully. |
+| 5479 | IPsec Services has been shut down successfully. The shutdown of IPsec Services can put the computer at greater risk of network attack or expose the computer to potential security risks. |
+| 5480 | IPsec Services failed to get the complete list of network interfaces on the computer. This poses a potential security risk because some of the network interfaces may not get the protection provided by the applied IPsec filters. Use the IP Security Monitor snap-in to diagnose the problem. |
+| 5483 | IPsec Services failed to initialize RPC server. IPsec Services could not be started. |
+| 5484 | IPsec Services has experienced a critical failure and has been shut down. The shutdown of IPsec Services can put the computer at greater risk of network attack or expose the computer to potential security risks. |
+| 5485 | IPsec Services failed to process some IPsec filters on a plug-and-play event for network interfaces. This poses a potential security risk because some of the network interfaces may not get the protection provided by the applied IPsec filters. Use the IP Security Monitor snap-in to diagnose the problem. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-ipsec-extended-mode.md b/windows/keep-secure/audit-ipsec-extended-mode.md
index 22d1af6a85..89f0857940 100644
--- a/windows/keep-secure/audit-ipsec-extended-mode.md
+++ b/windows/keep-secure/audit-ipsec-extended-mode.md
@@ -5,123 +5,38 @@ ms.assetid: 2b4fee9e-482a-4181-88a8-6a79d8fc8049
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit IPsec Extended Mode
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the advanced security audit policy setting, **Audit IPsec Extended Mode**, which determines whether the operating system generates audit events for the results of the Internet Key Exchange (IKE) protocol and Authenticated Internet Protocol (AuthIP) during Extended Mode negotiations.
IKE is an Internet standard, defined in RFC 2409, that defines a mechanism to establish IPsec security associations (SAs). An SA is a combination of a mutually agreeable policy and keys that define the security services and mechanisms that help protect communication between IPsec peers.
-AuthIP is an enhanced version of IKE that offers additional flexibility with support for user-based authentication, authentication with multiple credentials, improved authentication method negotiation, and asymmetric authentication. Like IKE, AuthIP supports main-mode and quick-mode negotiation. AuthIP also supports Extended Mode, a part of IPsec peer negotiation during which a second round of authentication can be performed. Extended Mode, which is optional, can be used for multiple authentications. For example, with extended mode you can perform separate computer-based and user-based authentications.
+AuthIP is an enhanced version of IKE that offers additional flexibility with support for user-based authentication, authentication with multiple credentials, improved authentication method negotiation, and asymmetric authentication. Like IKE, AuthIP supports main-mode and quick-mode negotiation.
+AuthIP also supports Extended Mode, a part of IPsec peer negotiation during which a second round of authentication can be performed. Extended Mode, which is optional, can be used for multiple authentications. For example, with extended mode you can perform separate computer-based and user-based authentications.
Event volume: High
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4978 |
-During Extended Mode negotiation, IPsec received an invalid negotiation packet. If this problem persists, it could indicate a network issue or an attempt to modify or replay this negotiation. |
-
-
-4979 |
-IPsec Main Mode and Extended Mode security associations were established.
-
- Note
- This event provides event data in the following categories: Main Mode Local Endpoint, Main Mode Remote Endpoint, Main Mode Cryptographic Information, Main Mode Security Association, Main Mode Additional Information, and Extended Mode Information.
-
+| Event ID | Event message |
+| - | - |
+| 4978 | During Extended Mode negotiation, IPsec received an invalid negotiation packet. If this problem persists, it could indicate a network issue or an attempt to modify or replay this negotiation. |
+| 4979 | IPsec Main Mode and Extended Mode security associations were established.
**Note:** This event provides event data in the following categories: Main Mode Local Endpoint, Main Mode Remote Endpoint, Main Mode Cryptographic Information, Main Mode Security Association, Main Mode Additional Information, and Extended Mode Information. |
+| 4980 | IPsec Main Mode and Extended Mode security associations were established.
**Note:** This event provides event audit data in the following categories: Main Mode Local Endpoint, Main Mode Remote Endpoint. Main Mode Cryptographic Information, Main Mode Security Association, Main Mode Additional Information, Extended Mode Local Endpoint, Extended Mode Remote Endpoint, and Extended Mode Additional Information: |
+| 4981 | IPsec Main Mode and Extended Mode security associations were established.
**Note:** This event provides event audit data in the following categories: Local Endpoint, Local Certificate, Remote Endpoint, Remote Certificate, Cryptographic Information, Security Association Information, Additional Information, and Extended Mode Information. |
+| 4982 | IPsec Main Mode and Extended Mode security associations were established.
**Note:** This event provides event audit data in the following categories: Local Endpoint, Local Certificate, Remote Endpoint, Remote Certificate, Cryptographic Information, Security Association Information, Additional Information, Extended Mode Local Endpoint, Extended Mode Remote Endpoint, and Extended Mode Additional Information. |
+| 4983 | An IPsec Extended Mode negotiation failed. The corresponding Main Mode security association has been deleted.
**Note:** This event provides event audit data in the following categories: Local Endpoint, Local Certificate, Remote Endpoint, Remote Certificate, and Failure Information. |
+| 4984 | An IPsec Extended Mode negotiation failed. The corresponding Main Mode security association has been deleted.
**Note:** This event provides event audit data in the following categories: Local Endpoint, Remote Endpoint, Additional Information, and Failure Information. |
- |
-
-
-4980 |
-IPsec Main Mode and Extended Mode security associations were established.
-
- Note
- This event provides event audit data in the following categories: Main Mode Local Endpoint, Main Mode Remote Endpoint. Main Mode Cryptographic Information, Main Mode Security Association, Main Mode Additional Information, Extended Mode Local Endpoint, Extended Mode Remote Endpoint, and Extended Mode Additional Information:
-
-
- |
-
-
-4981 |
-IPsec Main Mode and Extended Mode security associations were established.
-
- Note
- This event provides event audit data in the following categories: Local Endpoint, Local Certificate, Remote Endpoint, Remote Certificate, Cryptographic Information, Security Association Information, Additional Information, and Extended Mode Information.
-
-
- |
-
-
-4982 |
-IPsec Main Mode and Extended Mode security associations were established.
-
- Note
- This event provides event audit data in the following categories: Local Endpoint, Local Certificate, Remote Endpoint, Remote Certificate, Cryptographic Information, Security Association Information, Additional Information, Extended Mode Local Endpoint, Extended Mode Remote Endpoint, and Extended Mode Additional Information.
-
-
- |
-
-
-4983 |
-An IPsec Extended Mode negotiation failed. The corresponding Main Mode security association has been deleted.
-
- Note
- This event provides event audit data in the following categories: Local Endpoint, Local Certificate, Remote Endpoint, Remote Certificate, and Failure Information.
-
-
- |
-
-
-4984 |
-An IPsec Extended Mode negotiation failed. The corresponding Main Mode security association has been deleted.
-
- Note
- This event provides event audit data in the following categories: Local Endpoint, Remote Endpoint, Additional Information, and Failure Information.
-
-
- |
-
-
-
-
-
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-ipsec-main-mode.md b/windows/keep-secure/audit-ipsec-main-mode.md
index fb2d8b42d3..203307a841 100644
--- a/windows/keep-secure/audit-ipsec-main-mode.md
+++ b/windows/keep-secure/audit-ipsec-main-mode.md
@@ -5,105 +5,39 @@ ms.assetid: 06ed26ec-3620-4ef4-a47a-c70df9c8827b
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit IPsec Main Mode
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the advanced security audit policy setting, **Audit IPsec Main Mode**, which determines whether the operating system generates events for the results of the Internet Key Exchange (IKE) protocol and Authenticated Internet Protocol (AuthIP) during Main Mode negotiations.
IKE is an Internet standard, defined in RFC 2409, that defines a mechanism to establish IPsec security associations (SAs). An SA is a combination of a mutually agreeable policy and keys that define the security services and mechanisms that help protect communication between IPsec peers.
-
AuthIP is an enhanced version of IKE that offers additional flexibility with support for user-based authentication, authentication with multiple credentials, improved authentication method negotiation, and asymmetric authentication. Like IKE, AuthIP supports Main Mode and Quick Mode negotiation.
-
Main Mode Internet Key Exchange (IKE) negotiation establishes a secure channel, known as the Internet Security Association and Key Management Protocol (ISAKMP) security association (SA), between two computers. To establish the secure channel, Main Mode negotiation determines a set of cryptographic protection suites, exchanges keying material to establish the shared secret key, and authenticates computer identities.
Event volume: High
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4646 |
-Security ID: %1 |
-
-
-4650 |
-An IPsec Main Mode security association was established. Extended Mode was not enabled. Certificate authentication was not used. |
-
-
-4651 |
-An IPsec Main Mode security association was established. Extended Mode was not enabled. A certificate was used for authentication. |
-
-
-4652 |
-An IPsec Main Mode negotiation failed.
-
- Note
- This audit event returns detailed audit data in the following categories: Local Endpoint, Local Certificate, Remote Endpoint, Remote Certificate, Additional Information, and Failure Information.
-
+| Event ID | Event message |
+| - | - |
+| 4646 | Security ID: %1 |
+| 4650 | An IPsec Main Mode security association was established. Extended Mode was not enabled. Certificate authentication was not used. |
+| 4651 | An IPsec Main Mode security association was established. Extended Mode was not enabled. A certificate was used for authentication. |
+| 4652 | An IPsec Main Mode negotiation failed.
**Note:** This audit event returns detailed audit data in the following categories: Local Endpoint, Local Certificate, Remote Endpoint, Remote Certificate, Additional Information, and Failure Information. |
+| 4653 | An IPsec Main Mode negotiation failed.
**Note:** This audit event returns detailed audit data in the following categories: Local Endpoint, Remote Endpoint, Additional Information, and Failure Information. |
+| 4655 | An IPsec Main Mode security association ended. |
+| 4976 | During Main Mode negotiation, IPsec received an invalid negotiation packet. If this problem persists, it could indicate a network issue or an attempt to modify or replay this negotiation. |
+| 5049 | An IPsec Security Association was deleted. |
+| 5453 | An IPsec negotiation with a remote computer failed because the IKE and AuthIP IPsec Keying Modules (IKEEXT) service is not started. |
- |
-
-
-4653 |
-An IPsec Main Mode negotiation failed.
-
- Note
- This audit event returns detailed audit data in the following categories: Local Endpoint, Remote Endpoint, Additional Information, and Failure Information.
-
-
- |
-
-
-4655 |
-An IPsec Main Mode security association ended. |
-
-
-4976 |
-During Main Mode negotiation, IPsec received an invalid negotiation packet. If this problem persists, it could indicate a network issue or an attempt to modify or replay this negotiation. |
-
-
-5049 |
-An IPsec Security Association was deleted. |
-
-
-5453 |
-An IPsec negotiation with a remote computer failed because the IKE and AuthIP IPsec Keying Modules (IKEEXT) service is not started. |
-
-
-
-
-
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-ipsec-quick-mode.md b/windows/keep-secure/audit-ipsec-quick-mode.md
index dbbd645b9e..79de06ad17 100644
--- a/windows/keep-secure/audit-ipsec-quick-mode.md
+++ b/windows/keep-secure/audit-ipsec-quick-mode.md
@@ -5,67 +5,33 @@ ms.assetid: 7be67a15-c2ce-496a-9719-e25ac7699114
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit IPsec Quick Mode
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the advanced security audit policy setting, **Audit IPsec Quick Mode**, which determines whether the operating system generates audit events for the results of the Internet Key Exchange (IKE) protocol and Authenticated Internet Protocol (AuthIP) during Quick Mode negotiations.
IKE is an Internet standard, defined in RFC 2409, that defines a mechanism to establish IPsec security associations (SAs). An SA is a combination of a mutually agreeable policy and keys that define the security services and mechanisms that help protect communication between IPsec peers.
-
AuthIP is an enhanced version of IKE that offers additional flexibility with support for user-based authentication, authentication with multiple credentials, improved authentication method negotiation, and asymmetric authentication. Like IKE, AuthIP supports Main Mode and Quick Mode negotiation.
-
Quick Mode (also known as Phase 2) IKE negotiation establishes a secure channel between two computers to protect data. Because this phase involves the establishment of security associations (SAs) that are negotiated on behalf of the IPsec service, the SAs that are created during Quick Mode are called the IPsec SAs. During Quick Mode, keying material is refreshed or, if necessary, new keys are generated. A protection suite that protects specified IP traffic is also selected. A protection suite is a defined set of data integrity or data encryption settings. Quick Mode is not considered a complete exchange because it is dependent on a Main Mode exchange.
Event volume: High
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4977 |
-During Quick Mode negotiation, IPsec received an invalid negotiation packet. If this problem persists, it could indicate a network issue or an attempt to modify or replay this negotiation. |
-
-
-5451 |
-An IPsec Quick Mode security association was established. |
-
-
-5452 |
-An IPsec Quick Mode security association ended. |
-
-
-
-
+| Event ID | Event message |
+|- |- |
+| 4977 | During Quick Mode negotiation, IPsec received an invalid negotiation packet. If this problem persists, it could indicate a network issue or an attempt to modify or replay this negotiation.|
+| 5451 | An IPsec Quick Mode security association was established.|
+| 5452 | An IPsec Quick Mode security association ended.|
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-kerberos-authentication-service.md b/windows/keep-secure/audit-kerberos-authentication-service.md
index aaa0076939..85498b7404 100644
--- a/windows/keep-secure/audit-kerberos-authentication-service.md
+++ b/windows/keep-secure/audit-kerberos-authentication-service.md
@@ -5,14 +5,13 @@ ms.assetid: 990dd6d9-1a1f-4cce-97ba-5d7e0a7db859
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Kerberos Authentication Service
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
@@ -24,45 +23,14 @@ Event volume: High on Kerberos Key Distribution Center servers
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4768 |
-A Kerberos authentication ticket (TGT) was requested. |
-
-
-4771 |
-Kerberos preauthentication failed. |
-
-
-4772 |
-A Kerberos authentication ticket request failed. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4768 | A Kerberos authentication ticket (TGT) was requested. |
+| 4771 | Kerberos preauthentication failed. |
+| 4772 | A Kerberos authentication ticket request failed. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-kerberos-service-ticket-operations.md b/windows/keep-secure/audit-kerberos-service-ticket-operations.md
index ccd1d1a83b..5f00cf260a 100644
--- a/windows/keep-secure/audit-kerberos-service-ticket-operations.md
+++ b/windows/keep-secure/audit-kerberos-service-ticket-operations.md
@@ -5,14 +5,13 @@ ms.assetid: ddc0abef-ac7f-4849-b90d-66700470ccd6
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Kerberos Service Ticket Operations
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
@@ -23,46 +22,17 @@ Events are generated every time Kerberos is used to authenticate a user who want
Event volume:
- High on a domain controller that is in a Key Distribution Center (KDC)
-
- Low on domain members
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4769 |
-A Kerberos service ticket was requested. |
-
-
-4770 |
-A Kerberos service ticket was renewed. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4769 | A Kerberos service ticket was requested. |
+| 4770 | A Kerberos service ticket was renewed. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-kernel-object.md b/windows/keep-secure/audit-kernel-object.md
index 8eec2824ea..783f4c3e18 100644
--- a/windows/keep-secure/audit-kernel-object.md
+++ b/windows/keep-secure/audit-kernel-object.md
@@ -5,14 +5,13 @@ ms.assetid: 75619d8b-b1eb-445b-afc9-0f9053be97fb
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Kernel Object
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
@@ -22,58 +21,21 @@ Only kernel objects with a matching system access control list (SACL) generate s
Typically, kernel objects are given SACLs only if the **AuditBaseObjects** or **AuditBaseDirectories** auditing options are enabled.
-**Note**
-The **Audit: Audit the access of global system objects** policy setting controls the default SACL of kernel objects.
-
+> **Note:** The **Audit: Audit the access of global system objects** policy setting controls the default SACL of kernel objects.
-
Event volume: High if you have enabled one of the Global Object Access Auditing settings
Default setting: Not configured
-
-
-
-
-
-
-
-
-
-
-4659 |
-A handle to an object was requested with intent to delete. |
-
-
-4660 |
-An object was deleted. |
-
-
-4661 |
-A handle to an object was requested. |
-
-
-4663 |
-An attempt was made to access an object. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4659 | A handle to an object was requested with intent to delete. |
+| 4660 | An object was deleted. |
+| 4661 | A handle to an object was requested. |
+| 4663 | An attempt was made to access an object. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-logoff.md b/windows/keep-secure/audit-logoff.md
index fca6ed6c10..05aee8928a 100644
--- a/windows/keep-secure/audit-logoff.md
+++ b/windows/keep-secure/audit-logoff.md
@@ -5,14 +5,13 @@ ms.assetid: 681e51f2-ba06-46f5-af8c-d9c48d515432
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Logoff
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
@@ -20,52 +19,21 @@ This topic for the IT professional describes the Advanced Security Audit policy
These events occur on the computer that was accessed. In the case of an interactive logon, these events are generated on the computer that was logged on to.
-**Note**
-There is no failure event in this subcategory because failed logoffs (such as when a system abruptly shuts down) do not generate an audit record.
-
+> **Note: ** There is no failure event in this subcategory because failed logoffs (such as when a system abruptly shuts down) do not generate an audit record.
-
Logon events are essential to understanding user activity and detecting potential attacks. Logoff events are not 100 percent reliable. For example, the computer can be turned off without a proper logoff and shutdown; in this case, a logoff event is not generated.
Event volume: Low
Default: Success
-
-
-
-
-
-
-
-
-
-
-4634 |
-An account was logged off. |
-
-
-4647 |
-User initiated logoff. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4634 | An account was logged off. |
+| 4647 | User initiated logoff. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-logon.md b/windows/keep-secure/audit-logon.md
index 581f4860fe..fb98f6691c 100644
--- a/windows/keep-secure/audit-logon.md
+++ b/windows/keep-secure/audit-logon.md
@@ -5,14 +5,13 @@ ms.assetid: ca968d03-7d52-48c4-ba0e-2bcd2937231b
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Logon
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
@@ -23,9 +22,7 @@ These events are related to the creation of logon sessions and occur on the comp
The following events are recorded:
- Logon success and failure.
-
- Logon attempts by using explicit credentials. This event is generated when a process attempts to log on an account by explicitly specifying that account's credentials. This most commonly occurs in batch configurations such as scheduled tasks, or when using the Runas command.
-
- Security identifiers (SIDs) are filtered.
Logon events are essential to tracking user activity and detecting potential attacks.
@@ -34,49 +31,15 @@ Event volume: Low on a client computer; medium on a domain controller or network
Default: Success for client computers; success and failure for servers
-
-
-
-
-
-
-
-
-
-
-4624 |
-An account was successfully logged on. |
-
-
-4625 |
-An account failed to log on. |
-
-
-4648 |
-A logon was attempted using explicit credentials. |
-
-
-4675 |
-SIDs were filtered. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4624 | An account was successfully logged on. |
+| 4625 | An account failed to log on. |
+| 4648 | A logon was attempted using explicit credentials. |
+| 4675 | SIDs were filtered. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-mpssvc-rule-level-policy-change.md b/windows/keep-secure/audit-mpssvc-rule-level-policy-change.md
index f448d5882b..67760b944f 100644
--- a/windows/keep-secure/audit-mpssvc-rule-level-policy-change.md
+++ b/windows/keep-secure/audit-mpssvc-rule-level-policy-change.md
@@ -5,14 +5,13 @@ ms.assetid: 263461b3-c61c-4ec3-9dee-851164845019
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit MPSSVC Rule-Level Policy Change
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the Advanced Security Audit policy setting, **Audit MPSSVC Rule-Level Policy Change**, which determines whether the operating system generates audit events when changes are made to policy rules for the Microsoft Protection Service (MPSSVC.exe).
@@ -20,15 +19,10 @@ This topic for the IT professional describes the Advanced Security Audit policy
The Microsoft Protection Service, which is used by Windows Firewall, is an integral part of the computer’s threat protection against malware. The tracked activities include:
- Active policies when the Windows Firewall service starts.
-
- Changes to Windows Firewall rules.
-
- Changes to the Windows Firewall exception list.
-
- Changes to Windows Firewall settings.
-
- Rules ignored or not applied by the Windows Firewall service.
-
- Changes to Windows Firewall Group Policy settings.
Changes to firewall rules are important for understanding the security state of the computer and how well it is protected against network attacks.
@@ -37,89 +31,25 @@ Event volume: Low
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4944 |
-The following policy was active when the Windows Firewall started. |
-
-
-4945 |
-A rule was listed when the Windows Firewall started. |
-
-
-4946 |
-A change has been made to Windows Firewall exception list. A rule was added. |
-
-
-4947 |
-A change has been made to Windows Firewall exception list. A rule was modified. |
-
-
-4948 |
-A change has been made to Windows Firewall exception list. A rule was deleted. |
-
-
-4949 |
-Windows Firewall settings were restored to the default values. |
-
-
-4950 |
-A Windows Firewall setting has changed. |
-
-
-4951 |
-A rule has been ignored because its major version number was not recognized by Windows Firewall. |
-
-
-4952 |
-Parts of a rule have been ignored because its minor version number was not recognized by Windows Firewall. The other parts of the rule will be enforced. |
-
-
-4953 |
-A rule has been ignored by Windows Firewall because it could not parse the rule. |
-
-
-4954 |
-Windows Firewall Group Policy settings have changed. The new settings have been applied. |
-
-
-4956 |
-Windows Firewall has changed the active profile. |
-
-
-4957 |
-Windows Firewall did not apply the following rule: |
-
-
-4958 |
-Windows Firewall did not apply the following rule because the rule referred to items not configured on this computer: |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4944 | The following policy was active when the Windows Firewall started. |
+| 4945 | A rule was listed when the Windows Firewall started. |
+| 4946 | A change has been made to Windows Firewall exception list. A rule was added. |
+| 4947 | A change has been made to Windows Firewall exception list. A rule was modified. |
+| 4948 | A change has been made to Windows Firewall exception list. A rule was deleted. |
+| 4949 | Windows Firewall settings were restored to the default values. |
+| 4950 | A Windows Firewall setting has changed. |
+| 4951 | A rule has been ignored because its major version number was not recognized by Windows Firewall. |
+| 4952 | Parts of a rule have been ignored because its minor version number was not recognized by Windows Firewall. The other parts of the rule will be enforced. |
+| 4953 | A rule has been ignored by Windows Firewall because it could not parse the rule. |
+| 4954 | Windows Firewall Group Policy settings have changed. The new settings have been applied. |
+| 4956 | Windows Firewall has changed the active profile. |
+| 4957 | Windows Firewall did not apply the following rule: |
+| 4958 | Windows Firewall did not apply the following rule because the rule referred to items not configured on this computer: |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-network-policy-server.md b/windows/keep-secure/audit-network-policy-server.md
index 0901a69905..5f060ff57e 100644
--- a/windows/keep-secure/audit-network-policy-server.md
+++ b/windows/keep-secure/audit-network-policy-server.md
@@ -5,14 +5,13 @@ ms.assetid: 43b2aea4-26df-46da-b761-2b30f51a80f7
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Network Policy Server
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the Advanced Security Audit policy setting, **Audit Network Policy Server**, which determines whether the operating system generates audit events for RADIUS (IAS) and Network Access Protection (NAP) activity on user access requests (Grant, Deny, Discard, Quarantine, Lock, and Unlock).
@@ -23,69 +22,20 @@ Event volume: Medium to high on servers that are running Network Policy Server (
Default: Success and failure
-
-
-
-
-
-
-
-
-
-
-6272 |
-Network Policy Server granted access to a user. |
-
-
-6273 |
-Network Policy Server denied access to a user. |
-
-
-6274 |
-Network Policy Server discarded the request for a user. |
-
-
-6275 |
-Network Policy Server discarded the accounting request for a user. |
-
-
-6276 |
-Network Policy Server quarantined a user. |
-
-
-6277 |
-Network Policy Server granted access to a user but put it on probation because the host did not meet the defined health policy. |
-
-
-6278 |
-Network Policy Server granted full access to a user because the host met the defined health policy. |
-
-
-6279 |
-Network Policy Server locked the user account due to repeated failed authentication attempts. |
-
-
-6280 |
-Network Policy Server unlocked the user account. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 6272 | Network Policy Server granted access to a user. |
+| 6273 | Network Policy Server denied access to a user. |
+| 6274 | Network Policy Server discarded the request for a user. |
+| 6275 | Network Policy Server discarded the accounting request for a user. |
+| 6276 | Network Policy Server quarantined a user. |
+| 6277 | Network Policy Server granted access to a user but put it on probation because the host did not meet the defined health policy. |
+| 6278 | Network Policy Server granted full access to a user because the host met the defined health policy. |
+| 6279 | Network Policy Server locked the user account due to repeated failed authentication attempts. |
+| 6280 | Network Policy Server unlocked the user account. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-non-sensitive-privilege-use.md b/windows/keep-secure/audit-non-sensitive-privilege-use.md
index ac2879b686..e1321ebc6a 100644
--- a/windows/keep-secure/audit-non-sensitive-privilege-use.md
+++ b/windows/keep-secure/audit-non-sensitive-privilege-use.md
@@ -5,14 +5,13 @@ ms.assetid: 8fd74783-1059-443e-aa86-566d78606627
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Non-Sensitive Privilege Use
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the Advanced Security Audit policy setting, **Audit Non-Sensitive Privilege Use**, which determines whether the operating system generates audit events when non-sensitive privileges (user rights) are used.
@@ -20,63 +19,34 @@ This topic for the IT professional describes the Advanced Security Audit policy
The following privileges are non-sensitive:
- **Access Credential Manager as a trusted caller**
-
- **Access this computer from the network**
-
- **Add workstations to domain**
-
- **Adjust memory quotas for a process**
-
- **Allow log on locally**
-
- **Allow log on through Terminal Services**
-
- **Bypass traverse checking**
-
- **Change the system time**
-
- **Create a page file**
-
- **Create global objects**
-
- **Create permanent shared objects**
-
- **Create symbolic links**
-
- **Deny access to this computer from the network**
-
- **Deny log on as a batch job**
-
- **Deny log on as a service**
-
- **Deny log on locally**
-
- **Deny log on through Terminal Services**
-
- **Force shutdown from a remote system**
-
- **Increase a process working set**
-
- **Increase scheduling priority**
-
- **Lock pages in memory**
-
- **Log on as a batch job**
-
- **Log on as a service**
-
- **Modify an object label**
-
- **Perform volume maintenance tasks**
-
- **Profile single process**
-
- **Profile system performance**
-
- **Remove computer from docking station**
-
- **Shut down the system**
-
- **Synchronize directory service data**
If you configure this policy setting, an audit event is generated when a non-sensitive privilege is called. Success audits record successful attempts, and failure audits record unsuccessful attempts.
@@ -85,45 +55,14 @@ Event volume: Very high
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4672 |
-Special privileges assigned to new logon. |
-
-
-4673 |
-A privileged service was called. |
-
-
-4674 |
-An operation was attempted on a privileged object. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4672 | Special privileges assigned to new logon. |
+| 4673 | A privileged service was called. |
+| 4674 | An operation was attempted on a privileged object. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-other-account-logon-events.md b/windows/keep-secure/audit-other-account-logon-events.md
index 36d1c35cf5..57eaa771fa 100644
--- a/windows/keep-secure/audit-other-account-logon-events.md
+++ b/windows/keep-secure/audit-other-account-logon-events.md
@@ -5,14 +5,13 @@ ms.assetid: c8c6bfe0-33d2-4600-bb1a-6afa840d75b3
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Other Account Logon Events
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the advanced security audit policy setting, **Audit Other Account Logon Events**, which allows you to audit events generated by responses to credential requests submitted for a user account logon that are not credential validation or Kerberos tickets.
@@ -20,97 +19,36 @@ This topic for the IT professional describes the advanced security audit policy
Examples can include the following:
- Remote Desktop session disconnections
-
- New Remote Desktop sessions
-
- Locking and unlocking a workstation
-
- Invoking a screen saver
-
- Dismissing a screen saver
-
- Detection of a Kerberos replay attack, in which a Kerberos request with identical information was received twice
- **Note**
- This condition could be caused by a network misconfiguration.
-
+ > **Note:** This condition could be caused by a network misconfiguration.
-
- Access to a wireless network granted to a user or computer account
-
- Access to a wired 802.1x network granted to a user or computer account
Event volume: Varies, depending on system use
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4649 |
-A replay attack was detected. |
-
-
-4778 |
-A session was reconnected to a Window Station. |
-
-
-4779 |
-A session was disconnected from a Window Station. |
-
-
-4800 |
-The workstation was locked. |
-
-
-4801 |
-The workstation was unlocked. |
-
-
-4802 |
-The screen saver was invoked. |
-
-
-4803 |
-The screen saver was dismissed. |
-
-
-5378 |
-The requested credentials delegation was disallowed by policy. |
-
-
-5632 |
-A request was made to authenticate to a wireless network. |
-
-
-5633 |
-A request was made to authenticate to a wired network. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4649 | A replay attack was detected. |
+| 4778 | A session was reconnected to a Window Station. |
+| 4779 | A session was disconnected from a Window Station. |
+| 4800 | The workstation was locked. |
+| 4801 | The workstation was unlocked. |
+| 4802 | The screen saver was invoked. |
+| 4803 | The screen saver was dismissed. |
+| 5378 | The requested credentials delegation was disallowed by policy. |
+| 5632 | A request was made to authenticate to a wireless network. |
+| 5633 | A request was made to authenticate to a wired network. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-other-account-management-events.md b/windows/keep-secure/audit-other-account-management-events.md
index 78a7da62bd..737c91e478 100644
--- a/windows/keep-secure/audit-other-account-management-events.md
+++ b/windows/keep-secure/audit-other-account-management-events.md
@@ -5,14 +5,13 @@ ms.assetid: 4ce22eeb-a96f-4cf9-a46d-6642961a31d5
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Other Account Management Events
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the Advanced Security Audit policy setting, **Audit Other Account Management Events**, which determines whether the operating system generates user account management audit events.
@@ -20,55 +19,21 @@ This topic for the IT professional describes the Advanced Security Audit policy
Events can be generated for user account management auditing when:
- The password hash of an account is accessed. This typically happens when the Active Directory Migration Tool (ADMT) is moving password data.
-
- The Password Policy Checking application programming interface (API) is called. Calls to this function could be part of an attack from a malicious application that is testing whether password complexity policy settings are being applied.
-
- Changes are made to domain policy under **Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Password Policy** or **Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Account Lockout Policy**.
-
-**Note**
-These events are logged when the domain policy is applied (on refresh or restart), not when settings are modified by an administrator.
-
+> **Note:** These events are logged when the domain policy is applied (on refresh or restart), not when settings are modified by an administrator.
-
Event volume: Low
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4782 |
-The password hash for an account was accessed. |
-
-
-4793 |
-The Password Policy Checking API was called. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4782 | The password hash for an account was accessed. |
+| 4793 | The Password Policy Checking API was called. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-other-logonlogoff-events.md b/windows/keep-secure/audit-other-logonlogoff-events.md
index c38d1fcc1a..14b371601d 100644
--- a/windows/keep-secure/audit-other-logonlogoff-events.md
+++ b/windows/keep-secure/audit-other-logonlogoff-events.md
@@ -5,14 +5,13 @@ ms.assetid: 76d987cd-1917-4907-a739-dd642609a458
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Other Logon/Logoff Events
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the Advanced Security Audit policy setting, **Audit Other Logon/Logoff Events**, which determines whether Windows generates audit events for other logon or logoff events.
@@ -20,15 +19,10 @@ This topic for the IT professional describes the Advanced Security Audit policy
These other logon or logoff events include:
- A Remote Desktop session connects or disconnects.
-
- A workstation is locked or unlocked.
-
- A screen saver is invoked or dismissed.
-
- A replay attack is detected. This event indicates that a Kerberos request was received twice with identical information. This condition could also be caused by network misconfiguration.
-
- A user is granted access to a wireless network. It can either be a user account or the computer account.
-
- A user is granted access to a wired 802.1x network. It can either be a user account or the computer account.
Logon events are essential to understanding user activity and detecting potential attacks.
@@ -37,73 +31,21 @@ Event volume: Low
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4649 |
-A replay attack was detected. |
-
-
-4778 |
-A session was reconnected to a Window Station. |
-
-
-4779 |
-A session was disconnected from a Window Station. |
-
-
-4800 |
-The workstation was locked. |
-
-
-4801 |
-The workstation was unlocked. |
-
-
-4802 |
-The screen saver was invoked. |
-
-
-4803 |
-The screen saver was dismissed. |
-
-
-5378 |
-The requested credentials delegation was disallowed by policy. |
-
-
-5632 |
-A request was made to authenticate to a wireless network. |
-
-
-5633 |
-A request was made to authenticate to a wired network. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4649 | A replay attack was detected. |
+| 4778 | A session was reconnected to a Window Station. |
+| 4779 | A session was disconnected from a Window Station. |
+| 4800 | The workstation was locked. |
+| 4801 | The workstation was unlocked. |
+| 4802 | The screen saver was invoked. |
+| 4803 | The screen saver was dismissed. |
+| 5378 | The requested credentials delegation was disallowed by policy. |
+| 5632 | A request was made to authenticate to a wireless network. |
+| 5633 | A request was made to authenticate to a wired network. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-other-object-access-events.md b/windows/keep-secure/audit-other-object-access-events.md
index 4998656c13..71b1ee1965 100644
--- a/windows/keep-secure/audit-other-object-access-events.md
+++ b/windows/keep-secure/audit-other-object-access-events.md
@@ -5,14 +5,13 @@ ms.assetid: b9774595-595d-4199-b0c5-8dbc12b6c8b2
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Other Object Access Events
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the Advanced Security Audit policy setting, **Audit Other Object Access Events**, which determines whether the operating system generates audit events for the management of Task Scheduler jobs or COM+ objects.
@@ -20,102 +19,38 @@ This topic for the IT professional describes the Advanced Security Audit policy
For scheduler jobs, the following actions are audited:
- Job created.
-
- Job deleted.
-
- Job enabled.
-
- Job disabled.
-
- Job updated.
For COM+ objects, the following actions are audited:
- Catalog object added.
-
- Catalog object updated.
-
- Catalog object deleted.
Event volume: Low
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4671 |
-An application attempted to access a blocked ordinal through the TBS. |
-
-
-4691 |
-Indirect access to an object was requested. |
-
-
-4698 |
-A scheduled task was created. |
-
-
-4699 |
-A scheduled task was deleted. |
-
-
-4700 |
-A scheduled task was enabled. |
-
-
-4701 |
-A scheduled task was disabled. |
-
-
-4702 |
-A scheduled task was updated. |
-
-
-5148 |
-The Windows Filtering Platform has detected a DoS attack and entered a defensive mode; packets associated with this attack will be discarded. |
-
-
-5149 |
-The DoS attack has subsided and normal processing is being resumed. |
-
-
-5888 |
-An object in the COM+ Catalog was modified. |
-
-
-5889 |
-An object was deleted from the COM+ Catalog. |
-
-
-5890 |
-An object was added to the COM+ Catalog. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4671 | An application attempted to access a blocked ordinal through the TBS. |
+| 4691 | Indirect access to an object was requested. |
+| 4698 | A scheduled task was created. |
+| 4699 | A scheduled task was deleted. |
+| 4700 | A scheduled task was enabled. |
+| 4701 | A scheduled task was disabled. |
+| 4702 | A scheduled task was updated. |
+| 5148 | The Windows Filtering Platform has detected a DoS attack and entered a defensive mode; packets associated with this attack will be discarded. |
+| 5149 | The DoS attack has subsided and normal processing is being resumed. |
+| 5888 | An object in the COM+ Catalog was modified. |
+| 5889 | An object was deleted from the COM+ Catalog. |
+| 5890 | An object was added to the COM+ Catalog. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-other-policy-change-events.md b/windows/keep-secure/audit-other-policy-change-events.md
index 33f1800b16..7e2c53404a 100644
--- a/windows/keep-secure/audit-other-policy-change-events.md
+++ b/windows/keep-secure/audit-other-policy-change-events.md
@@ -5,14 +5,13 @@ ms.assetid: 8618502e-c21c-41cc-8a49-3dc1eb359e60
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Other Policy Change Events
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the Advanced Security Audit policy setting, **Audit Other Policy Change Events**, which determines whether the operating system generates audit events for security policy changes that are not otherwise audited in the Policy Change category.
@@ -20,100 +19,33 @@ This topic for the IT professional describes the Advanced Security Audit policy
These other activities in the Policy Change category that can be audited include:
- Trusted Platform Module (TPM) configuration changes.
-
- Kernel-mode cryptographic self tests.
-
- Cryptographic provider operations.
-
- Cryptographic context operations or modifications.
Event volume: Low
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4670 |
-Permissions on an object were changed. |
-
-
-4909 |
-The local policy settings for the TBS were changed. |
-
-
-4910 |
-The group policy settings for the TBS were changed. |
-
-
-5063 |
-A cryptographic provider operation was attempted. |
-
-
-5064 |
-A cryptographic context operation was attempted. |
-
-
-5065 |
-A cryptographic context modification was attempted. |
-
-
-5066 |
-A cryptographic function operation was attempted. |
-
-
-5067 |
-A cryptographic function modification was attempted. |
-
-
-5068 |
-A cryptographic function provider operation was attempted. |
-
-
-5069 |
-A cryptographic function property operation was attempted. |
-
-
-5070 |
-A cryptographic function property modification was attempted. |
-
-
-5447 |
-A Windows Filtering Platform filter has been changed. |
-
-
-6144 |
-Security policy in the group policy objects has been applied successfully. |
-
-
-6145 |
-One or more errors occurred while processing security policy in the group policy objects. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4670 | Permissions on an object were changed. |
+| 4909 | The local policy settings for the TBS were changed. |
+| 4910 | The group policy settings for the TBS were changed. |
+| 5063 | A cryptographic provider operation was attempted. |
+| 5064 | A cryptographic context operation was attempted. |
+| 5065 | A cryptographic context modification was attempted. |
+| 5066 | A cryptographic function operation was attempted. |
+| 5067 | A cryptographic function modification was attempted. |
+| 5068 | A cryptographic function provider operation was attempted. |
+| 5069 | A cryptographic function property operation was attempted. |
+| 5070 | A cryptographic function property modification was attempted. |
+| 5447 | A Windows Filtering Platform filter has been changed. |
+| 6144 | Security policy in the group policy objects has been applied successfully. |
+| 6145 | One or more errors occurred while processing security policy in the group policy objects. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-other-privilege-use-events.md b/windows/keep-secure/audit-other-privilege-use-events.md
index 65b5146b7b..839251f763 100644
--- a/windows/keep-secure/audit-other-privilege-use-events.md
+++ b/windows/keep-secure/audit-other-privilege-use-events.md
@@ -5,28 +5,18 @@ ms.assetid: 5f7f5b25-42a6-499f-8aa2-01ac79a2a63c
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Other Privilege Use Events
-
**Applies to**
-
- Windows 10
This security policy setting is not used.
## Related topics
-
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-other-system-events.md b/windows/keep-secure/audit-other-system-events.md
index 9b5457b2a3..2b28658209 100644
--- a/windows/keep-secure/audit-other-system-events.md
+++ b/windows/keep-secure/audit-other-system-events.md
@@ -5,14 +5,13 @@ ms.assetid: 2401e4cc-d94e-41ec-82a7-e10914295f8b
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Other System Events
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the Advanced Security Audit policy setting, **Audit Other System Events**, which determines whether the operating system audits various system events.
@@ -20,135 +19,42 @@ This topic for the IT professional describes the Advanced Security Audit policy
The system events in this category include:
- Startup and shutdown of the Windows Firewall service and driver.
-
- Security policy processing by the Windows Firewall service.
-
- Cryptography key file and migration operations.
-**Important**
-Failure to start the Windows Firewall service may result in a computer that is not fully protected against network threats.
-
+> **Important:** Failure to start the Windows Firewall service may result in a computer that is not fully protected against network threats.
-
Event volume: Low
Default: Success and failure
-
-
-
-
-
-
-
-
-
-
-5024 |
-The Windows Firewall Service has started successfully. |
-
-
-5025 |
-The Windows Firewall Service has been stopped. |
-
-
-5027 |
-The Windows Firewall Service was unable to retrieve the security policy from the local storage. The service will continue enforcing the current policy. |
-
-
-5028 |
-The Windows Firewall Service was unable to parse the new security policy. The service will continue with currently enforced policy. |
-
-
-5029 |
-The Windows Firewall Service failed to initialize the driver. The service will continue to enforce the current policy. |
-
-
-5030 |
-The Windows Firewall Service failed to start. |
-
-
-5032 |
-Windows Firewall was unable to notify the user that it blocked an application from accepting incoming connections on the network. |
-
-
-5033 |
-The Windows Firewall Driver has started successfully. |
-
-
-5034 |
-The Windows Firewall Driver has been stopped. |
-
-
-5035 |
-The Windows Firewall Driver failed to start. |
-
-
-5037 |
-The Windows Firewall Driver detected critical runtime error. Terminating. |
-
-
-5058 |
-Key file operation. |
-
-
-5059 |
-Key migration operation. |
-
-
-6400 |
-BranchCache: Received an incorrectly formatted response while discovering availability of content. |
-
-
-6401 |
-BranchCache: Received invalid data from a peer. Data discarded. |
-
-
-6402 |
-BranchCache: The message to the hosted cache offering it data is incorrectly formatted. |
-
-
-6403 |
-BranchCache: The hosted cache sent an incorrectly formatted response to the client. |
-
-
-6404 |
-BranchCache: Hosted cache could not be authenticated using the provisioned SSL certificate. |
-
-
-6405 |
-BranchCache: %2 instance(s) of event id %1 occurred. |
-
-
-6406 |
-%1 registered to Windows Firewall to control filtering for the following: %2 |
-
-
-6407 |
-1% |
-
-
-6408 |
-Registered product %1 failed and Windows Firewall is now controlling the filtering for %2 |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 5024 | The Windows Firewall Service has started successfully. |
+| 5025 | The Windows Firewall Service has been stopped. |
+| 5027 | The Windows Firewall Service was unable to retrieve the security policy from the local storage. The service will continue enforcing the current policy. |
+| 5028 | The Windows Firewall Service was unable to parse the new security policy. The service will continue with currently enforced policy. |
+| 5029 | The Windows Firewall Service failed to initialize the driver. The service will continue to enforce the current policy. |
+| 5030 | The Windows Firewall Service failed to start. |
+| 5032 | Windows Firewall was unable to notify the user that it blocked an application from accepting incoming connections on the network.|
+| 5033 | The Windows Firewall Driver has started successfully. |
+| 5034 | The Windows Firewall Driver has been stopped. |
+| 5035 | The Windows Firewall Driver failed to start. |
+| 5037 | The Windows Firewall Driver detected critical runtime error. Terminating.|
+| 5058 | Key file operation. |
+| 5059 | Key migration operation.|
+| 6400 | BranchCache: Received an incorrectly formatted response while discovering availability of content.|
+| 6401 | BranchCache: Received invalid data from a peer. Data discarded. |
+| 6402 | BranchCache: The message to the hosted cache offering it data is incorrectly formatted.|
+| 6403 | BranchCache: The hosted cache sent an incorrectly formatted response to the client. |
+| 6404 | BranchCache: Hosted cache could not be authenticated using the provisioned SSL certificate.|
+| 6405 | BranchCache: %2 instance(s) of event id %1 occurred. |
+| 6406 | %1 registered to Windows Firewall to control filtering for the following: %2|
+| 6407 | 1% |
+| 6408 | Registered product %1 failed and Windows Firewall is now controlling the filtering for %2 |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-pnp-activity.md b/windows/keep-secure/audit-pnp-activity.md
index e278b54ff1..aef1c0ae47 100644
--- a/windows/keep-secure/audit-pnp-activity.md
+++ b/windows/keep-secure/audit-pnp-activity.md
@@ -5,18 +5,15 @@ ms.assetid: A3D87B3B-EBBE-442A-953B-9EB75A5F600E
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit PNP Activity
-
**Applies to**
-
- Windows 10
-\[Some information relates to pre-released product, which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.\]
-
This topic for the IT professional describes the advanced security audit policy setting, **Audit PNP Activity**, which determines when plug and play detects an external device.
A PnP audit event can be used to track down changes in system hardware and will be logged on the machine where the change took place. For example, when a keyboard is plugged into a PC a PnP event is triggered.
@@ -25,37 +22,12 @@ Event volume: Varies, depending on how the computer is used
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-6416 |
-A new external device was recognized by the system. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 6416 | A new external device was recognized by the system. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-policy.md b/windows/keep-secure/audit-policy.md
index c955e349c7..87cf555f43 100644
--- a/windows/keep-secure/audit-policy.md
+++ b/windows/keep-secure/audit-policy.md
@@ -5,14 +5,13 @@ ms.assetid: 2e8ea400-e555-43e5-89d6-0898cb89da90
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Policy
-
**Applies to**
-
- Windows 10
Provides information about basic audit policies that are available in Windows and links to information about each setting.
@@ -20,37 +19,19 @@ Provides information about basic audit policies that are available in Windows an
The security audit policy settings under **Security Settings\\Local Policies\\Audit Policy** provide broad security audit capabilities for client devices and servers that cannot use advanced security audit policy settings.
The basic audit policy settings under **Security Settings\\Local Policies\\Audit Policy** are:
-
-[Audit account logon events](basic-audit-account-logon-events.md)
-
-[Audit account management](basic-audit-account-management.md)
-
-[Audit directory service access](basic-audit-directory-service-access.md)
-
-[Audit logon events](basic-audit-logon-events.md)
-
-[Audit object access](basic-audit-object-access.md)
-
-[Audit policy change](basic-audit-policy-change.md)
-
-[Audit privilege use](basic-audit-privilege-use.md)
-
-[Audit process tracking](basic-audit-process-tracking.md)
-
-[Audit system events](basic-audit-system-events.md)
+- [Audit account logon events](basic-audit-account-logon-events.md)
+- [Audit account management](basic-audit-account-management.md)
+- [Audit directory service access](basic-audit-directory-service-access.md)
+- [Audit logon events](basic-audit-logon-events.md)
+- [Audit object access](basic-audit-object-access.md)
+- [Audit policy change](basic-audit-policy-change.md)
+- [Audit privilege use](basic-audit-privilege-use.md)
+- [Audit process tracking](basic-audit-process-tracking.md)
+- [Audit system events](basic-audit-system-events.md)
## Related topics
-
-[Configure security policy settings](how-to-configure-security-policy-settings.md)
-
-[Security auditing](security-auditing-overview.md)
-
+- [Configure security policy settings](how-to-configure-security-policy-settings.md)
+- [Security auditing](security-auditing-overview.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-process-creation.md b/windows/keep-secure/audit-process-creation.md
index 217836dc17..dbe4b6bc69 100644
--- a/windows/keep-secure/audit-process-creation.md
+++ b/windows/keep-secure/audit-process-creation.md
@@ -5,14 +5,13 @@ ms.assetid: 67e39fcd-ded6-45e8-b1b6-d411e4e93019
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Process Creation
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
@@ -24,41 +23,13 @@ Event volume: Low to medium, depending on system usage
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4688 |
-A new process has been created. |
-
-
-4696 |
-A primary token was assigned to a process. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4688 | A new process has been created.|
+| 4696 | A primary token was assigned to a process.|
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-process-termination.md b/windows/keep-secure/audit-process-termination.md
index ac362e72be..4208a938c3 100644
--- a/windows/keep-secure/audit-process-termination.md
+++ b/windows/keep-secure/audit-process-termination.md
@@ -5,14 +5,13 @@ ms.assetid: 65d88e53-14aa-48a4-812b-557cebbf9e50
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Process Termination
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
@@ -28,37 +27,12 @@ Event volume: Varies, depending on how the computer is used
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4689 |
-A process has exited. |
-
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4689 | A process has exited. |
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-registry.md b/windows/keep-secure/audit-registry.md
index f8c60d1b1f..40ea22bf27 100644
--- a/windows/keep-secure/audit-registry.md
+++ b/windows/keep-secure/audit-registry.md
@@ -5,14 +5,13 @@ ms.assetid: 02bcc23b-4823-46ac-b822-67beedf56b32
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Registry
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
@@ -20,47 +19,20 @@ This topic for the IT professional describes the Advanced Security Audit policy
Audit events are generated only for objects that have configured system access control lists (SACLs) specified, and only if the type of access requested (such as Write, Read, or Modify) and the account making the request match the settings in the SACL.
-If success auditing is enabled, an audit entry is generated each time any account successfully accesses a registry object that has a matching SACL. If failure auditing is enabled, an audit entry is generated each time any user unsuccessfully attempts to access a registry object that has a matching SACL.
+If success auditing is enabled, an audit entry is generated each time any account successfully accesses a registry object that has a matching SACL. If failure auditing is enabled, an audit entry is generated each time any user unsuccessfully attempts to access a registry object that has a matching
+SACL.
Event volume: Low to medium, depending on how registry SACLs are configured
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4657 |
-A registry value was modified. |
-
-
-5039 |
-A registry key was virtualized. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4657 | A registry value was modified. |
+| 5039 | A registry key was virtualized. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-removable-storage.md b/windows/keep-secure/audit-removable-storage.md
index 5c9276822b..1892857f3e 100644
--- a/windows/keep-secure/audit-removable-storage.md
+++ b/windows/keep-secure/audit-removable-storage.md
@@ -5,14 +5,13 @@ ms.assetid: 1746F7B3-8B41-4661-87D8-12F734AFFB26
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Removable Storage
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the Advanced Security Audit policy setting, **Audit Removable Storage**, which determines when there is a read or a write to a removable drive.
@@ -122,19 +121,9 @@ Default: Not configured
-
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-rpc-events.md b/windows/keep-secure/audit-rpc-events.md
index de4ec1bad5..dfb512694b 100644
--- a/windows/keep-secure/audit-rpc-events.md
+++ b/windows/keep-secure/audit-rpc-events.md
@@ -5,14 +5,13 @@ ms.assetid: 868aec2d-93b4-4bc8-a150-941f88838ba6
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit RPC Events
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the advanced security audit policy setting, **Audit RPC Events**, which determines whether the operating system generates audit events when inbound remote procedure call (RPC) connections are made.
@@ -23,37 +22,12 @@ Event volume: High on RPC servers
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-5712 |
-A Remote Procedure Call (RPC) was attempted. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 5712 | A Remote Procedure Call (RPC) was attempted. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-sam.md b/windows/keep-secure/audit-sam.md
index 9afb708e33..c682e87a89 100644
--- a/windows/keep-secure/audit-sam.md
+++ b/windows/keep-secure/audit-sam.md
@@ -5,14 +5,13 @@ ms.assetid: 1d00f955-383d-4c95-bbd1-fab4a991a46e
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit SAM
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
@@ -23,76 +22,32 @@ The Security Account Manager (SAM) is a database that is present on computers ru
SAM objects include the following:
- SAM\_ALIAS: A local group
-
- SAM\_GROUP: A group that is not a local group
-
- SAM\_USER: A user account
-
- SAM\_DOMAIN: A domain
-
- SAM\_SERVER: A computer account
If you configure this policy setting, an audit event is generated when a SAM object is accessed. Success audits record successful attempts, and failure audits record unsuccessful attempts.
-**Note**
-Only the SACL for SAM\_SERVER can be modified.
-
+> **Note:** Only the SACL for SAM\_SERVER can be modified.
-
Changes to user and group objects are tracked by the Account Management audit category. However, user accounts with enough privileges could potentially alter the files in which the account and password information is stored in the system, bypassing any Account Management events.
Event volume: High on domain controllers
-**Note**
-For information about reducing the number of events generated in this subcategory, see [KB841001](http://go.microsoft.com/fwlink/p/?LinkId=121698).
-
+> **Note:** For information about reducing the number of events generated in this subcategory, see [KB841001](http://go.microsoft.com/fwlink/p/?LinkId=121698).
-
Default setting: Not configured
-
-
-
-
-
-
-
-
-
-
-4659 |
-A handle to an object was requested with intent to delete. |
-
-
-4660 |
-An object was deleted. |
-
-
-4661 |
-A handle to an object was requested. |
-
-
-4663 |
-An attempt was made to access an object. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4659 | A handle to an object was requested with intent to delete.|
+| 4660 | An object was deleted. |
+| 4661 | A handle to an object was requested.|
+| 4663 | An attempt was made to access an object.|
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-security-group-management.md b/windows/keep-secure/audit-security-group-management.md
index c4112315d8..65d91ba967 100644
--- a/windows/keep-secure/audit-security-group-management.md
+++ b/windows/keep-secure/audit-security-group-management.md
@@ -5,14 +5,13 @@ ms.assetid: ac2ee101-557b-4c84-b9fa-4fb23331f1aa
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Security Group Management
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the advanced security audit policy setting, **Audit Security Group Management**, which determines whether the operating system generates audit events when specific security group management tasks are performed.
@@ -20,108 +19,35 @@ This topic for the IT professional describes the advanced security audit policy
Tasks for security group management include:
- A security group is created, changed, or deleted.
-
- A member is added to or removed from a security group.
-
- A group's type is changed.
-
Security groups can be used for access control permissions and also as distribution lists.
Event volume: Low
Default: Success
-
-
-
-
-
-
-
-
-
-
-4727 |
-A security-enabled global group was created. |
-
-
-4728 |
-A member was added to a security-enabled global group. |
-
-
-4729 |
-A member was removed from a security-enabled global group. |
-
-
-4730 |
-A security-enabled global group was deleted. |
-
-
-4731 |
-A security-enabled local group was created. |
-
-
-4732 |
-A member was added to a security-enabled local group. |
-
-
-4733 |
-A member was removed from a security-enabled local group. |
-
-
-4734 |
-A security-enabled local group was deleted. |
-
-
-4735 |
-A security-enabled local group was changed. |
-
-
-4737 |
-A security-enabled global group was changed. |
-
-
-4754 |
-A security-enabled universal group was created. |
-
-
-4755 |
-A security-enabled universal group was changed. |
-
-
-4756 |
-A member was added to a security-enabled universal group. |
-
-
-4757 |
-A member was removed from a security-enabled universal group. |
-
-
-4758 |
-A security-enabled universal group was deleted. |
-
-
-4764 |
-A group's type was changed. |
-
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4727 | A security-enabled global group was created. |
+| 4728 | A member was added to a security-enabled global group. |
+| 4729 | A member was removed from a security-enabled global group. |
+| 4730 | A security-enabled global group was deleted. |
+| 4731 | A security-enabled local group was created. |
+| 4732 | A member was added to a security-enabled local group.|
+| 4733 | A member was removed from a security-enabled local group.|
+| 4734 | A security-enabled local group was deleted. |
+| 4735 | A security-enabled local group was changed. |
+| 4737 | A security-enabled global group was changed. |
+| 4754 | A security-enabled universal group was created.|
+| 4755 | A security-enabled universal group was changed. |
+| 4756 | A member was added to a security-enabled universal group.|
+| 4757 | A member was removed from a security-enabled universal group.|
+| 4758 | A security-enabled universal group was deleted. |
+| 4764 | A group's type was changed. |
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-security-state-change.md b/windows/keep-secure/audit-security-state-change.md
index f20c08fa77..efda133f49 100644
--- a/windows/keep-secure/audit-security-state-change.md
+++ b/windows/keep-secure/audit-security-state-change.md
@@ -5,14 +5,13 @@ ms.assetid: decb3218-a67d-4efa-afc0-337c79a89a2d
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Security State Change
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
@@ -21,71 +20,26 @@ This topic for the IT professional describes the Advanced Security Audit policy
Changes in the security state of the operating system include:
- System startup and shutdown.
-
- Change of system time.
-
- System recovery from **CrashOnAuditFail**. This event is logged after a system reboots following **CrashOnAuditFail**.
- **Important**
- Some auditable activity may not be recorded when a system restarts due to **CrashOnAuditFail**.
-
+ > **Important:** Some auditable activity may not be recorded when a system restarts due to **CrashOnAuditFail**.
-
System startup and shutdown events are important for understanding system usage.
Event volume: Low
Default: Success
-
-
-
-
-
-
-
-
-
-
-
-4608 |
-Windows is starting up. |
-Windows Vista, Windows Server 2008 |
-
-
-4609 |
-Windows is shutting down. |
-Windows Vista, Windows Server 2008 |
-
-
-4616 |
-The system time was changed. |
-Windows Vista, Windows Server 2008 |
-
-
-4621 |
-Administrator recovered system from CrashOnAuditFail. Users who are not administrators will now be allowed to log on. Some auditable activity might not have been recorded. |
-Windows Vista, Windows Server 2008 |
-
-
-
-
+| Event ID | Event message summary | Minimum requirement |
+| - | - | - |
+| 4608 | Windows is starting up. | Windows Vista, Windows Server 2008 |
+| 4609 | Windows is shutting down. | Windows Vista, Windows Server 2008 |
+| 4616 | The system time was changed.| Windows Vista, Windows Server 2008 |
+| 4621 | Administrator recovered system from CrashOnAuditFail. Users who are not administrators will now be allowed to log on. Some auditable activity might not have been recorded.| Windows Vista, Windows Server 2008 |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-security-system-extension.md b/windows/keep-secure/audit-security-system-extension.md
index ace6274636..e605195736 100644
--- a/windows/keep-secure/audit-security-system-extension.md
+++ b/windows/keep-secure/audit-security-system-extension.md
@@ -5,83 +5,40 @@ ms.assetid: 9f3c6bde-42b2-4a0a-b353-ed3106ebc005
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Security System Extension
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
This topic for the IT professional describes the Advanced Security Audit policy setting, **Audit Security System Extension**, which determines whether the operating system generates audit events related to security system extensions.
Changes to security system extensions in the operating system include the following activities:
-
- A security extension code is loaded (such as an authentication, notification, or security package). A security extension code registers with the Local Security Authority and will be used and trusted to authenticate logon attempts, submit logon requests, and be notified of any account or password changes. Examples of this extension code are Security Support Providers, such as Kerberos and NTLM.
-
- A service is installed. An audit log is generated when a service is registered with the Service Control Manager. The audit log contains information about the service name, binary, type, start type, and service account.
-**Important**
-Attempts to install or load security system extensions or services are critical system events that could indicate a security breach.
-
+> **Important:** Attempts to install or load security system extensions or services are critical system events that could indicate a security breach.
-
Event volume: Low
These events are expected to appear more on a domain controller than on client computers or member servers.
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4610 |
-An authentication package has been loaded by the Local Security Authority. |
-
-
-4611 |
-A trusted logon process has been registered with the Local Security Authority. |
-
-
-4614 |
-A notification package has been loaded by the Security Account Manager. |
-
-
-4622 |
-A security package has been loaded by the Local Security Authority. |
-
-
-4697 |
-A service was installed in the system. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4610 | An authentication package has been loaded by the Local Security Authority. |
+| 4611 | A trusted logon process has been registered with the Local Security Authority.|
+| 4614 | A notification package has been loaded by the Security Account Manager. |
+| 4622 | A security package has been loaded by the Local Security Authority. |
+| 4697 | A service was installed in the system. |
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-sensitive-privilege-use.md b/windows/keep-secure/audit-sensitive-privilege-use.md
index 339007cdc8..2c7cd5a902 100644
--- a/windows/keep-secure/audit-sensitive-privilege-use.md
+++ b/windows/keep-secure/audit-sensitive-privilege-use.md
@@ -5,49 +5,33 @@ ms.assetid: 915abf50-42d2-45f6-9fd1-e7bd201b193d
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Sensitive Privilege Use
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the Advanced Security Audit policy setting, **Audit Sensitive Privilege Use**, which determines whether the operating system generates audit events when sensitive privileges (user rights) are used.
Actions that can be audited include:
-
- A privileged service is called.
-
- One of the following privileges is called:
-
- **Act as part of the operating system**
-
- **Back up files and directories**
-
- **Create a token object**
-
- **Debug programs**
-
- **Enable computer and user accounts to be trusted for delegation**
-
- **Generate security audits**
-
- **Impersonate a client after authentication**
-
- **Load and unload device drivers**
-
- **Manage auditing and security log**
-
- **Modify firmware environment values**
-
- **Replace a process-level token**
-
- **Restore files and directories**
-
- **Take ownership of files or other objects**
+ - **Act as part of the operating system**
+ - **Back up files and directories**
+ - **Create a token object**
+ - **Debug programs**
+ - **Enable computer and user accounts to be trusted for delegation**
+ - **Generate security audits**
+ - **Impersonate a client after authentication**
+ - **Load and unload device drivers**
+ - **Manage auditing and security log**
+ - **Modify firmware environment values**
+ - **Replace a process-level token**
+ - **Restore files and directories**
+ - **Take ownership of files or other objects**
If you configure this policy setting, an audit event is generated when sensitive privilege requests are made. Success audits record successful attempts, and failure audits record unsuccessful attempts.
@@ -55,45 +39,14 @@ Event volume: High
Default: Not configured
-
-
-
-
-
-
-
-
-
-
-4672 |
-Special privileges assigned to new logon. |
-
-
-4673 |
-A privileged service was called. |
-
-
-4674 |
-An operation was attempted on a privileged object. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4672 | Special privileges assigned to new logon.|
+| 4673 | A privileged service was called. |
+| 4674 | An operation was attempted on a privileged object.|
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-shut-down-system-immediately-if-unable-to-log-security-audits.md b/windows/keep-secure/audit-shut-down-system-immediately-if-unable-to-log-security-audits.md
index dd3b82a5bd..5ce9aeecf7 100644
--- a/windows/keep-secure/audit-shut-down-system-immediately-if-unable-to-log-security-audits.md
+++ b/windows/keep-secure/audit-shut-down-system-immediately-if-unable-to-log-security-audits.md
@@ -5,25 +5,22 @@ ms.assetid: 2cd23cd9-0e44-4d0b-a1f1-39fc29303826
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit: Shut down system immediately if unable to log security audits
-
**Applies to**
-
- Windows 10
Describes the best practices, location, values, management practices, and security considerations for the **Audit: Shut down system immediately if unable to log security audits** security policy setting.
## Reference
-
The **Audit: Shut down system immediately if unable to log security audits** policy setting determines whether the system shuts down if it is unable to log security events. This policy setting is a requirement for Trusted Computer System Evaluation Criteria (TCSEC)-C2 and Common Criteria certification to prevent auditable events from occurring if the audit system is unable to log those events. Microsoft has chosen to meet this requirement by halting the system and displaying a Stop message in the case of a failure of the auditing system. Enabling this policy setting stops the system if a security audit cannot be logged for any reason. Typically, an event fails to be logged when the security audit log is full and the value of **Retention method for security log** is **Do not overwrite events (clear log manually)** or **Overwrite events by days**.
With **Audit: Shut down system immediately if unable to log security audits** set to **Enabled**, if the security log is full and an existing entry cannot be overwritten, the following Stop message appears:
-
@@ -35,9 +32,7 @@ With **Audit: Shut down system immediately if unable to log security audits** se
-
-
To recover, you must log on, archive the log (optional), clear the log, and reset this option as desired.
If the computer is unable to record events to the security log, critical evidence or important troubleshooting information might not be available for review after a security incident.
@@ -45,9 +40,7 @@ If the computer is unable to record events to the security log, critical evidenc
### Possible values
- Enabled
-
- Disabled
-
- Not defined
### Best practices
@@ -62,52 +55,18 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Sec
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
-
-
-
-
-
-
-
-
-
-Default Domain Policy |
-Not defined |
-
-
-Default Domain Controller Policy |
-Not defined |
-
-
-Stand-Alone Server Default Settings |
-Disabled |
-
-
-DC Effective Default Settings |
-Disabled |
-
-
-Member Server Effective Default Settings |
-Disabled |
-
-
-Client Computer Effective Default Settings |
-Disabled |
-
-
-
-
+| Server type or GPO | Default value |
+| - | - |
+| Default Domain Policy | Not defined
+| Default Domain Controler Policy | Not defined
+| Stand-Alone Server Default Settings | Disabled
+| DC Effective Default Settings | Disabled
+| Member Server Effective Default Settings | Disabled
+| Client Computer Effective Default Settings | Disabled
-
## Policy management
-
This section describes features and tools that are available to help you manage this policy.
-
The administrative burden of enabling this policy setting can be very high, especially if you also set the **Retention method for security log** to **Do not overwrite events (clear log manually)**. This setting turns a repudiation threat (a backup operator could deny that they backed up or restored data) into a denial-of-service threat, because a server can be forced to shut down if it is overwhelmed with logon events and other security events that are written to the security log. Additionally, because the shutdown is not graceful, it is possible that irreparable damage to the operating system, applications, or data could result. Although the NTFS file system will guarantee that the file system's integrity will be maintained during a sudden system shutdown, it cannot guarantee that every data file for every application will still be in a usable form when the system is restarted.
### Restart requirement
@@ -120,7 +79,6 @@ Modifying this setting may affect compatibility with clients, services, and appl
## Security considerations
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
@@ -137,14 +95,6 @@ If you enable this policy setting, the administrative burden can be significant,
## Related topics
-
-[Security Options](security-options.md)
-
+- [Security Options](security-options.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-special-logon.md b/windows/keep-secure/audit-special-logon.md
index b95710f26b..439cf91d3d 100644
--- a/windows/keep-secure/audit-special-logon.md
+++ b/windows/keep-secure/audit-special-logon.md
@@ -5,14 +5,13 @@ ms.assetid: e1501bac-1d09-4593-8ebb-f311231567d3
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit Special Logon
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
@@ -21,7 +20,6 @@ This topic for the IT professional describes the Advanced Security Audit policy
This security policy setting determines whether the operating system generates audit events when:
- A special logon is used. A special logon is a logon that has administrator-equivalent privileges and can be used to elevate a process to a higher level.
-
- A member of a special group logs on. Special Groups is a Windows feature that enables the administrator to find out when a member of a certain group has logged on. The administrator can set a list of group security identifiers (SIDs) in the registry. If any of these SIDs is added to a token during logon and this auditing subcategory is enabled, a security event is logged. For more information about this feature, see [article 947223](http://go.microsoft.com/fwlink/p/?linkid=120183) in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/p/?linkid=120183).
Users holding special privileges can potentially make changes to the system. We recommend that you track their activity.
@@ -30,37 +28,12 @@ Event volume: Low
Default: Success
-
-
-
-
-
-
-
-
-
-
-4964 |
-Special groups have been assigned to a new logon. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4964 | Special groups have been assigned to a new logon.|
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-system-integrity.md b/windows/keep-secure/audit-system-integrity.md
index b9e785f0b3..dfc2666ebf 100644
--- a/windows/keep-secure/audit-system-integrity.md
+++ b/windows/keep-secure/audit-system-integrity.md
@@ -5,14 +5,13 @@ ms.assetid: 942a9a7f-fa31-4067-88c7-f73978bf2034
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit System Integrity
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
@@ -21,95 +20,33 @@ This topic for the IT professional describes the Advanced Security Audit policy
Activities that violate the integrity of the security subsystem include the following:
- Audited events are lost due to a failure of the auditing system.
-
- A process uses an invalid local procedure call (LPC) port in an attempt to impersonate a client, reply to a client address space, read to a client address space, or write from a client address space.
-
- A remote procedure call (RPC) integrity violation is detected.
-
- A code integrity violation with an invalid hash value of an executable file is detected.
-
- Cryptographic tasks are performed.
-**Important**
-Violations of security subsystem integrity are critical and could indicate a potential security attack.
-
+> **Important:** Violations of security subsystem integrity are critical and could indicate a potential security attack.
-
Event volume: Low
Default: Success and failure
-
-
-
-
-
-
-
-
-
-
-4612 |
-Internal resources allocated for the queuing of audit messages have been exhausted, leading to the loss of some audits. |
-
-
-4615 |
-Invalid use of LPC port. |
-
-
-4618 |
-A monitored security event pattern has occurred. |
-
-
-4816 |
-RPC detected an integrity violation while decrypting an incoming message. |
-
-
-5038 |
-Code integrity determined that the image hash of a file is not valid. The file could be corrupt due to unauthorized modification or the invalid hash could indicate a potential disk device error. |
-
-
-5056 |
-A cryptographic self-test was performed. |
-
-
-5057 |
-A cryptographic primitive operation failed. |
-
-
-5060 |
-Verification operation failed. |
-
-
-5061 |
-Cryptographic operation. |
-
-
-5062 |
-A kernel-mode cryptographic self-test was performed. |
-
-
-6281 |
-Code Integrity determined that the page hashes of an image file are not valid. The file could be improperly signed without page hashes or corrupt due to unauthorized modification. The invalid hashes could indicate a potential disk device error. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4612 | Internal resources allocated for the queuing of audit messages have been exhausted, leading to the loss of some audits. |
+| 4615 | Invalid use of LPC port. |
+| 4618 | A monitored security event pattern has occurred.|
+| 4816 | RPC detected an integrity violation while decrypting an incoming message.|
+| 5038 | Code integrity determined that the image hash of a file is not valid. The file could be corrupt due to unauthorized modification or the invalid hash could indicate a potential disk device error.|
+| 5056 | A cryptographic self-test was performed. |
+| 5057 | A cryptographic primitive operation failed.|
+| 5060 | Verification operation failed. |
+| 5061 | Cryptographic operation. |
+| 5062 | A kernel-mode cryptographic self-test was performed.|
+| 6281 | Code Integrity determined that the page hashes of an image file are not valid. The file could be improperly signed without page hashes or corrupt due to unauthorized modification. The invalid hashes could indicate a potential disk device error.|
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-user-account-management.md b/windows/keep-secure/audit-user-account-management.md
index 406ceb5ef9..1f05f3085b 100644
--- a/windows/keep-secure/audit-user-account-management.md
+++ b/windows/keep-secure/audit-user-account-management.md
@@ -5,14 +5,13 @@ ms.assetid: f7e72998-3858-4197-a443-19586ecc4bfb
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit User Account Management
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the advanced security audit policy setting, **Audit User Account Management**, which determines whether the operating system generates audit events when specific user account management tasks are performed.
@@ -20,15 +19,10 @@ This topic for the IT professional describes the advanced security audit policy
Tasks that are audited for user account management include:
- A user account is created, changed, deleted, renamed, disabled, enabled, locked out, or unlocked.
-
- A user account password is set or changed.
-
- Security identifier (SID) history is added to a user account.
-
- The Directory Services Restore Mode password is set.
-
- Permissions are changed on accounts that are members of administrator groups.
-
- Credential Manager credentials are backed up or restored.
This policy setting is essential for tracking events that involve provisioning and managing user accounts.
@@ -37,97 +31,27 @@ Event volume: Low
Default: Success
-
-
-
-
-
-
-
-
-
-
-4720 |
-A user account was created. |
-
-
-4722 |
-A user account was enabled. |
-
-
-4723 |
-An attempt was made to change an account's password. |
-
-
-4724 |
-An attempt was made to reset an account's password. |
-
-
-4725 |
-A user account was disabled. |
-
-
-4726 |
-A user account was deleted. |
-
-
-4738 |
-A user account was changed. |
-
-
-4740 |
-A user account was locked out. |
-
-
-4765 |
-SID History was added to an account. |
-
-
-4766 |
-An attempt to add SID History to an account failed. |
-
-
-4767 |
-A user account was unlocked. |
-
-
-4780 |
-The ACL was set on accounts which are members of administrators groups. |
-
-
-4781 |
-The name of an account was changed: |
-
-
-4794 |
-An attempt was made to set the Directory Services Restore Mode. |
-
-
-5376 |
-Credential Manager credentials were backed up. |
-
-
-5377 |
-Credential Manager credentials were restored from a backup. |
-
-
-
-
+| Event ID | Event message |
+| - | - |
+| 4720 | A user account was created. |
+| 4722 | A user account was enabled. |
+| 4723 | An attempt was made to change an account's password.|
+| 4724 | An attempt was made to reset an account's password. |
+| 4725 | A user account was disabled. |
+| 4726 | A user account was deleted. |
+| 4738 | A user account was changed. |
+| 4740 | A user account was locked out.|
+| 4765 | SID History was added to an account.|
+| 4766 | An attempt to add SID History to an account failed.|
+| 4767 | A user account was unlocked. |
+| 4780 | The ACL was set on accounts which are members of administrators groups.|
+| 4781 | The name of an account was changed: |
+| 4794 | An attempt was made to set the Directory Services Restore Mode.|
+| 5376 | Credential Manager credentials were backed up. |
+| 5377 | Credential Manager credentials were restored from a backup.|
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/audit-user-device-claims.md b/windows/keep-secure/audit-user-device-claims.md
index 6d913998df..254bfb2c7d 100644
--- a/windows/keep-secure/audit-user-device-claims.md
+++ b/windows/keep-secure/audit-user-device-claims.md
@@ -5,14 +5,13 @@ ms.assetid: D3D2BFAF-F2C0-462A-9377-673DB49D5486
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit User/Device Claims
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes the advanced security audit policy setting, **Audit User/Device Claims**, which enables you to audit security events that are generated by user and device claims.
@@ -57,19 +56,9 @@ Default: Not configured
-
-
## Related topics
-
-[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
+- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/back-up-files-and-directories.md b/windows/keep-secure/back-up-files-and-directories.md
index fa7650f9c0..2cddb14842 100644
--- a/windows/keep-secure/back-up-files-and-directories.md
+++ b/windows/keep-secure/back-up-files-and-directories.md
@@ -5,47 +5,38 @@ ms.assetid: 1cd6bdd5-1501-41f4-98b9-acf29ac173ae
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Back up files and directories
-
**Applies to**
-
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Back up files and directories** security policy setting.
## Reference
-
This user right determines which users can bypass file and directory, registry, and other persistent object permissions for the purposes of backing up the system. This user right is effective only when an application attempts access through the NTFS backup application programming interface (API) through a backup tool such as NTBACKUP.EXE. Otherwise, standard file and directory permissions apply.
This user right is similar to granting the following permissions to the user or group you have selected on all files and folders on the system:
- Traverse Folder/Execute File
-
- List Folder/Read Data
-
- Read Attributes
-
- Read Extended Attributes
-
- Read Permissions
Default on workstations and servers:
- Administrators
-
- Backup Operators
Default on domain controllers:
- Administrators
-
- Backup Operators
-
- Server Operators
Constant: SeBackupPrivilege
@@ -53,13 +44,11 @@ Constant: SeBackupPrivilege
### Possible values
- User-defined list of accounts
-
- Not Defined
### Best practices
1. Restrict the **Back up files and directories** user right to members of the IT team who must back up organizational data as part of their daily job responsibilities. Because there is no way to be sure that a user is backing up data, stealing data, or copying data to be distributed, only assign this user right to trusted users.
-
2. If you are using backup software that runs under specific service accounts, only these accounts (and not the IT staff) should have the **Back up files and directories** user right.
### Location
@@ -72,57 +61,17 @@ By default, this right is granted to Administrators and Backup Operators on work
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
-
-
-
-
-
-
-
-
-
-Default Domain Policy |
-Not Defined |
-
-
-Default Domain Controller Policy |
-Administrators
-Backup Operators
-Server Operators |
-
-
-Stand-Alone Server Default Settings |
-Administrators
-Backup Operators |
-
-
-Domain Controller Effective Default Settings |
-Administrators
-Backup Operators
-Server Operators |
-
-
-Member Server Effective Default Settings |
-Administrators
-Backup Operators |
-
-
-Client Computer Effective Default Settings |
-Administrators
-Backup Operators |
-
-
-
-
+| Server type or GPO | Default value |
+| - | - |
+| Default Domain Policy | Not Defined |
+| Default Domain Controller Policy | Administrators
Backup Operators
Server Operators|
+| Stand-Alone Server Default Settings | Administrators
Backup Operators|
+| Domain Controller Effective Default Settings | Administrators
Backup Operators
Server Operators|
+| Member Server Effective Default Settings | Administrators
Backup Operators|
+| Client Computer Effective Default Settings | Administrators
Backup Operators|
-
## Policy management
-
A restart of the device is not required for this policy setting to be effective.
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
@@ -132,18 +81,14 @@ Any change to the user rights assignment for an account becomes effective the ne
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
## Security considerations
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
@@ -160,14 +105,6 @@ Changes in the membership of the groups that have the **Back up files and direct
## Related topics
-
-[User Rights Assignment](user-rights-assignment.md)
-
+- [User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/backup-tpm-recovery-information-to-ad-ds.md b/windows/keep-secure/backup-tpm-recovery-information-to-ad-ds.md
index 0aca86ef95..5f46d91a0d 100644
--- a/windows/keep-secure/backup-tpm-recovery-information-to-ad-ds.md
+++ b/windows/keep-secure/backup-tpm-recovery-information-to-ad-ds.md
@@ -5,30 +5,25 @@ ms.assetid: 62bcec80-96a1-464e-8b3f-d177a7565ac5
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Backup the TPM recovery Information to AD DS
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes how to back up a computer’s Trusted Platform Module (TPM) information to Active Directory Domain Services (AD DS) so that you can use AD DS to administer the TPM from a remote computer.
## About administering TPM remotely
-
Backing up the TPM owner information for a computer allows administrators in a domain to remotely configure the TPM security hardware on the local computer. For example, administrators might want to reset the TPM to the manufacturer’s defaults when they decommission or repurpose computers, without having to be present at the computer.
You can use AD DS to store TPM owner information for use in recovery situations where the TPM owner has forgotten the password or where you must take control of the TPM. There is only one TPM owner password per computer; therefore, the hash of the TPM owner password can be stored as an attribute of the computer object in AD DS. The attribute has the common name (CN) of **ms-TPM-OwnerInformation**.
-**Note**
-The TPM owner authorization value is stored in AD DS, and it is present in a TPM owner password file as a SHA-1 hash of the TPM owner password, which is base 64–encoded. The actual owner password is not stored.
-
+> **Note:** The TPM owner authorization value is stored in AD DS, and it is present in a TPM owner password file as a SHA-1 hash of the TPM owner password, which is base 64–encoded. The actual owner password is not stored.
-
Domain controllers running Windows Server 2012 R2 or Windows Server 2012 include the required AD DS schema objects by default. However, if your domain controller is running Windows Server 2008 R2, you need to update the schema as described in [AD DS schema extensions to support TPM backup](ad-ds-schema-extensions-to-support-tpm-backup.md).
This topic contains procedures, some of which are dependent on Visual Basic scripts, to recover TPM information and decommission TPM on remote computers. Sample scripts are available, which you can customize to meet the requirements of your environment.
@@ -36,50 +31,37 @@ This topic contains procedures, some of which are dependent on Visual Basic scri
In this topic:
1. [Check status of prerequisites](#bkmk-prereqs)
-
2. [Set permissions to back up password information](#bkmk-setperms)
-
3. [Configure Group Policy to back up TPM recovery information in AD DS](#bkmk-configuregp)
-
4. [Use AD DS to recover TPM information](#bkmk-useit)
-
5. [Sample scripts](#bkmk-adds-tpm-scripts)
## Check status of prerequisites
-
Before you begin your backup, ensure that the following prerequisites are met:
1. All domain controllers that are accessible by client computers that will be using TPM services are running Windows Server 2012 R2, Windows Server 2012, or Windows Server 2008 R2 with the updated schema.
-
- **Tip**
- For more info about the schema extensions that are required for a TPM backup in Active Directory domains that are running Windows Server 2008 R2, see [AD DS schema extensions to support TPM backup](ad-ds-schema-extensions-to-support-tpm-backup.md).
-
+
+ > **Tip:** For more info about the schema extensions that are required for a TPM backup in Active Directory domains that are running Windows Server 2008 R2, see [AD DS schema extensions to support TPM backup](ad-ds-schema-extensions-to-support-tpm-backup.md).
-
2. You have domain administrator rights in the target forest, or you are using an account that has been granted appropriate permissions to extend the schema for the target forest. Members of the Enterprise Admins or Schema Admins groups are examples of accounts that have the appropriate permissions.
## Set permissions to back up password information
-
This procedure uses the sample script [Add-TPMSelfWriteACE.vbs](#bkmk-add-tpmselfwriteace) to add an access control entry (ACE) so that backing up TPM recovery information is possible. A client computer cannot back up TPM owner information until this ACE is added.
This script is run on the domain controller that you will use to administer the TPM recovery information, and it operates under the following assumptions:
- You have domain administrator credentials to set permissions for the top-level domain object.
-
- Your target domain is the same as the domain for the user account that is running the script. For example, running the script as TESTDOMAIN\\admin will extend permissions for TESTDOMAIN.
- **Note**
- You might need to modify the sample script if you want to set permissions for multiple domains, but you do not have domain administrator accounts for each of those domains. Find the variable **strPathToDomain** in the script, and modify it for your target domain, for example:
-
+ > **Note:** You might need to modify the sample script if you want to set permissions for multiple domains, but you do not have domain administrator accounts for each of those domains. Find the variable **strPathToDomain** in the script, and modify it for your target domain, for example:
`LDAP://DC=testdomain,DC=nttest,DC=microsoft,DC=com`
-
-
- Your domain is configured so that permissions are inherited from the top-level domain object to targeted computer objects.
- Permissions will not take effect if any container in the hierarchy does not allow inherited permissions. By default, permissions inheritance is set in AD DS. If you are not sure whether your configuration differs from this default, you can continue with the setup steps to set the permissions. You can then verify your configuration as described later in this topic. Or you can click the **Effective Permissions** button while viewing the properties of a computer object, then check that **Self** is approved to write the **msTPM-OwnerInformation** attribute.
+ Permissions will not take effect if any container in the hierarchy does not allow inherited permissions. By default, permissions inheritance is set in AD DS. If you are not sure whether your configuration differs from this default, you can continue with the setup steps to set the permissions.
+ You can then verify your configuration as described later in this topic. Or you can click the **Effective Permissions** button while viewing the properties of a computer object, then check that **Self** is approved to write the **msTPM-OwnerInformation** attribute.
**To add an ACE to allow TPM recovery information backup**
@@ -88,29 +70,23 @@ This script is run on the domain controller that you will use to administer the
The script contains a permission extension, and you must modify the value of **strPathToDomain** by using your domain name.
2. Save your modifications to the script.
-
3. Type the following at a command prompt, and then press ENTER:
**cscript Add-TPMSelfWriteACE.vbs**
This script adds a single ACE to the top-level domain object. The ACE is an inheritable permission that allows the computer (SELF) to write to the **ms-TPM-OwnerInformation** attribute for computer objects in the domain.
-
Complete the following procedure to check that the correct permissions are set and to remove TPM and BitLocker ACEs from the top-level domain, if necessary.
**Manage ACEs configured on TPM schema objects**
1. Open the sample script **List-ACEs.vbs**.
-
2. Modify **List-ACEs.vbs**.
You must modify:
-
- Value of **strPathToDomain**: Use your domain name.
-
- Filter options: The script sets a filter to address BitLocker and TPM schema objects, so you must modify **If IsFilterActive ()** if you want to list or remove other schema objects.
3. Save your modifications to the script.
-
4. Type the following at a command prompt, and then press ENTER:
**cscript List-ACEs.vbs**
@@ -119,60 +95,41 @@ Complete the following procedure to check that the correct permissions are set a
## Configure Group Policy to back up TPM recovery information in AD DS
-
Use these procedures to configure the [TPM Group Policy settings](trusted-platform-module-services-group-policy-settings.md#bkmk-tpmgp-addsbu) policy setting on a local computer. In a production environment, an efficient way to do this is to create or edit a Group Policy Object (GPO) that can target client computers in the domain.
**To enable local policy setting to back up TPM recovery information to AD DS**
1. Sign in to a domain-joined computer by using a domain account that is a member of the local Administrators group.
-
2. Open the Local Group Policy Editor (gpedit.msc), and in the console tree, navigate to **Computer Configuration\\Administrative Templates\\System**.
-
3. Click **Trusted Platform Module Services**.
-
4. Double-click **Turn on TPM backup to Active Directory Domain Services**.
-
5. Click **Enabled**, and then click **OK**.
-
-**Important**
-When this setting is enabled, the TPM owner password cannot be set or changed unless the computer is connected to the domain and AD DS backup of the TPM recovery information succeeds.
-
+> **Important:** When this setting is enabled, the TPM owner password cannot be set or changed unless the computer is connected to the domain and AD DS backup of the TPM recovery information succeeds.
-
## Use AD DS to recover TPM information
-
When you need to recover the TPM owner information from AD DS and use it to manage the TPM, you need to read the **ms-TPM-OwnerInformation** object from AD DS, and then manually create a TPM owner password backup file that can be supplied when TPM owner credentials are required.
**To obtain TPM owner backup information from AD DS and create a password file**
1. Sign in to a domain controller by using domain administrator credentials.
-
2. Copy the sample script file, [Get-TPMOwnerInfo.vbs](#ms-tpm-ownerinformation), to a location on your computer.
-
3. Open a Command Prompt window, and change the default location to the location of the sample script files you saved in the previous step.
-
4. At the command prompt, type **cscript Get-TPMOwnerInfo.vbs**.
The expected output is a string that is the hash of the password that you created earlier.
-
- **Note**
- If you receive the error message, "Active Directory: The directory property cannot be found in the cache," verify that you are using a domain administrator account, which is required to read the **ms-TPM-OwnerInformation** attribute.
-
+ > **Note:** If you receive the error message, "Active Directory: The directory property cannot be found in the cache," verify that you are using a domain administrator account, which is required to read the **ms-TPM-OwnerInformation** attribute.
+
The only exception to this requirement is that if users are the Creator Owner of computer objects that they join to the domain, they can possibly read the TPM owner information for their computer objects.
-
-
5. Open Notepad or another text editor, and copy the following code sample into the file, and replace *TpmOwnerPasswordHash* with the string that you recorded in the previous step.
-
+
``` syntax
@@ -181,18 +138,14 @@ When you need to recover the TPM owner information from AD DS and use it to man
TpmOwnerPasswordHash
```
-
6. Save this file with a .tpm extension on a removable storage device, such as a USB flash drive. When you access the TPM, and you are required to provide the TPM owner password, choose the option for reading the password from a file and provide the path to this file.
## Sample scripts
-
You can use all or portions of the following sample scripts, which are used in the preceding procedures, to configure AD DS for backing up TPM recovery information. Customization is required depending on how your environment is configured.
- [Add-TPMSelfWriteACE.vbs: Use to add the access control entry (ACE) for the TPM to AD DS](#bkmk-add-tpmselfwriteace)
-
- [List-ACEs.vbs: Use to list or remove the ACEs that are configured on BitLocker and TPM schema objects](#bkmk-list-aces)
-
- [Get-TPMOwnerInfo.vbs: Use to retrieve the TPM recovery information from AD DS for a particular computer](#bkmk-get-tpmownerinfo)
### Add-TPMSelfWriteACE.vbs
@@ -232,97 +185,66 @@ This script adds the access control entry (ACE) for the TPM to AD DS so that th
' of such damages.
'
' Version 1.0.2 - Tested and re-released for Windows 8 and Windows Server 2012
-
'
'===============================================================================
-
' --------------------------------------------------------------------------------
' Access Control Entry (ACE) constants
' --------------------------------------------------------------------------------
-
'- From the ADS_ACETYPE_ENUM enumeration
Const ADS_ACETYPE_ACCESS_ALLOWED_OBJECT = &H5 'Allows an object to do something
-
'- From the ADS_ACEFLAG_ENUM enumeration
Const ADS_ACEFLAG_INHERIT_ACE = &H2 'ACE can be inherited to child objects
Const ADS_ACEFLAG_INHERIT_ONLY_ACE = &H8 'ACE does NOT apply to target (parent) object
-
'- From the ADS_RIGHTS_ENUM enumeration
Const ADS_RIGHT_DS_WRITE_PROP = &H20 'The right to write object properties
Const ADS_RIGHT_DS_CREATE_CHILD = &H1 'The right to create child objects
-
'- From the ADS_FLAGTYPE_ENUM enumeration
Const ADS_FLAG_OBJECT_TYPE_PRESENT = &H1 'Target object type is present in the ACE
Const ADS_FLAG_INHERITED_OBJECT_TYPE_PRESENT = &H2 'Target inherited object type is present in the ACE
-
' --------------------------------------------------------------------------------
' TPM and FVE schema object GUID's
' --------------------------------------------------------------------------------
-
'- ms-TPM-OwnerInformation attribute
SCHEMA_GUID_MS_TPM_OWNERINFORMATION = "{AA4E1A6D-550D-4E05-8C35-4AFCB917A9FE}"
-
'- ms-FVE-RecoveryInformation object
SCHEMA_GUID_MS_FVE_RECOVERYINFORMATION = "{EA715D30-8F53-40D0-BD1E-6109186D782C}"
-
'- Computer object
SCHEMA_GUID_COMPUTER = "{BF967A86-0DE6-11D0-A285-00AA003049E2}"
-
'Reference: "Platform SDK: Active Directory Schema"
-
-
-
-
' --------------------------------------------------------------------------------
' Set up the ACE to allow write of TPM owner information
' --------------------------------------------------------------------------------
-
Set objAce1 = createObject("AccessControlEntry")
-
objAce1.AceFlags = ADS_ACEFLAG_INHERIT_ACE + ADS_ACEFLAG_INHERIT_ONLY_ACE
objAce1.AceType = ADS_ACETYPE_ACCESS_ALLOWED_OBJECT
objAce1.Flags = ADS_FLAG_OBJECT_TYPE_PRESENT + ADS_FLAG_INHERITED_OBJECT_TYPE_PRESENT
-
objAce1.Trustee = "SELF"
objAce1.AccessMask = ADS_RIGHT_DS_WRITE_PROP
objAce1.ObjectType = SCHEMA_GUID_MS_TPM_OWNERINFORMATION
objAce1.InheritedObjectType = SCHEMA_GUID_COMPUTER
-
-
-
' --------------------------------------------------------------------------------
' NOTE: BY default, the "SELF" computer account can create
' BitLocker recovery information objects and write BitLocker recovery properties
'
' No additional ACE's are needed.
' --------------------------------------------------------------------------------
-
-
' --------------------------------------------------------------------------------
' Connect to Discretional ACL (DACL) for domain object
' --------------------------------------------------------------------------------
-
Set objRootLDAP = GetObject("LDAP://rootDSE")
strPathToDomain = "LDAP://" & objRootLDAP.Get("defaultNamingContext") ' e.g. string dc=fabrikam,dc=com
-
Set objDomain = GetObject(strPathToDomain)
-
WScript.Echo "Accessing object: " + objDomain.Get("distinguishedName")
-
Set objDescriptor = objDomain.Get("ntSecurityDescriptor")
Set objDacl = objDescriptor.DiscretionaryAcl
-
' --------------------------------------------------------------------------------
' Add the ACEs to the Discretionary ACL (DACL) and set the DACL
' --------------------------------------------------------------------------------
-
objDacl.AddAce objAce1
-
objDescriptor.DiscretionaryAcl = objDacl
objDomain.Put "ntSecurityDescriptor", Array(objDescriptor)
objDomain.SetInfo
-
WScript.Echo "SUCCESS!"
```
@@ -364,11 +286,9 @@ This script lists or removes the ACEs that are configured on BitLocker and TPM s
' Version 1.0.2 - Tested and re-released for Windows 8 and Windows Server 2012
'
'===============================================================================
-
' --------------------------------------------------------------------------------
' Usage
' --------------------------------------------------------------------------------
-
Sub ShowUsage
Wscript.Echo "USAGE: List-ACEs"
Wscript.Echo "List access permissions for BitLocker and TPM schema objects"
@@ -377,14 +297,10 @@ Sub ShowUsage
Wscript.Echo "Removes access permissions for BitLocker and TPM schema objects"
WScript.Quit
End Sub
-
-
' --------------------------------------------------------------------------------
' Parse Arguments
' --------------------------------------------------------------------------------
-
Set args = WScript.Arguments
-
Select Case args.Count
Case 0
@@ -399,97 +315,63 @@ Select Case args.Count
removeACE = True
End If
End If
-
Case Else
ShowUsage
-
End Select
-
' --------------------------------------------------------------------------------
' Configuration of the filter to show/remove only ACE's for BDE and TPM objects
' --------------------------------------------------------------------------------
-
'- ms-TPM-OwnerInformation attribute
SCHEMA_GUID_MS_TPM_OWNERINFORMATION = "{AA4E1A6D-550D-4E05-8C35-4AFCB917A9FE}"
-
'- ms-FVE-RecoveryInformation object
SCHEMA_GUID_MS_FVE_RECOVERYINFORMATION = "{EA715D30-8F53-40D0-BD1E-6109186D782C}"
-
' Use this filter to list/remove only ACEs related to TPM and BitLocker
-
aceGuidFilter = Array(SCHEMA_GUID_MS_TPM_OWNERINFORMATION, _
SCHEMA_GUID_MS_FVE_RECOVERYINFORMATION)
-
-
' Note to script source reader:
' Uncomment the following line to turn off the filter and list all ACEs
'aceGuidFilter = Array()
-
-
' --------------------------------------------------------------------------------
' Helper functions related to the list filter for listing or removing ACE's
' --------------------------------------------------------------------------------
-
Function IsFilterActive()
-
If Join(aceGuidFilter) = "" Then
IsFilterActive = False
Else
IsFilterActive = True
End If
-
End Function
-
-
Function isAceWithinFilter(ace)
-
aceWithinFilter = False ' assume first not pass the filter
-
For Each guid In aceGuidFilter
-
If ace.ObjectType = guid Or ace.InheritedObjectType = guid Then
isAceWithinFilter = True
End If
Next
-
End Function
-
Sub displayFilter
For Each guid In aceGuidFilter
WScript.echo guid
Next
End Sub
-
-
' --------------------------------------------------------------------------------
' Connect to Discretional ACL (DACL) for domain object
' --------------------------------------------------------------------------------
-
Set objRootLDAP = GetObject("LDAP://rootDSE")
strPathToDomain = "LDAP://" & objRootLDAP.Get("defaultNamingContext") ' e.g. dc=fabrikam,dc=com
-
Set domain = GetObject(strPathToDomain)
-
WScript.Echo "Accessing object: " + domain.Get("distinguishedName")
WScript.Echo ""
-
Set descriptor = domain.Get("ntSecurityDescriptor")
Set dacl = descriptor.DiscretionaryAcl
-
-
' --------------------------------------------------------------------------------
' Show Access Control Entries (ACE's)
' --------------------------------------------------------------------------------
-
' Loop through the existing ACEs, including all ACEs if the filter is not active
-
i = 1 ' global index
c = 0 ' found count - relevant if filter is active
-
For Each ace In dacl
-
If IsFilterActive() = False or isAceWithinFilter(ace) = True Then
-
' note to script source reader:
' echo i to show the index of the ACE
@@ -501,73 +383,47 @@ For Each ace In dacl
WScript.echo "> InheritedObjectType: " & ace.InheritedObjectType
WScript.echo "> Trustee: " & ace.Trustee
WScript.echo ""
-
-
if IsFilterActive() = True Then
c = c + 1
-
' optionally include this ACE in removal list if configured
' note that the filter being active is a requirement since we don't
' want to accidentally remove all ACEs
-
If removeACE = True Then
dacl.RemoveAce ace
End If
-
end if
-
End If
-
i = i + 1
-
Next
-
-
' Display number of ACEs found
-
If IsFilterActive() = True Then
-
WScript.echo c & " ACE(s) found in " & domain.Get("distinguishedName") _
& " related to BitLocker and TPM" 'note to script source reader: change this line if you configure your own
-
filter
-
' note to script source reader:
' uncomment the following lines if you configure your own filter
'WScript.echo ""
'WScript.echo "The following filter was active: "
'displayFilter
'Wscript.echo ""
-
Else
-
i = i - 1
WScript.echo i & " total ACE(s) found in " & domain.Get("distinguishedName")
End If
-
-
' --------------------------------------------------------------------------------
' Optionally remove ACE's on a filtered list
' --------------------------------------------------------------------------------
-
if removeACE = True and IsFilterActive() = True then
-
descriptor.DiscretionaryAcl = dacl
domain.Put "ntSecurityDescriptor", Array(descriptor)
domain.setInfo
-
WScript.echo c & " ACE(s) removed from " & domain.Get("distinguishedName")
-
else
-
if removeACE = True then
-
WScript.echo "You must specify a filter to remove ACEs from " & domain.Get("distinguishedName")
end if
-
-
end if
```
@@ -609,24 +465,18 @@ This script retrieves TPM recovery information from AD DS for a particular comp
' Version 1.1.2 - Tested and re-released for Windows 8 and Windows Server 2012
'
'=================================================================================
-
-
' --------------------------------------------------------------------------------
' Usage
' --------------------------------------------------------------------------------
-
Sub ShowUsage
Wscript.Echo "USAGE: Get-TpmOwnerInfo [Optional Computer Name]"
Wscript.Echo "If no computer name is specified, the local computer is assumed."
WScript.Quit
End Sub
-
' --------------------------------------------------------------------------------
' Parse Arguments
' --------------------------------------------------------------------------------
-
Set args = WScript.Arguments
-
Select Case args.Count
Case 0
@@ -643,22 +493,15 @@ Select Case args.Count
Case Else
ShowUsage
-
End Select
-
-
' --------------------------------------------------------------------------------
' Get path to Active Directory computer object associated with the computer name
' --------------------------------------------------------------------------------
-
Function GetStrPathToComputer(strComputerName)
-
' Uses the global catalog to find the computer in the forest
' Search also includes deleted computers in the tombstone
-
Set objRootLDAP = GetObject("LDAP://rootDSE")
namingContext = objRootLDAP.Get("defaultNamingContext") ' e.g. string dc=fabrikam,dc=com
-
strBase = ""
Set objConnection = CreateObject("ADODB.Connection")
@@ -666,84 +509,52 @@ Function GetStrPathToComputer(strComputerName)
objConnection.Provider = "ADsDSOOBject"
objConnection.Open "Active Directory Provider"
Set objCommand.ActiveConnection = objConnection
-
strFilter = "(&(objectCategory=Computer)(cn=" & strComputerName & "))"
strQuery = strBase & ";" & strFilter & ";distinguishedName;subtree"
-
objCommand.CommandText = strQuery
objCommand.Properties("Page Size") = 100
objCommand.Properties("Timeout") = 100
objCommand.Properties("Cache Results") = False
-
' Enumerate all objects found.
-
Set objRecordSet = objCommand.Execute
If objRecordSet.EOF Then
WScript.echo "The computer name '" & strComputerName & "' cannot be found."
WScript.Quit 1
End If
-
' Found object matching name
-
Do Until objRecordSet.EOF
dnFound = objRecordSet.Fields("distinguishedName")
GetStrPathToComputer = "LDAP://" & dnFound
objRecordSet.MoveNext
Loop
-
-
' Clean up.
Set objConnection = Nothing
Set objCommand = Nothing
Set objRecordSet = Nothing
-
End Function
-
' --------------------------------------------------------------------------------
' Securely access the Active Directory computer object using Kerberos
' --------------------------------------------------------------------------------
-
Set objDSO = GetObject("LDAP:")
strPath = GetStrPathToComputer(strComputerName)
-
-
WScript.Echo "Accessing object: " + strPath
-
Const ADS_SECURE_AUTHENTICATION = 1
Const ADS_USE_SEALING = 64 '0x40
Const ADS_USE_SIGNING = 128 '0x80
-
Set objComputer = objDSO.OpenDSObject(strPath, vbNullString, vbNullString, _
ADS_SECURE_AUTHENTICATION + ADS_USE_SEALING + ADS_USE_SIGNING)
-
' --------------------------------------------------------------------------------
' Get the TPM owner information from the Active Directory computer object
' --------------------------------------------------------------------------------
-
strOwnerInformation = objComputer.Get("msTPM-OwnerInformation")
WScript.echo "msTPM-OwnerInformation: " + strOwnerInformation
```
## Additional resources
-
-[Trusted Platform Module technology overview](trusted-platform-module-overview.md)
-
-[TPM fundamentals](tpm-fundamentals.md)
-
-[TPM Group Policy settings](trusted-platform-module-services-group-policy-settings.md)
-
-[TPM Cmdlets in Windows PowerShell](http://technet.microsoft.com/library/jj603116.aspx)
-
-[AD DS schema extensions to support TPM backup](ad-ds-schema-extensions-to-support-tpm-backup.md)
-
-[Prepare your organization for BitLocker: Planning and Policies](http://technet.microsoft.com/library/jj592683.aspx), see TPM considerations
-
-
-
-
-
-
-
-
-
+- [Trusted Platform Module technology overview](trusted-platform-module-overview.md)
+- [TPM fundamentals](tpm-fundamentals.md)
+- [TPM Group Policy settings](trusted-platform-module-services-group-policy-settings.md)
+- [TPM Cmdlets in Windows PowerShell](http://technet.microsoft.com/library/jj603116.aspx)
+- [AD DS schema extensions to support TPM backup](ad-ds-schema-extensions-to-support-tpm-backup.md)
+- [Prepare your organization for BitLocker: Planning and Policies](http://technet.microsoft.com/library/jj592683.aspx), see TPM considerations
diff --git a/windows/keep-secure/basic-audit-account-logon-events.md b/windows/keep-secure/basic-audit-account-logon-events.md
index ebac5ddb27..4bfa89fd5b 100644
--- a/windows/keep-secure/basic-audit-account-logon-events.md
+++ b/windows/keep-secure/basic-audit-account-logon-events.md
@@ -5,14 +5,13 @@ ms.assetid: 84B44181-E325-49A1-8398-AECC3CE0A516
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit account logon events
-
**Applies to**
-
- Windows 10
Determines whether to audit each instance of a user logging on to or logging off from another device in which this device is used to validate the account.
@@ -20,14 +19,12 @@ Determines whether to audit each instance of a user logging on to or logging off
This security setting determines whether to audit each instance of a user logging on to or logging off from another computer in which this computer is used to validate the account. Account logon events are generated when a domain user account is authenticated on a domain controller. The event is logged in the domain controller's security log. Logon events are generated when a local user is authenticated on a local computer. The event is logged in the local security log. Account logoff events are not generated.
If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when an account logon attempt succeeds. Failure audits generate an audit entry when an account logon attempt fails.
-
To set this value to **No auditing**, in the **Properties** dialog box for this policy setting, select the **Define these policy settings** check box and clear the **Success** and **Failure** check boxes.
**Default**: Success
## Configure this audit setting
-
You can configure this security setting by opening the appropriate policy under Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Audit Policy.
| Logon events | Description |
@@ -42,19 +39,9 @@ You can configure this security setting by opening the appropriate policy under
| 681 | Logon failure. A domain account logon was attempted. This event is not generated in Windows XP or in the Windows Server 2003 family. |
| 682 | A user has reconnected to a disconnected terminal server session. |
| 683 | A user disconnected a terminal server session without logging off. |
-
-
## Related topics
-
-[Basic security audit policy settings](basic-security-audit-policy-settings.md)
-
+- [Basic security audit policy settings](basic-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/basic-audit-account-management.md b/windows/keep-secure/basic-audit-account-management.md
index 54b8232935..ee0cf33722 100644
--- a/windows/keep-secure/basic-audit-account-management.md
+++ b/windows/keep-secure/basic-audit-account-management.md
@@ -5,14 +5,13 @@ ms.assetid: 369197E1-7E0E-45A4-89EA-16D91EF01689
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit account management
-
**Applies to**
-
- Windows 10
Determines whether to audit each event of account management on a device.
@@ -20,235 +19,69 @@ Determines whether to audit each event of account management on a device.
Examples of account management events include:
- A user account or group is created, changed, or deleted.
-
- A user account is renamed, disabled, or enabled.
-
- A password is set or changed.
-If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when any account management event succeeds. Failure audits generate an audit entry when any account management event fails. To set this value to **No auditing**, in the **Properties** dialog box for this policy setting, select the Define these policy settings check box and clear the **Success** and **Failure** check boxes.
+If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when any account management event succeeds. Failure audits generate an audit entry when any account management event fails. To
+set this value to **No auditing**, in the **Properties** dialog box for this policy setting, select the Define these policy settings check box and clear the **Success** and **Failure** check boxes.
**Default:**
- Success on domain controllers.
-
- No auditing on member servers.
## Configure this audit setting
-
You can configure this security setting by opening the appropriate policy under Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Audit Policy.
-
-
-
-
-
-
-
-
-
-
-| 624 |
-A user account was created. |
-
-
-| 627 |
-A user password was changed. |
-
-
-| 628 |
-A user password was set. |
-
-
-| 630 |
-A user account was deleted. |
-
-
-| 631 |
-A global group was created. |
-
-
-| 632 |
-A member was added to a global group. |
-
-
-| 633 |
-A member was removed from a global group. |
-
-
-| 634 |
-A global group was deleted. |
-
-
-| 635 |
-A new local group was created. |
-
-
-| 636 |
-A member was added to a local group. |
-
-
-| 637 |
-A member was removed from a local group. |
-
-
-| 638 |
-A local group was deleted. |
-
-
-| 639 |
-A local group account was changed. |
-
-
-| 641 |
-A global group account was changed. |
-
-
-| 642 |
-A user account was changed |
-
-
-| 643 |
-A domain policy was modified. |
-
-
-| 644 |
-A user account was auto locked. |
-
-
-| 645 |
-A computer account was created. |
-
-
-| 646 |
-A computer account was changed. |
-
-
-| 647 |
-A computer account was deleted. |
-
-
-| 648 |
-A local security group with security disabled was created.
-
-Note SECURITY_DISABLED in the formal name means that this group cannot be used to grant permissions in access checks.
-
-
+| Account management events | Description |
+| - | - |
+| 624 | A user account was created.|
+| 627 | A user password was changed.|
+| 628 | A user password was set. |
+| 630 | A user account was deleted.|
+| 631 | A global group was created. |
+| 632 | A member was added to a global group.|
+| 633 | A member was removed from a global group.|
+| 634 | A global group was deleted. |
+| 635 | A new local group was created.|
+| 636 | A member was added to a local group.|
+| 637 | A member was removed from a local group.|
+| 638 | A local group was deleted. |
+| 639 | A local group account was changed.|
+| 641 | A global group account was changed.|
+| 642 | A user account was changed. |
+| 643 | A domain policy was modified. |
+| 644 | A user account was auto locked. |
+| 645 | A computer account was created. |
+| 646 | A computer account was changed. |
+| 647 | A computer account was deleted. |
+| 648 | A local security group with security disabled was created.
**Note:** SECURITY_DISABLED in the formal name means that this group cannot be used to grant permissions in access checks. | |
+| 649 | A local security group with security disabled was changed. |
+| 650 | A member was added to a security-disabled local security group. |
+| 651 | A member was removed from a security-disabled local security group. |
+| 652 | A security-disabled local group was deleted. |
+| 653 | A security-disabled global group was created. |
+| 645 | A security-disabled global group was changed. |
+| 655 | A member was added to a security-disabled global group. |
+| 656 | A member was removed from a security-disabled global group. |
+| 657 | A security-disabled global group was deleted. |
+| 658 | A security-enabled universal group was created. |
+| 659 | A security-enabled universal group was changed. |
+| 660 | A member was added to a security-enabled universal group. |
+| 661 | A member was removed from a security-enabled universal group. |
+| 662 | A security-enabled universal group was deleted. |
+| 663 | A security-disabled universal group was created. |
+| 664 | A security-disabled universal group was changed. |
+| 665 | A member was added to a security-disabled universal group. |
+| 666 | A member was removed from a security-disabled universal group. |
+| 667 | A security-disabled universal group was deleted. |
+| 668 | A group type was changed. |
+| 684 | Set the security descriptor of members of administrative groups. |
+| 685 | Set the security descriptor of members of administrative groups.
**Note:** Every 60 minutes on a domain controller a background thread searches all members of administrative groups (such as domain, enterprise, and schema administrators) and applies a fixed security descriptor on them. This event is logged.|
- |
-
-
-| 649 |
-A local security group with security disabled was changed. |
-
-
-| 650 |
-A member was added to a security-disabled local security group. |
-
-
-| 651 |
-A member was removed from a security-disabled local security group. |
-
-
-| 652 |
-A security-disabled local group was deleted. |
-
-
-| 653 |
-A security-disabled global group was created. |
-
-
-| 645 |
-A security-disabled global group was changed. |
-
-
-| 655 |
-A member was added to a security-disabled global group. |
-
-
-| 656 |
-A member was removed from a security-disabled global group. |
-
-
-| 657 |
-A security-disabled global group was deleted. |
-
-
-| 658 |
-A security-enabled universal group was created. |
-
-
-| 659 |
-A security-enabled universal group was changed. |
-
-
-| 660 |
-A member was added to a security-enabled universal group. |
-
-
-| 661 |
-A member was removed from a security-enabled universal group. |
-
-
-| 662 |
-A security-enabled universal group was deleted. |
-
-
-| 663 |
-A security-disabled universal group was created. |
-
-
-| 664 |
-A security-disabled universal group was changed. |
-
-
-| 665 |
-A member was added to a security-disabled universal group. |
-
-
-| 666 |
-A member was removed from a security-disabled universal group. |
-
-
-| 667 |
-A security-disabled universal group was deleted. |
-
-
-| 668 |
-A group type was changed. |
-
-
-| 684 |
-Set the security descriptor of members of administrative groups. |
-
-
-| 685 |
-Set the security descriptor of members of administrative groups.
-
-Note Every 60 minutes on a domain controller a background thread searches all members of administrative groups (such as domain, enterprise, and schema administrators) and applies a fixed security descriptor on them. This event is logged.
-
-
-
- |
-
-
-
-
-
-
## Related topics
-
-[Basic security audit policy settings](basic-security-audit-policy-settings.md)
-
+- [Basic security audit policy settings](basic-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/basic-audit-directory-service-access.md b/windows/keep-secure/basic-audit-directory-service-access.md
index 25799f59ea..0d48b78b27 100644
--- a/windows/keep-secure/basic-audit-directory-service-access.md
+++ b/windows/keep-secure/basic-audit-directory-service-access.md
@@ -5,38 +5,29 @@ ms.assetid: 52F02EED-3CFE-4307-8D06-CF1E27693D09
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit directory service access
-
**Applies to**
-
- Windows 10
-\[Some information relates to pre-released product, which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.\]
-
Determines whether to audit the event of a user accessing an Active Directory object that has its own system access control list (SACL) specified.
By default, this value is set to no auditing in the Default Domain Controller Group Policy object (GPO), and it remains undefined for workstations and servers where it has no meaning.
If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when a user successfully accesses an Active Directory object that has a SACL specified. Failure audits generate an audit entry when a user unsuccessfully attempts to access an Active Directory object that has a SACL specified. To set this value to **No auditing,** in the **Properties** dialog box for this policy setting, select the **Define these policy settings** check box and clear the **Success** and **Failure** check boxes.
-
-**Note**
-You can set a SACL on an Active Directory object by using the **Security** tab in that object's **Properties** dialog box. This is the same as Audit object access, except that it applies only to Active Directory objects and not to file system and registry objects.
-
+> **Note:** You can set a SACL on an Active Directory object by using the **Security** tab in that object's **Properties** dialog box. This is the same as Audit object access, except that it applies only to Active Directory objects and not to file system and registry objects.
-
**Default:**
- Success on domain controllers.
-
- Undefined for a member server.
## Configure this audit setting
-
You can configure this security setting under Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Audit Policy.
There is only one directory service access event, which is identical to the Object Access security event message 566.
@@ -44,19 +35,9 @@ There is only one directory service access event, which is identical to the Obje
| Directory service access events | Description |
|---------------------------------|----------------------------------------|
| 566 | A generic object operation took place. |
-
-
## Related topics
-
-[Basic security audit policy settings](basic-security-audit-policy-settings.md)
-
+- [Basic security audit policy settings](basic-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/basic-audit-logon-events.md b/windows/keep-secure/basic-audit-logon-events.md
index 27d4e90250..d83d80357e 100644
--- a/windows/keep-secure/basic-audit-logon-events.md
+++ b/windows/keep-secure/basic-audit-logon-events.md
@@ -5,18 +5,15 @@ ms.assetid: 78B5AFCB-0BBD-4C38-9FE9-6B4571B94A35
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit logon events
-
**Applies to**
-
- Windows 10
-\[Some information relates to pre-released product, which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.\]
-
Determines whether to audit each instance of a user logging on to or logging off from a device.
Account logon events are generated on domain controllers for domain account activity and on local devices for local account activity. If both account logon and logon audit policy categories are enabled, logons that use a domain account generate a logon or logoff event on the workstation or server, and they generate an account logon event on the domain controller. Additionally, interactive logons to a member server or workstation that use a domain account generate a logon event on the domain controller as the logon scripts and policies are retrieved when a user logs on. For more info about account logon events, see [Audit account logon events](basic-audit-account-logon-events.md).
@@ -27,11 +24,10 @@ To set this value to **No auditing**, in the **Properties** dialog box for this
## Configure this audit setting
-
You can configure this security setting by opening the appropriate policy under Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Audit Policy.
-| Logon events | Description |
-|--------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Logon events | Description |
+| - | - |
| 528 | A user successfully logged on to a computer. For information about the type of logon, see the Logon Types table below. |
| 529 | Logon failure. A logon attempt was made with an unknown user name or a known user name with a bad password. |
| 530 | Logon failure. A logon attempt was made user account tried to log on outside of the allowed time. |
@@ -59,35 +55,24 @@ You can configure this security setting by opening the appropriate policy under
| 552 | A user successfully logged on to a computer using explicit credentials while already logged on as a different user. |
| 682 | A user has reconnected to a disconnected terminal server session. |
| 683 | A user disconnected a terminal server session without logging off. |
-
When event 528 is logged, a logon type is also listed in the event log. The following table describes each logon type.
-| Logon type | Logon title | Description |
-|------------|-------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| 2 | Interactive | A user logged on to this computer. |
-| 3 | Network | A user or computer logged on to this computer from the network. |
-| 4 | Batch | Batch logon type is used by batch servers, where processes may be executing on behalf of a user without their direct intervention. |
-| 5 | Service | A service was started by the Service Control Manager. |
-| 7 | Unlock | This workstation was unlocked. |
+| Logon type | Logon title | Description |
+| - | - | - |
+| 2 | Interactive | A user logged on to this computer.|
+| 3 | Network | A user or computer logged on to this computer from the network.|
+| 4 | Batch | Batch logon type is used by batch servers, where processes may be executing on behalf of a user without their direct intervention.|
+| 5 | Service | A service was started by the Service Control Manager.|
+| 7 | Unlock | This workstation was unlocked.|
| 8 | NetworkCleartext | A user logged on to this computer from the network. The user's password was passed to the authentication package in its unhashed form. The built-in authentication packages all hash credentials before sending them across the network. The credentials do not traverse the network in plaintext (also called cleartext). |
-| 9 | NewCredentials | A caller cloned its current token and specified new credentials for outbound connections. The new logon session has the same local identity, but uses different credentials for other network connections. |
-| 10 | RemoteInteractive | A user logged on to this computer remotely using Terminal Services or Remote Desktop. |
-| 11 | CachedInteractive | A user logged on to this computer with network credentials that were stored locally on the computer. The domain controller was not contacted to verify the credentials. |
-
+| 9 | NewCredentials | A caller cloned its current token and specified new credentials for outbound connections. The new logon session has the same local identity, but uses different credentials for other network connections.|
+| 10 | RemoteInteractive | A user logged on to this computer remotely using Terminal Services or Remote Desktop.|
+| 11 | CachedInteractive | A user logged on to this computer with network credentials that were stored locally on the computer. The domain controller was not contacted to verify the credentials.|
-
## Related topics
-
-[Basic security audit policy settings](basic-security-audit-policy-settings.md)
-
+- [Basic security audit policy settings](basic-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/basic-audit-object-access.md b/windows/keep-secure/basic-audit-object-access.md
index 84b7afbcea..6ae03e3c93 100644
--- a/windows/keep-secure/basic-audit-object-access.md
+++ b/windows/keep-secure/basic-audit-object-access.md
@@ -5,14 +5,13 @@ ms.assetid: D15B6D67-7886-44C2-9972-3F192D5407EA
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit object access
-
**Applies to**
-
- Windows 10
Determines whether to audit the event of a user accessing an object--for example, a file, folder, registry key, printer, and so forth--that has its own system access control list (SACL) specified.
@@ -21,226 +20,60 @@ If you define this policy setting, you can specify whether to audit successes, a
To set this value to **No auditing**, in the **Properties** dialog box for this policy setting, select the Define these policy settings check box and clear the **Success** and **Failure** check boxes.
-**Note** You can set a SACL on a file system object using the **Security** tab in that object's **Properties** dialog box.
-
+> **Note:** You can set a SACL on a file system object using the **Security** tab in that object's **Properties** dialog box.
-
**Default:** No auditing.
## Configure this audit setting
-
You can configure this security setting by opening the appropriate policy under Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Audit Policy.
-
-
-
-
-
-
-
-
-
-
-| 560 |
-Access was granted to an already existing object. |
-
-
-| 562 |
-A handle to an object was closed. |
-
-
-| 563 |
-An attempt was made to open an object with the intent to delete it.
-
-Note This is used by file systems when the FILE_DELETE_ON_CLOSE flag is specified in Createfile().
-
-
-
- |
-
-
-| 564 |
-A protected object was deleted. |
-
-
-| 565 |
-Access was granted to an already existing object type. |
-
-
-| 567 |
-A permission associated with a handle was used.
-
-Note A handle is created with certain granted permissions (Read, Write, and so on). When the handle is used, up to one audit is generated for each of the permissions that was used.
-
-
-
- |
-
-
-| 568 |
-An attempt was made to create a hard link to a file that is being audited. |
-
-
-| 569 |
-The resource manager in Authorization Manager attempted to create a client context. |
-
-
-| 570 |
-A client attempted to access an object.
-
-Note An event will be generated for every attempted operation on the object.
-
-
-
- |
-
-
-| 571 |
-The client context was deleted by the Authorization Manager application. |
-
-
-| 572 |
-The administrator manager initialized the application. |
-
-
-| 772 |
-The certificate manager denied a pending certificate request. |
-
-
-| 773 |
-Certificate Services received a resubmitted certificate request. |
-
-
-| 774 |
-Certificate Services revoked a certificate. |
-
-
-| 775 |
-Certificate Services received a request to publish the certificate revocation list (CRL). |
-
-
-| 776 |
-Certificate Services published the certificate revocation list (CRL). |
-
-
-| 777 |
-A certificate request extension was made. |
-
-
-| 778 |
-One or more certificate request attributes changed. |
-
-
-| 779 |
-Certificate Services received a request to shutdown. |
-
-
-| 780 |
-Certificate Services backup started. |
-
-
-| 781 |
-Certificate Services backup completed |
-
-
-| 782 |
-Certificate Services restore started. |
-
-
-| 783 |
-Certificate Services restore completed. |
-
-
-| 784 |
-Certificate Services started. |
-
-
-| 785 |
-Certificate Services stopped. |
-
-
-| 786 |
-The security permissions for Certificate Services changed. |
-
-
-| 787 |
-Certificate Services retrieved an archived key. |
-
-
-| 788 |
-Certificate Services imported a certificate into its database. |
-
-
-| 789 |
-The audit filter for Certificate Services changed. |
-
-
-| 790 |
-Certificate Services received a certificate request. |
-
-
-| 791 |
-Certificate Services approved a certificate request and issued a certificate. |
-
-
-| 792 |
-Certificate Services denied a certificate request. |
-
-
-| 793 |
-Certificate Services set the status of a certificate request to pending. |
-
-
-| 794 |
-The certificate manager settings for Certificate Services changed. |
-
-
-| 795 |
-A configuration entry changed in Certificate Services. |
-
-
-| 796 |
-A property of Certificate Services changed. |
-
-
-| 797 |
-Certificate Services archived a key. |
-
-
-| 798 |
-Certificate Services imported and archived a key. |
-
-
-| 799 |
-Certificate Services published the CA certificate to Active Directory. |
-
-
-| 800 |
-One or more rows have been deleted from the certificate database. |
-
-
-| 801 |
-Role separation enabled. |
-
-
-
-
-
+| Object access events | Description |
+| - | - |
+| 560 | Access was granted to an already existing object.|
+| 562 | A handle to an object was closed. |
+| 563 | An attempt was made to open an object with the intent to delete it.
**Note: ** This is used by file systems when the FILE_DELETE_ON_CLOSE flag is specified in Createfile().||
+| 564 | A protected object was deleted. |
+| 565 | Access was granted to an already existing object type.|
+| 567 | A permission associated with a handle was used.
**Note: ** A handle is created with certain granted permissions (Read, Write, and so on). When the handle is used, up to one audit is generated for each of the permissions that was used.|
+| 568 | An attempt was made to create a hard link to a file that is being audited. |
+| 569 | The resource manager in Authorization Manager attempted to create a client context.|
+| 570 | A client attempted to access an object.
**Note:** An event will be generated for every attempted operation on the object.|
+| 571 | The client context was deleted by the Authorization Manager application. |
+| 572 | The administrator manager initialized the application. |
+| 772 | The certificate manager denied a pending certificate request.|
+| 773 | Certificate Services received a resubmitted certificate request.|
+| 774 | Certificate Services revoked a certificate.|
+| 775 | Certificate Services received a request to publish the certificate revocation list (CRL).|
+| 776 | Certificate Services published the certificate revocation list (CRL). |
+| 777 | A certificate request extension was made. |
+| 778 | One or more certificate request attributes changed.|
+| 779 | Certificate Services received a request to shutdown.|
+| 780 | Certificate Services backup started. |
+| 781 | Certificate Services backup completed |
+| 782 | Certificate Services restore started. |
+| 783 | Certificate Services restore completed.|
+| 784 | Certificate Services started. |
+| 785 | Certificate Services stopped. |
+| 786 | The security permissions for Certificate Services changed.|
+| 787 | Certificate Services retrieved an archived key. |
+| 788 | Certificate Services imported a certificate into its database.|
+| 789 | The audit filter for Certificate Services changed. |
+| 790 | Certificate Services received a certificate request.|
+| 791 | Certificate Services approved a certificate request and issued a certificate.|
+| 792 | Certificate Services denied a certificate request. |
+| 793 | Certificate Services set the status of a certificate request to pending.|
+| 794 | The certificate manager settings for Certificate Services changed. |
+| 795 | A configuration entry changed in Certificate Services. |
+| 796 | A property of Certificate Services changed. |
+| 797 | Certificate Services archived a key. |
+| 798 | Certificate Services imported and archived a key.|
+| 799 | Certificate Services published the CA certificate to Active Directory.|
+| 800 | One or more rows have been deleted from the certificate database. |
+| 801 | Role separation enabled. |
## Related topics
-
-[Basic security audit policy settings](basic-security-audit-policy-settings.md)
-
+- [Basic security audit policy settings](basic-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/basic-audit-policy-change.md b/windows/keep-secure/basic-audit-policy-change.md
index 48eb4dc41b..0590d832ee 100644
--- a/windows/keep-secure/basic-audit-policy-change.md
+++ b/windows/keep-secure/basic-audit-policy-change.md
@@ -5,14 +5,13 @@ ms.assetid: 1025A648-6B22-4C85-9F47-FE0897F1FA31
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit policy change
-
**Applies to**
-
- Windows 10
Determines whether to audit every incident of a change to user rights assignment policies, audit policies, or trust policies.
@@ -24,149 +23,38 @@ To set this value to **No auditing**, in the **Properties** dialog box for this
**Default:**
- Success on domain controllers.
-
- No auditing on member servers.
## Configure this audit setting
-
You can configure this security setting under Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Audit Policy.
-
-
-
-
-
-
-
-
-
-
-| 608 |
-A user right was assigned. |
-
-
-| 609 |
-A user right was removed. |
-
-
-| 610 |
-A trust relationship with another domain was created. |
-
-
-| 611 |
-A trust relationship with another domain was removed. |
-
-
-| 612 |
-An audit policy was changed. |
-
-
-| 613 |
-An Internet Protocol security (IPSec) policy agent started. |
-
-
-| 614 |
-An IPSec policy agent was disabled. |
-
-
-| 615 |
-An IPSec policy agent changed. |
-
-
-| 616 |
-An IPSec policy agent encountered a potentially serious failure. |
-
-
-| 617 |
-A Kerberos policy changed. |
-
-
-| 618 |
-Encrypted Data Recovery policy changed. |
-
-
-| 620 |
-A trust relationship with another domain was modified. |
-
-
-| 621 |
-System access was granted to an account. |
-
-
-| 622 |
-System access was removed from an account. |
-
-
-| 623 |
-Per user auditing policy was set for a user. |
-
-
-| 625 |
-Per user audit policy was refreshed. |
-
-
-| 768 |
-A collision was detected between a namespace element in one forest and a namespace element in another forest.
-
-Note When a namespace element in one forest overlaps a namespace element in another forest, it can lead to ambiguity in resolving a name belonging to one of the namespace elements. This overlap is also called a collision. Not all parameters are valid for each entry type. For example, fields such as DNS name, NetBIOS name, and SID are not valid for an entry of type 'TopLevelName'.
-
-
+| Policy change events | Description |
+| - | - |
+| 608 | A user right was assigned.|
+| 609 | A user right was removed. |
+| 610 | A trust relationship with another domain was created.|
+| 611 | A trust relationship with another domain was removed.|
+| 612 | An audit policy was changed.|
+| 613 | An Internet Protocol security (IPSec) policy agent started.|
+| 614 | An IPSec policy agent was disabled. |
+| 615 | An IPSec policy agent changed. |
+| 616 | An IPSec policy agent encountered a potentially serious failure.|
+| 617 | A Kerberos policy changed. |
+| 618 | Encrypted Data Recovery policy changed.|
+| 620 | A trust relationship with another domain was modified.|
+| 621 | System access was granted to an account. |
+| 622 | System access was removed from an account.|
+| 623 | Per user auditing policy was set for a user.|
+| 625 | Per user audit policy was refreshed. |
+| 768 | A collision was detected between a namespace element in one forest and a namespace element in another forest.
**Note** When a namespace element in one forest overlaps a namespace element in another forest, it can lead to ambiguity in resolving a name belonging to one of the namespace elements. This overlap is also called a collision. Not all parameters are valid for each entry type. For example, fields such as DNS name, NetBIOS name, and SID are not valid for an entry of type 'TopLevelName'.|
+| 769 | Trusted forest information was added.
**Note:** This event message is generated when forest trust information is updated and one or more entries are added. One event message is generated per added, deleted, or modified entry. If multiple entries are added, deleted, or modified in a single update of the forest trust information, all the generated event messages have a single unique identifier called an operation ID. This allows you to determine that the multiple generated event messages are the result of a single operation. Not all parameters are valid for each entry type. For example, parameters such as DNS name, NetBIOS name and SID are not valid for an entry of type "TopLevelName".|
+| 770 | Trusted forest information was deleted.
**Note:** This event message is generated when forest trust information is updated and one or more entries are added. One event message is generated per added, deleted, or modified entry. If multiple entries are added, deleted, or modified in a single update of the forest trust information, all the generated event messages have a single unique identifier called an operation ID. This allows you to determine that the multiple generated event messages are the result of a single operation. Not all parameters are valid for each entry type. For example, parameters such as DNS name, NetBIOS name and SID are not valid for an entry of type "TopLevelName".|
+| 771 | Trusted forest information was modified.
**Note:** This event message is generated when forest trust information is updated and one or more entries are added. One event message is generated per added, deleted, or modified entry. If multiple entries are added, deleted, or modified in a single update of the forest trust information, all the generated event messages have a single unique identifier called an operation ID. This allows you to determine that the multiple generated event messages are the result of a single operation. Not all parameters are valid for each entry type. For example, parameters such as DNS name, NetBIOS name and SID are not valid for an entry of type "TopLevelName".|
+| 805 | The event log service read the security log configuration for a session.
- |
-
-
-| 769 |
-Trusted forest information was added.
-
-Note This event message is generated when forest trust information is updated and one or more entries are added. One event message is generated per added, deleted, or modified entry. If multiple entries are added, deleted, or modified in a single update of the forest trust information, all the generated event messages have a single unique identifier called an operation ID. This allows you to determine that the multiple generated event messages are the result of a single operation. Not all parameters are valid for each entry type. For example, parameters such as DNS name, NetBIOS name and SID are not valid for an entry of type "TopLevelName".
-
-
-
- |
-
-
-| 770 |
-Trusted forest information was deleted.
-
-Note This event message is generated when forest trust information is updated and one or more entries are added. One event message is generated per added, deleted, or modified entry. If multiple entries are added, deleted, or modified in a single update of the forest trust information, all the generated event messages have a single unique identifier called an operation ID. This allows you to determine that the multiple generated event messages are the result of a single operation. Not all parameters are valid for each entry type. For example, parameters such as DNS name, NetBIOS name and SID are not valid for an entry of type "TopLevelName".
-
-
-
- |
-
-
-| 771 |
-Trusted forest information was modified.
-
-Note This event message is generated when forest trust information is updated and one or more entries are added. One event message is generated per added, deleted, or modified entry. If multiple entries are added, deleted, or modified in a single update of the forest trust information, all the generated event messages have a single unique identifier called an operation ID. This allows you to determine that the multiple generated event messages are the result of a single operation. Not all parameters are valid for each entry type. For example, parameters such as DNS name, NetBIOS name and SID are not valid for an entry of type "TopLevelName".
-
-
-
- |
-
-
-| 805 |
-The event log service read the security log configuration for a session. |
-
-
-
-
-
-
## Related topics
-
-[Basic security audit policy settings](basic-security-audit-policy-settings.md)
-
+- [Basic security audit policy settings](basic-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/basic-audit-privilege-use.md b/windows/keep-secure/basic-audit-privilege-use.md
index bf1b98b716..38a2117169 100644
--- a/windows/keep-secure/basic-audit-privilege-use.md
+++ b/windows/keep-secure/basic-audit-privilege-use.md
@@ -5,14 +5,13 @@ ms.assetid: C5C6DAAF-8B58-4DFB-B1CE-F0675AE0E9F8
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit privilege use
-
**Applies to**
-
- Windows 10
Determines whether to audit each instance of a user exercising a user right.
@@ -26,69 +25,25 @@ To set this value to **No auditing**, in the **Properties** dialog box for this
Audits are not generated for use of the following user rights, even if success audits or failure audits are specified for **Audit privilege use**. Enabling auditing of these user rights tend to generate many events in the security log which may impede your computer's performance. To audit the following user rights, enable the **FullPrivilegeAuditing** registry key.
- Bypass traverse checking
-
- Debug programs
-
- Create a token object
-
- Replace process level token
-
- Generate security audits
-
- Back up files and directories
-
- Restore files and directories
## Configure this audit setting
-
You can configure this security setting under Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Audit Policy.
-
-
-
-
-
-
-
-
-
-
-| 576 |
-Specified privileges were added to a user's access token.
-
-Note This event is generated when the user logs on.
-
-
+| Privilege use events | Description |
+| - | - |
+| 576 | Specified privileges were added to a user's access token.
**Note:** This event is generated when the user logs on.|
+| 577 | A user attempted to perform a privileged system service operation. |
+| 578 | Privileges were used on an already open handle to a protected object. |
- |
-
-
-| 577 |
-A user attempted to perform a privileged system service operation. |
-
-
-| 578 |
-Privileges were used on an already open handle to a protected object. |
-
-
-
-
-
-
## Related topics
-
-[Basic security audit policy settings](basic-security-audit-policy-settings.md)
-
+- [Basic security audit policy settings](basic-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/basic-audit-process-tracking.md b/windows/keep-secure/basic-audit-process-tracking.md
index d0efa7d0b8..9fd272a03c 100644
--- a/windows/keep-secure/basic-audit-process-tracking.md
+++ b/windows/keep-secure/basic-audit-process-tracking.md
@@ -5,14 +5,13 @@ ms.assetid: 91AC5C1E-F4DA-4B16-BEE2-C92D66E4CEEA
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit process tracking
-
**Applies to**
-
- Windows 10
Determines whether to audit detailed tracking information for events such as program activation, process exit, handle duplication, and indirect object access.
@@ -25,86 +24,24 @@ To set this value to **No auditing**, in the **Properties** dialog box for this
## Configure this this security setting
-
You can configure this security setting under Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Audit Policy.
-
-
-
-
-
-
-
-
-
-
-| 592 |
-A new process was created. |
-
-
-| 593 |
-A process exited. |
-
-
-| 594 |
-A handle to an object was duplicated. |
-
-
-| 595 |
-Indirect access to an object was obtained. |
-
-
-| 596 |
-A data protection master key was backed up.
-
-Note The master key is used by the CryptProtectData and CryptUnprotectData routines, and Encrypting File System (EFS). The master key is backed up each time a new one is created. (The default setting is 90 days.) The key is usually backed up to a domain controller.
-
-
+| Process tracking events | Description |
+| - | - |
+| 592 | A new process was created.|
+| 593 | A process exited. |
+| 594 | A handle to an object was duplicated.|
+| 595 | Indirect access to an object was obtained.|
+| 596 | A data protection master key was backed up.
**Note:** The master key is used by the CryptProtectData and CryptUnprotectData routines, and Encrypting File System (EFS). The master key is backed up each time a new one is created. (The default setting is 90 days.) The key is usually backed up to a domain controller.|
+| 597 | A data protection master key was recovered from a recovery server.|
+| 598 | Auditable data was protected. |
+| 599 | Auditable data was unprotected.|
+| 600 | A process was assigned a primary token.|
+| 601 | A user attempted to install a service. |
+| 602 | A scheduler job was created. |
- |
-
-
-| 597 |
-A data protection master key was recovered from a recovery server. |
-
-
-| 598 |
-Auditable data was protected. |
-
-
-| 599 |
-Auditable data was unprotected. |
-
-
-| 600 |
-A process was assigned a primary token. |
-
-
-| 601 |
-A user attempted to install a service. |
-
-
-| 602 |
-A scheduler job was created. |
-
-
-
-
-
-
## Related topics
-
-[Basic security audit policy settings](basic-security-audit-policy-settings.md)
-
+- [Basic security audit policy settings](basic-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/basic-audit-system-events.md b/windows/keep-secure/basic-audit-system-events.md
index 34f4206e90..7724e17654 100644
--- a/windows/keep-secure/basic-audit-system-events.md
+++ b/windows/keep-secure/basic-audit-system-events.md
@@ -5,14 +5,13 @@ ms.assetid: BF27588C-2AA7-4365-A4BF-3BB377916447
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Audit system events
-
**Applies to**
-
- Windows 10
Determines whether to audit when a user restarts or shuts down the computer or when an event occurs that affects either the system security or the security log.
@@ -24,83 +23,26 @@ To set this value to **No auditing**, in the **Properties** dialog box for this
**Default:**
- Success on domain controllers.
-
- No auditing on member servers.
## Configure this audit setting
-
You can configure this security setting by opening the appropriate policy under Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Audit Policy.
-
-
-
-
-
-
-
-
-
-
-| 512 |
-Windows is starting up. |
-
-
-| 513 |
-Windows is shutting down. |
-
-
-| 514 |
-An authentication package was loaded by the Local Security Authority. |
-
-
-| 515 |
-A trusted logon process has registered with the Local Security Authority. |
-
-
-| 516 |
-Internal resources allocated for the queuing of security event messages have been exhausted, leading to the loss of some security event messages. |
-
-
-| 517 |
-The audit log was cleared. |
-
-
-| 518 |
-A notification package was loaded by the Security Accounts Manager. |
-
-
-| 519 |
-A process is using an invalid local procedure call (LPC) port in an attempt to impersonate a client and reply or read from or write to a client address space. |
-
-
-| 520 |
-The system time was changed.
-
-Note This audit normally appears twice.
-
-
-
- |
-
-
-
-
-
+| Logon events | Description |
+| - | - |
+| 512 | Windows is starting up. |
+| 513 | Windows is shutting down. |
+| 514 | An authentication package was loaded by the Local Security Authority.|
+| 515 | A trusted logon process has registered with the Local Security Authority.|
+| 516 | Internal resources allocated for the queuing of security event messages have been exhausted, leading to the loss of some security event messages.|
+| 517 | The audit log was cleared. |
+| 518 | A notification package was loaded by the Security Accounts Manager.|
+| 519 | A process is using an invalid local procedure call (LPC) port in an attempt to impersonate a client and reply or read from or write to a client address space.|
+| 520 | The system time was changed.
**Note:** This audit normally appears twice.|
## Related topics
-
-[Basic security audit policy settings](basic-security-audit-policy-settings.md)
-
+- [Basic security audit policy settings](basic-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/basic-security-audit-policies.md b/windows/keep-secure/basic-security-audit-policies.md
index 8aaba83b70..0ad34f0790 100644
--- a/windows/keep-secure/basic-security-audit-policies.md
+++ b/windows/keep-secure/basic-security-audit-policies.md
@@ -5,14 +5,13 @@ ms.assetid: 3B678568-7AD7-4734-9BB4-53CF5E04E1D3
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Basic security audit policies
-
**Applies to**
-
- Windows 10
Before you implement auditing, you must decide on an auditing policy. A basic audit policy specifies categories of security-related events that you want to audit. When this version of Windows is first installed, all auditing categories are disabled. By enabling various auditing event categories, you can implement an auditing policy that suits the security needs of your organization.
@@ -33,45 +32,11 @@ If you choose to audit access to objects as part of your audit policy, you must
## In this section
-
-
-
-
-
-
-
-
-
-
-
-[Create a basic audit policy for an event category](create-a-basic-audit-policy-settings-for-an-event-category.md) |
-By defining auditing settings for specific event categories, you can create an auditing policy that suits the security needs of your organization. On devices that are joined to a domain, auditing settings for the event categories are undefined by default. On domain controllers, auditing is turned on by default. |
-
-
-[Apply a basic audit policy on a file or folder](apply-a-basic-audit-policy-on-a-file-or-folder.md) |
-You can apply audit policies to individual files and folders on your computer by setting the permission type to record successful access attempts or failed access attempts in the security log. |
-
-
-[View the security event log](view-the-security-event-log.md) |
-The security log records each event as defined by the audit policies you set on each object. |
-
-
-[Basic security audit policy settings](basic-security-audit-policy-settings.md) |
-Basic security audit policy settings are found under Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy. |
-
-
-
-
+| Topic | Description |
+| - | - |
+| [Create a basic audit policy for an event category](create-a-basic-audit-policy-settings-for-an-event-category.md) | By defining auditing settings for specific event categories, you can create an auditing policy that suits the security needs of your organization. On devices that are joined to a domain, auditing settings for the event categories are undefined by default. On domain controllers, auditing is turned on by default. |
+| [Apply a basic audit policy on a file or folder](apply-a-basic-audit-policy-on-a-file-or-folder.md) | You can apply audit policies to individual files and folders on your computer by setting the permission type to record successful access attempts or failed access attempts in the security log. |
+| [View the security event log](view-the-security-event-log.md) | The security log records each event as defined by the audit policies you set on each object.|
+| [Basic security audit policy settings](basic-security-audit-policy-settings.md) | Basic security audit policy settings are found under Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy.|
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/basic-security-audit-policy-settings.md b/windows/keep-secure/basic-security-audit-policy-settings.md
index f59bbe3000..eeade033ce 100644
--- a/windows/keep-secure/basic-security-audit-policy-settings.md
+++ b/windows/keep-secure/basic-security-audit-policy-settings.md
@@ -5,84 +5,33 @@ ms.assetid: 31C2C453-2CFC-4D9E-BC88-8CE1C1A8F900
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Basic security audit policy settings
-
**Applies to**
-
- Windows 10
Basic security audit policy settings are found under Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Audit Policy.
## In this section
-
-
-
-
-
-
-
-
-
-
-
-[Audit account logon events](basic-audit-account-logon-events.md) |
-Determines whether to audit each instance of a user logging on to or logging off from another device in which this device is used to validate the account. |
-
-
-[Audit account management](basic-audit-account-management.md) |
-Determines whether to audit each event of account management on a device. |
-
-
-[Audit directory service access](basic-audit-directory-service-access.md) |
-Determines whether to audit the event of a user accessing an Active Directory object that has its own system access control list (SACL) specified. |
-
-
-[Audit logon events](basic-audit-logon-events.md) |
-Determines whether to audit each instance of a user logging on to or logging off from a device. |
-
-
-[Audit object access](basic-audit-object-access.md) |
-Determines whether to audit the event of a user accessing an object--for example, a file, folder, registry key, printer, and so forth--that has its own system access control list (SACL) specified. |
-
-
-[Audit policy change](basic-audit-policy-change.md) |
-Determines whether to audit every incident of a change to user rights assignment policies, audit policies, or trust policies. |
-
-
-[Audit privilege use](basic-audit-privilege-use.md) |
-Determines whether to audit each instance of a user exercising a user right. |
-
-
-[Audit process tracking](basic-audit-process-tracking.md) |
-Determines whether to audit detailed tracking information for events such as program activation, process exit, handle duplication, and indirect object access. |
-
-
-[Audit system events](basic-audit-system-events.md) |
-Determines whether to audit when a user restarts or shuts down the computer or when an event occurs that affects either the system security or the security log. |
-
-
-
-
+| Topic | Description |
+| - | - |
+| [Audit account logon events](basic-audit-account-logon-events.md) | Determines whether to audit each instance of a user logging on to or logging off from another device in which this device is used to validate the account.|
+| [Audit account management](basic-audit-account-management.md) | Determines whether to audit each event of account management on a device.|
+| [Audit directory service access](basic-audit-directory-service-access.md) | Determines whether to audit the event of a user accessing an Active Directory object that has its own system access control list (SACL) specified.|
+| [Audit logon events](basic-audit-logon-events.md) | Determines whether to audit each instance of a user logging on to or logging off from a device. |
+| [Audit object access](basic-audit-object-access.md) | Determines whether to audit the event of a user accessing an object--for example, a file, folder, registry key, printer, and so forth--that has its own system access control list (SACL) specified.|
+| [Audit policy change](basic-audit-policy-change.md) | Determines whether to audit every incident of a change to user rights assignment policies, audit policies, or trust policies. |
+| [Audit privilege use](basic-audit-privilege-use.md) | Determines whether to audit each instance of a user exercising a user right. |
+| [Audit process tracking](basic-audit-process-tracking.md) | Determines whether to audit detailed tracking information for events such as program activation, process exit, handle duplication, and indirect object access.|
+| [Audit system events](basic-audit-system-events.md) | Determines whether to audit when a user restarts or shuts down the computer or when an event occurs that affects either the system security or the security log. |
-
## Related topics
-
-[Basic security audit policy settings](basic-security-audit-policy-settings.md)
-
+- [Basic security audit policy settings](basic-security-audit-policy-settings.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/bcd-settings-and-bitlocker.md b/windows/keep-secure/bcd-settings-and-bitlocker.md
index c245fc0a1b..bee0c9e8f3 100644
--- a/windows/keep-secure/bcd-settings-and-bitlocker.md
+++ b/windows/keep-secure/bcd-settings-and-bitlocker.md
@@ -5,14 +5,13 @@ ms.assetid: c4ab7ac9-16dc-4c7e-b061-c0b0deb2c4fa
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# BCD settings and BitLocker
-
**Applies to**
-
- Windows 10
This topic for IT professionals describes the BCD settings that are used by BitLocker.
@@ -21,7 +20,6 @@ When protecting data at rest on an operating system volume, during the boot proc
## BitLocker and BCD Settings
-
In Windows 7 and Windows Server 2008 R2, BitLocker validated nearly all BCD settings with the winload, winresume, and memtest prefixes. However, this high degree of validation caused BitLocker to go into recovery mode for benign setting changes, for example, when applying a language pack BitLocker would enter recovery.
In Windows 8, Windows Server 2012, and later operating systems BitLocker narrows the set of BCD settings validated to reduce the chance of benign changes causing a BCD validation problem. If you believe that there is a risk in excluding a particular BCD setting from the validation profile, you can increase BCD validation coverage to suit your validation preferences. Alternatively, if a default BCD setting is persistently triggering recovery for benign changes, then you can exclude that BCD setting from the validation profile.
@@ -34,17 +32,13 @@ One of the benefits of using Secure Boot is that it can correct BCD settings dur
## Customizing BCD validation settings
-
To modify the BCD settings BitLocker validates the IT Pro will add or exclude BCD settings from the platform validation profile by enabling and configuring the **Use enhanced Boot Configuration Data validation profile** Group Policy setting.
For the purposes of BitLocker validation, BCD settings are associated with a specific set of Microsoft boot applications. BCD settings are either associated with a specific boot application or can apply to all boot applications by associating a prefix to the BCD setting entered in the Group Policy setting. Prefix values include:
- winload
-
- winresume
-
- memtest
-
- all
All BCD settings are specified by combining the prefix value with either a hexadecimal (hex) value or a “friendly name.”
@@ -58,948 +52,201 @@ Not all BCD settings have friendly names, for those settings the hex value is th
When specifying BCD values in the **Use enhanced Boot Configuration Data validation profile** Group Policy setting, use the following syntax:
- Prefix the setting with the boot application prefix
-
- Append a colon ‘:’
-
- Append either the hex value or the friendly name
-
- If entering more than one BCD setting, you will need to enter each BCD setting on a new line
For example, either “`winload:hypervisordebugport`” or “`winload:0x250000f4`” yield the same value.
Setting that applies to all boot applications may be applied only to an individual application, however the reverse is not true. For example, one can specify either: “`all:locale`” or “`winresume:locale`”, but as the bcd setting “`win-pe`” does not apply to all boot applications, “`winload:winpe`” is valid, but “`all:winpe`” is not valid. The setting that controls boot debugging (“`bootdebug`” or 0x16000010) will always be validated and will have no effect if it is included in the provided fields.
-**Note**
-Take care when configuring BCD entries in the Group Policy setting. The Local Group Policy Editor does not validate the correctness of the BCD entry. BitLocker will fail to be enabled if the Group Policy setting specified is invalid.
-
+> **Note:** Take care when configuring BCD entries in the Group Policy setting. The Local Group Policy Editor does not validate the correctness of the BCD entry. BitLocker will fail to be enabled if the Group Policy setting specified is invalid.
-
### Default BCD validation profile
The following table contains the default BCD validation profile used by BitLocker in Windows 8, Windows Server 2012, and later operating systems:
-
-
-
-
-
-
-
-
-
-
-
-0x11000001 |
-all |
-device |
-
-
-0x12000002 |
-all |
-path |
-
-
-0x12000030 |
-all |
-loadoptions |
-
-
-0x16000010 |
-all |
-bootdebug |
-
-
-0x16000040 |
-all |
-advancedoptions |
-
-
-0x16000041 |
-all |
-optionsedit |
-
-
-0x16000048 |
-all |
-nointegritychecks |
-
-
-0x16000049 |
-all |
-testsigning |
-
-
-0x16000060 |
-all |
-isolatedcontext |
-
-
-0x1600007b |
-all |
-forcefipscrypto |
-
-
-0x22000002 |
-winload |
-systemroot |
-
-
-0x22000011 |
-winload |
-kernel |
-
-
-0x22000012 |
-winload |
-hal |
-
-
-0x22000053 |
-winload |
-evstore |
-
-
-0x25000020 |
-winload |
-nx |
-
-
-0x25000052 |
-winload |
-restrictapiccluster |
-
-
-0x26000022 |
-winload |
-winpe |
-
-
-0x26000025 |
-winload |
-lastknowngood |
-
-
-0x26000081 |
-winload |
-safebootalternateshell |
-
-
-0x260000a0 |
-winload |
-debug |
-
-
-0x260000f2 |
-winload |
-hypervisordebug |
-
-
-0x26000116 |
-winload |
-hypervisorusevapic |
-
-
-0x21000001 |
-winresume |
-filedevice |
-
-
-0x22000002 |
-winresume |
-filepath |
-
-
-0x26000006 |
-winresume |
-debugoptionenabled |
-
-
-
-
-
+| Hex Value | Prefix | Friendly Name |
+| - | - | - |
+| 0x11000001 | all | device|
+| 0x12000002 | all | path|
+| 0x12000030 | all | loadoptions|
+| 0x16000010 | all | bootdebug|
+| 0x16000040 | all | advancedoptions|
+| 0x16000041 | all| optionsedit|
+| 0x16000048| all| nointegritychecks|
+| 0x16000049| all| testsigning|
+| 0x16000060| all| isolatedcontext|
+| 0x1600007b| all| forcefipscrypto|
+| 0x22000002| winload| systemroot|
+| 0x22000011| winload| kernel|
+| 0x22000012| winload| hal|
+| 0x22000053| winload| evstore|
+| 0x25000020| winload| nx|
+| 0x25000052| winload| restrictapiccluster|
+| 0x26000022| winload| winpe|
+| 0x26000025 |winload|lastknowngood|
+| 0x26000081| winload| safebootalternateshell|
+| 0x260000a0| winload| debug|
+| 0x260000f2| winload| hypervisordebug|
+| 0x26000116| winload| hypervisorusevapic|
+| 0x21000001| winresume| filedevice|
+| 0x22000002| winresume| filepath|
+| 0x26000006| winresume| debugoptionenabled|
### Full list of friendly names for ignored BCD settings
This following is a full list of BCD settings with friendly names which are ignored by default. These settings are not part of the default BitLocker validation profile, but can be added if you see a need to validate any of these settings before allowing a BitLocker–protected operating system drive to be unlocked.
-
-**Note**
-Additional BCD settings exist that have hex values but do not have friendly names. These settings are not included in this list.
-
+> **Note:** Additional BCD settings exist that have hex values but do not have friendly names. These settings are not included in this list.
-
-
-
-
-
-
-
-
-
-
-
-
-0x12000004 |
-all |
-description |
-
-
-0x12000005 |
-all |
-locale |
-
-
-0x12000016 |
-all |
-targetname |
-
-
-0x12000019 |
-all |
-busparams |
-
-
-0x1200001d |
-all |
-key |
-
-
-0x1200004a |
-all |
-fontpath |
-
-
-0x14000006 |
-all |
-inherit |
-
-
-0x14000008 |
-all |
-recoverysequence |
-
-
-0x15000007 |
-all |
-truncatememory |
-
-
-0x1500000c |
-all |
-firstmegabytepolicy |
-
-
-0x1500000d |
-all |
-relocatephysical |
-
-
-0x1500000e |
-all |
-avoidlowmemory |
-
-
-0x15000011 |
-all |
-debugtype |
-
-
-0x15000012 |
-all |
-debugaddress |
-
-
-0x15000013 |
-all |
-debugport |
-
-
-0x15000014 |
-all |
-baudrate |
-
-
-0x15000015 |
-all |
-channel |
-
-
-0x15000018 |
-all |
-debugstart |
-
-
-0x1500001a |
-all |
-hostip |
-
-
-0x1500001b |
-all |
-port |
-
-
-0x15000022 |
-all |
-emsport |
-
-
-0x15000023 |
-all |
-emsbaudrate |
-
-
-0x15000042 |
-all |
-keyringaddress |
-
-
-0x15000047 |
-all |
-configaccesspolicy |
-
-
-0x1500004b |
-all |
-integrityservices |
-
-
-0x1500004c |
-all |
-volumebandid |
-
-
-0x15000051 |
-all |
-initialconsoleinput |
-
-
-0x15000052 |
-all |
-graphicsresolution |
-
-
-0x15000065 |
-all |
-displaymessage |
-
-
-0x15000066 |
-all |
-displaymessageoverride |
-
-
-0x16000009 |
-all |
-recoveryenabled |
-
-
-0x1600000b |
-all |
-badmemoryaccess |
-
-
-0x1600000f |
-all |
-traditionalkseg |
-
-
-0x16000017 |
-all |
-noumex |
-
-
-0x1600001c |
-all |
-dhcp |
-
-
-0x1600001e |
-all |
-vm |
-
-
-0x16000020 |
-all |
-bootems |
-
-
-0x16000046 |
-all |
-graphicsmodedisabled |
-
-
-0x16000050 |
-all |
-extendedinput |
-
-
-0x16000053 |
-all |
-restartonfailure |
-
-
-0x16000054 |
-all |
-highestmode |
-
-
-0x1600006c |
-all |
-bootuxdisabled |
-
-
-0x16000072 |
-all |
-nokeyboard |
-
-
-0x16000074 |
-all |
-bootshutdowndisabled |
-
-
-0x1700000a |
-all |
-badmemorylist |
-
-
-0x17000077 |
-all |
-allowedinmemorysettings |
-
-
-0x22000040 |
-all |
-fverecoveryurl |
-
-
-0x22000041 |
-all |
-fverecoverymessage |
-
-
-0x31000003 |
-all |
-ramdisksdidevice |
-
-
-0x32000004 |
-all |
-ramdisksdipath |
-
-
-0x35000001 |
-all |
-ramdiskimageoffset |
-
-
-0x35000002 |
-all |
-ramdisktftpclientport |
-
-
-0x35000005 |
-all |
-ramdiskimagelength |
-
-
-0x35000007 |
-all |
-ramdisktftpblocksize |
-
-
-0x35000008 |
-all |
-ramdisktftpwindowsize |
-
-
-0x36000006 |
-all |
-exportascd |
-
-
-0x36000009 |
-all |
-ramdiskmcenabled |
-
-
-0x3600000a |
-all |
-ramdiskmctftpfallback |
-
-
-0x3600000b |
-all |
-ramdisktftpvarwindow |
-
-
-0x21000001 |
-winload |
-osdevice |
-
-
-0x22000013 |
-winload |
-dbgtransport |
-
-
-0x220000f9 |
-winload |
-hypervisorbusparams |
-
-
-0x22000110 |
-winload |
-hypervisorusekey |
-
-
-0x23000003 |
-winload |
-resumeobject |
-
-
-0x25000021 |
-winload |
-pae |
-
-
-0x25000031 |
-winload |
-removememory |
-
-
-0x25000032 |
-winload |
-increaseuserva |
-
-
-0x25000033 |
-winload |
-perfmem |
-
-
-0x25000050 |
-winload |
-clustermodeaddressing |
-
-
-0x25000055 |
-winload |
-x2apicpolicy |
-
-
-0x25000061 |
-winload |
-numproc |
-
-
-0x25000063 |
-winload |
-configflags |
-
-
-0x25000066 |
-winload |
-groupsize |
-
-
-0x25000071 |
-winload |
-msi |
-
-
-0x25000072 |
-winload |
-pciexpress |
-
-
-0x25000080 |
-winload |
-safeboot |
-
-
-0x250000a6 |
-winload |
-tscsyncpolicy |
-
-
-0x250000c1 |
-winload |
-driverloadfailurepolicy |
-
-
-0x250000c2 |
-winload |
-bootmenupolicy |
-
-
-0x250000e0 |
-winload |
-bootstatuspolicy |
-
-
-0x250000f0 |
-winload |
-hypervisorlaunchtype |
-
-
-0x250000f3 |
-winload |
-hypervisordebugtype |
-
-
-0x250000f4 |
-winload |
-hypervisordebugport |
-
-
-0x250000f5 |
-winload |
-hypervisorbaudrate |
-
-
-0x250000f6 |
-winload |
-hypervisorchannel |
-
-
-0x250000f7 |
-winload |
-bootux |
-
-
-0x250000fa |
-winload |
-hypervisornumproc |
-
-
-0x250000fb |
-winload |
-hypervisorrootprocpernode |
-
-
-0x250000fd |
-winload |
-hypervisorhostip |
-
-
-0x250000fe |
-winload |
-hypervisorhostport |
-
-
-0x25000100 |
-winload |
-tpmbootentropy |
-
-
-0x25000113 |
-winload |
-hypervisorrootproc |
-
-
-0x25000115 |
-winload |
-hypervisoriommupolicy |
-
-
-0x25000120 |
-winload |
-xsavepolicy |
-
-
-0x25000121 |
-winload |
-xsaveaddfeature0 |
-
-
-0x25000122 |
-winload |
-xsaveaddfeature1 |
-
-
-0x25000123 |
-winload |
-xsaveaddfeature2 |
-
-
-0x25000124 |
-winload |
-xsaveaddfeature3 |
-
-
-0x25000125 |
-winload |
-xsaveaddfeature4 |
-
-
-0x25000126 |
-winload |
-xsaveaddfeature5 |
-
-
-0x25000127 |
-winload |
-xsaveaddfeature6 |
-
-
-0x25000128 |
-winload |
-xsaveaddfeature7 |
-
-
-0x25000129 |
-winload |
-xsaveremovefeature |
-
-
-0x2500012a |
-winload |
-xsaveprocessorsmask |
-
-
-0x2500012b |
-winload |
-xsavedisable |
-
-
-0x25000130 |
-winload |
-claimedtpmcounter |
-
-
-0x26000004 |
-winload |
-stampdisks |
-
-
-0x26000010 |
-winload |
-detecthal |
-
-
-0x26000024 |
-winload |
-nocrashautoreboot |
-
-
-0x26000030 |
-winload |
-nolowmem |
-
-
-0x26000040 |
-winload |
-vga |
-
-
-0x26000041 |
-winload |
-quietboot |
-
-
-0x26000042 |
-winload |
-novesa |
-
-
-0x26000043 |
-winload |
-novga |
-
-
-0x26000051 |
-winload |
-usephysicaldestination |
-
-
-0x26000054 |
-winload |
-uselegacyapicmode |
-
-
-0x26000060 |
-winload |
-onecpu |
-
-
-0x26000062 |
-winload |
-maxproc |
-
-
-0x26000064 |
-winload |
-maxgroup |
-
-
-0x26000065 |
-winload |
-groupaware |
-
-
-0x26000070 |
-winload |
-usefirmwarepcisettings |
-
-
-0x26000090 |
-winload |
-bootlog |
-
-
-0x26000091 |
-winload |
-sos |
-
-
-0x260000a1 |
-winload |
-halbreakpoint |
-
-
-0x260000a2 |
-winload |
-useplatformclock |
-
-
-0x260000a3 |
-winload |
-forcelegacyplatform |
-
-
-0x260000a4 |
-winload |
-useplatformtick |
-
-
-0x260000a5 |
-winload |
-disabledynamictick |
-
-
-0x260000b0 |
-winload |
-ems |
-
-
-0x260000c3 |
-winload |
-onetimeadvancedoptions |
-
-
-0x260000c4 |
-winload |
-onetimeoptionsedit |
-
-
-0x260000e1 |
-winload |
-disableelamdrivers |
-
-
-0x260000f8 |
-winload |
-hypervisordisableslat |
-
-
-0x260000fc |
-winload |
-hypervisoruselargevtlb |
-
-
-0x26000114 |
-winload |
-hypervisordhcp |
-
-
-0x21000005 |
-winresume |
-associatedosdevice |
-
-
-0x25000007 |
-winresume |
-bootux |
-
-
-0x25000008 |
-winresume |
-bootmenupolicy |
-
-
-0x26000003 |
-winresume |
-customsettings |
-
-
-0x26000004 |
-winresume |
-pae |
-
-
-0x25000001 |
-memtest |
-passcount |
-
-
-0x25000002 |
-memtest |
-testmix |
-
-
-0x25000005 |
-memtest |
-stridefailcount |
-
-
-0x25000006 |
-memtest |
-invcfailcount |
-
-
-0x25000007 |
-memtest |
-matsfailcount |
-
-
-0x25000008 |
-memtest |
-randfailcount |
-
-
-0x25000009 |
-memtest |
-chckrfailcount |
-
-
-0x26000003 |
-memtest |
-cacheenable |
-
-
-0x26000004 |
-memtest |
-failuresenabled |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+| Hex Value | Prefix | Friendly Name |
+| - | - | - |
+| 0x12000004 | all| description|
+| 0x12000005| all| locale|
+| 0x12000016| all| targetname|
+| 0x12000019| all| busparams|
+| 0x1200001d| all| key|
+| 0x1200004a| all| fontpath|
+| 0x14000006| all| inherit|
+| 0x14000008| all| recoverysequence|
+| 0x15000007| all| truncatememory|
+| 0x1500000c| all| firstmegabytepolicy|
+| 0x1500000d| all| relocatephysical|
+| 0x1500000e| all| avoidlowmemory|
+| 0x15000011| all| debugtype|
+| 0x15000012 |all|debugaddress|
+| 0x15000013| all| debugport|
+| 0x15000014|all|baudrate|
+| 0x15000015 | all| channel|
+| 0x15000018 | all| debugstart|
+| 0x1500001a | all| hostip|
+| 0x1500001b | all| port|
+| 0x15000022 | all| emsport|
+| 0x15000023 | all| emsbaudrate|
+| 0x15000042 | all| keyringaddress|
+| 0x15000047 | all| configaccesspolicy|
+| 0x1500004b | all| integrityservices|
+| 0x1500004c|all| volumebandid|
+| 0x15000051 | all| initialconsoleinput|
+| 0x15000052 | all| graphicsresolution|
+| 0x15000065 | all| displaymessage|
+| 0x15000066| all| displaymessageoverride|
+| 0x16000009 | all| recoveryenabled|
+| 0x1600000b | all| badmemoryaccess|
+| 0x1600000f | all| traditionalkseg|
+| 0x16000017 | all| noumex|
+| 0x1600001c | all| dhcp|
+| 0x1600001e | all| vm|
+| 0x16000020 | all| bootems|
+| 0x16000046 | all| graphicsmodedisabled|
+| 0x16000050 | all| extendedinput|
+| 0x16000053 | all| restartonfailure|
+| 0x16000054 | all| highestmode|
+| 0x1600006c | all| bootuxdisabled|
+| 0x16000072 | all| nokeyboard|
+| 0x16000074 | all| bootshutdowndisabled|
+| 0x1700000a | all| badmemorylist|
+| 0x17000077 | all| allowedinmemorysettings|
+| 0x22000040 | all| fverecoveryurl|
+| 0x22000041 | all| fverecoverymessage|
+| 0x31000003 | all| ramdisksdidevice|
+| 0x32000004 | all| ramdisksdipath|
+| 0x35000001| all | ramdiskimageoffset|
+| 0x35000002 | all| ramdisktftpclientport|
+| 0x35000005 | all| ramdiskimagelength|
+| 0x35000007 | all| ramdisktftpblocksize|
+| 0x35000008 | all| ramdisktftpwindowsize|
+| 0x36000006 | all| exportascd|
+| 0x36000009 | all| ramdiskmcenabled|
+| 0x3600000a | all| ramdiskmctftpfallback|
+| 0x3600000b | all| ramdisktftpvarwindow|
+| 0x21000001 | winload| osdevice|
+| 0x22000013 | winload| dbgtransport|
+| 0x220000f9 | winload| hypervisorbusparams|
+| 0x22000110 | winload| hypervisorusekey|
+| 0x23000003 |winload| resumeobject|
+| 0x25000021| winload| pae|
+| 0x25000031 |winload| removememory|
+| 0x25000032 | winload| increaseuserva|
+| 0x25000033 | winload| perfmem|
+| 0x25000050 | winload| clustermodeaddressing|
+| 0x25000055 | winload| x2apicpolicy|
+| 0x25000061 | winload| numproc|
+| 0x25000063 | winload| configflags|
+| 0x25000066| winload| groupsize|
+| 0x25000071 | winload| msi|
+| 0x25000072 | winload| pciexpress|
+| 0x25000080 | winload| safeboot|
+| 0x250000a6 | winload| tscsyncpolicy|
+| 0x250000c1| winload| driverloadfailurepolicy|
+| 0x250000c2| winload| bootmenupolicy|
+| 0x250000e0 |winload| bootstatuspolicy|
+| 0x250000f0 | winload| hypervisorlaunchtype|
+| 0x250000f3 | winload| hypervisordebugtype|
+| 0x250000f4 | winload| hypervisordebugport|
+| 0x250000f5 | winload| hypervisorbaudrate|
+| 0x250000f6 | winload| hypervisorchannel|
+| 0x250000f7 | winload| bootux|
+| 0x250000fa | winload| hypervisornumproc|
+| 0x250000fb | winload| hypervisorrootprocpernode|
+| 0x250000fd | winload| hypervisorhostip|
+| 0x250000fe | winload| hypervisorhostport|
+| 0x25000100 | winload| tpmbootentropy|
+| 0x25000113 | winload| hypervisorrootproc|
+| 0x25000115 | winload| hypervisoriommupolicy|
+| 0x25000120 | winload| xsavepolicy|
+| 0x25000121 | winload| xsaveaddfeature0|
+| 0x25000122 | winload| xsaveaddfeature1|
+| 0x25000123 | winload| xsaveaddfeature2|
+| 0x25000124 | winload| xsaveaddfeature3|
+| 0x25000125 | winload| xsaveaddfeature4|
+| 0x25000126 | winload| xsaveaddfeature5|
+| 0x25000127 | winload| xsaveaddfeature6|
+| 0x25000128 | winload| xsaveaddfeature7|
+| 0x25000129 | winload| xsaveremovefeature|
+| 0x2500012a | winload| xsaveprocessorsmask|
+| 0x2500012b | winload| xsavedisable|
+| 0x25000130 | winload| claimedtpmcounter|
+| 0x26000004 | winload| stampdisks|
+| 0x26000010 | winload| detecthal|
+| 0x26000024 | winload| nocrashautoreboot|
+| 0x26000030 | winload| nolowmem|
+| 0x26000040 | winload| vga|
+| 0x26000041 | winload| quietboot|
+| 0x26000042 | winload| novesa|
+| 0x26000043 | winload| novga|
+| 0x26000051 | winload| usephysicaldestination|
+| 0x26000054 | winload| uselegacyapicmode|
+| 0x26000060 | winload| onecpu|
+| 0x26000062 | winload| maxproc|
+| 0x26000064 | winload| maxgroup|
+| 0x26000065 | winload| groupaware|
+| 0x26000070| winload| usefirmwarepcisettings|
+| 0x26000090 | winload| bootlog|
+| 0x26000091 | winload| sos|
+| 0x260000a1 | winload| halbreakpoint|
+| 0x260000a2 | winload| useplatformclock|
+| 0x260000a3 |winload| forcelegacyplatform|
+| 0x260000a4 | winload| useplatformtick|
+| 0x260000a5 | winload| disabledynamictick|
+| 0x260000b0 | winload| ems|
+| 0x260000c3 | winload| onetimeadvancedoptions|
+| 0x260000c4 | winload| onetimeoptionsedit|
+| 0x260000e1| winload| disableelamdrivers|
+| 0x260000f8 | winload| hypervisordisableslat|
+| 0x260000fc | winload| hypervisoruselargevtlb|
+| 0x26000114 | winload| hypervisordhcp|
+| 0x21000005 | winresume| associatedosdevice|
+| 0x25000007 | winresume| bootux|
+| 0x25000008 | winresume| bootmenupolicy|
+| 0x26000003| winresume |customsettings|
+| 0x26000004 | winresume| pae|
+| 0x25000001 | memtest| passcount|
+| 0x25000002 | memtest| testmix|
+| 0x25000005 | memtest| stridefailcount|
+| 0x25000006 | memtest| invcfailcount|
+| 0x25000007 | memtest| matsfailcount|
+| 0x25000008 | memtest| randfailcount|
+| 0x25000009 |memtest| chckrfailcount|
+| 0x26000003| memtest| cacheenable|
+| 0x26000004 | memtest| failuresenabled|
diff --git a/windows/keep-secure/bitlocker-basic-deployment.md b/windows/keep-secure/bitlocker-basic-deployment.md
index e6eceae5d1..e63322f296 100644
--- a/windows/keep-secure/bitlocker-basic-deployment.md
+++ b/windows/keep-secure/bitlocker-basic-deployment.md
@@ -5,14 +5,13 @@ ms.assetid: 97c646cb-9e53-4236-9678-354af41151c4
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# BitLocker basic deployment
-
**Applies to**
-
- Windows 10
This topic for the IT professional explains how BitLocker features can be used to protect your data through drive encryption.
@@ -20,45 +19,33 @@ This topic for the IT professional explains how BitLocker features can be used t
The following sections provide information that will help you put together your basic deployment plan for implementing BitLocker in your organization:
- [Using BitLocker to encrypt volumes](#bkmk-dep1)
-
- [Down-level compatibility](#bkmk-dep2)
-
- [Using manage-bde to encrypt volumes with BitLocker](#bkmk-dep3)
-
- [Using PowerShell to encrypt volumes with BitLocker](#bkmk-dep4)
## Using BitLocker to encrypt volumes
-
BitLocker provides full volume encryption (FVE) for operating system volumes, as well as fixed and removable data volumes. To support fully encrypted operating system volumes, BitLocker uses an unencrypted system volume for the files required to boot, decrypt, and load the operating system. This volume is automatically created during a new installation of both client and server operating systems.
In the event that the drive was prepared as a single contiguous space, BitLocker requires a new volume to hold the boot files. BdeHdCfg.exe can create these volumes.
-**Note**
-For more info about using this tool, see [Bdehdcfg](http://technet.microsoft.com/library/ee732026.aspx) in the Command-Line Reference.
-
+> **Note:** For more info about using this tool, see [Bdehdcfg](http://technet.microsoft.com/library/ee732026.aspx) in the Command-Line Reference.
-
BitLocker encryption can be done using the following methods:
- BitLocker control panel
-
- Windows Explorer
-
- manage-bde command line interface
-
- BitLocker Windows PowerShell cmdlets
### Encrypting volumes using the BitLocker control panel
Encrypting volumes with the BitLocker control panel is how many users will utilize BitLocker. The name of the BitLocker control panel is BitLocker Drive Encryption. The BitLocker control panel supports encrypting operating system, fixed data and removable data volumes. The BitLocker control panel will organize available drives in the appropriate category based on how the device reports itself to Windows. Only formatted volumes with assigned drive letters will appear properly in the BitLocker control panel applet.
-
To start encryption for a volume, select **Turn on BitLocker** for the appropriate drive to initialize the BitLocker Drive Encryption Wizard. BitLocker Drive Encryption Wizard options vary based on volume type (operating system volume or data volume).
### Operating system volume
Upon launch, the BitLocker Drive Encryption Wizard verifies the computer meets the BitLocker system requirements for encrypting an operating system volume. By default, the system requirements are:
-
@@ -104,11 +91,8 @@ Upon launch, the BitLocker Drive Encryption Wizard verifies the computer meets t
-
-
Upon passing the initial configuration, users are required to enter a password for the volume. If the volume does not pass the initial configuration for BitLocker, the user is presented with an error dialog describing the appropriate actions to be taken.
-
Once a strong password has been created for the volume, a recovery key will be generated. The BitLocker Drive Encryption Wizard will prompt for a location to save this key. A BitLocker recovery key is a special key that you can create when you turn on BitLocker Drive Encryption for the first time on each drive that you encrypt. You can use the recovery key to gain access to your computer if the drive that Windows is installed on (the operating system drive) is encrypted using BitLocker Drive Encryption and BitLocker detects a condition that prevents it from unlocking the drive when the computer is starting up. A recovery key can also be used to gain access to your files and folders on a removable data drive (such as an external hard drive or USB flash drive) that is encrypted using BitLocker To Go, if for some reason you forget the password or your computer cannot access the drive.
You should store the recovery key by printing it, saving it on removable media, or saving it as a file in a network folder or on your OneDrive, or on another drive of your computer that you are not encrypting. You cannot save the recovery key to the root directory of a non-removable drive and cannot be stored on the encrypted volume. You cannot save the recovery key for a removable data drive (such as a USB flash drive) on removable media. Ideally, you should store the recovery key separate from your computer. After you create a recovery key, you can use the BitLocker control panel to make additional copies.
@@ -116,16 +100,12 @@ You should store the recovery key by printing it, saving it on removable media,
When the recovery key has been properly stored, the BitLocker Drive Encryption Wizard will prompt the user to choose how to encrypt the drive. There are two options:
- Encrypt used disk space only - Encrypts only disk space that contains data
-
- Encrypt entire drive - Encrypts the entire volume including free space
It is recommended that drives with little to no data utilize the **used disk space only** encryption option and that drives with data or an operating system utilize the **encrypt entire drive** option.
-**Note**
-Deleted files appear as free space to the file system, which is not encrypted by **used disk space only**. Until they are wiped or overwritten, deleted files hold information that could be recovered with common data forensic tools.
-
+> **Note:** Deleted files appear as free space to the file system, which is not encrypted by **used disk space only**. Until they are wiped or overwritten, deleted files hold information that could be recovered with common data forensic tools.
-
Selecting an encryption type and choosing **Next** will give the user the option of running a BitLocker system check (selected by default) which will ensure that BitLocker can properly access the recovery and encryption keys before the volume encryption begins. It is recommended to run this system check before starting the encryption process. If the system check is not run and a problem is encountered when the operating system attempts to start, the user will need to provide the recovery key to start Windows.
After completing the system check (if selected), the BitLocker Drive Encryption Wizard will restart the computer to begin encryption. Upon reboot, users are required to enter the password chosen to boot into the operating system volume. Users can check encryption status by checking the system notification area or the BitLocker control panel.
@@ -135,11 +115,9 @@ Until encryption is completed, the only available options for managing BitLocker
### Data volume
Encrypting data volumes using the BitLocker control panel interface works in a similar fashion to encryption of the operating system volumes. Users select **Turn on BitLocker** within the control panel to begin the BitLocker Drive Encryption wizard.
-
Unlike for operating system volumes, data volumes are not required to pass any configuration tests for the wizard to proceed. Upon launching the wizard, a choice of authentication methods to unlock the drive appears. The available options are **password** and **smart card** and **automatically unlock this drive on this computer**. Disabled by default, the latter option will unlock the data volume without user input when the operating system volume is unlocked.
After selecting the desired authentication method and choosing **Next**, the wizard presents options for storage of the recovery key. These options are the same as for operating system volumes.
-
With the recovery key saved, selecting **Next** in the wizard will show available options for encryption. These options are the same as for operating system volumes; **used disk space only** and **full drive encryption**. If the volume being encrypted is new or empty, it is recommended that used space only encryption is selected.
With an encryption method chosen, a final confirmation screen displays before beginning the encryption process. Selecting **Start encrypting** will begin encryption.
@@ -150,7 +128,8 @@ Encryption status displays in the notification area or within the BitLocker cont
There is a new option for storing the BitLocker recovery key using the OneDrive. This option requires that computers are not members of a domain and that the user is using a Microsoft Account. Local accounts do not give the option to utilize OneDrive. Using the OneDrive option is the default, recommended recovery key storage method for computers that are not joined to a domain.
-Users can verify the recovery key was saved properly by checking their OneDrive for the BitLocker folder which is created automatically during the save process. The folder will contain two files, a readme.txt and the recovery key. For users storing more than one recovery password on their OneDrive, they can identify the required recovery key by looking at the file name. The recovery key ID is appended to the end of the file name.
+Users can verify the recovery key was saved properly by checking their OneDrive for the BitLocker folder which is created automatically during the save process. The folder will contain two files, a readme.txt and the recovery key. For users storing more than one recovery password on their OneDrive,
+they can identify the required recovery key by looking at the file name. The recovery key ID is appended to the end of the file name.
### Using BitLocker within Windows Explorer
@@ -158,7 +137,6 @@ Windows Explorer allows users to launch the BitLocker Drive Encryption wizard by
## Down-level compatibility
-
The following table shows the compatibility matrix for systems that have been BitLocker enabled then presented to a different version of Windows.
Table 1: Cross compatibility for Windows 10, Windows 8.1, Windows 8, and Windows 7 encrypted volumes
@@ -203,15 +181,11 @@ Table 1: Cross compatibility for Windows 10, Windows 8.1, Windows 8, and Window
-
-
### Encrypting volumes using the manage-bde command line interface
Manage-bde is a command-line utility that can be used for scripting BitLocker operations. Manage-bde offers additional options not displayed in the BitLocker control panel. For a complete list of the options, see [Manage-bde](http://technet.microsoft.com/library/ff829849.aspx).
-
Manage-bde offers a multitude of wider options for configuring BitLocker. This means that using the command syntax may require care and possibly later customization by the user. For example, using just the `manage-bde -on` command on a data volume will fully encrypt the volume without any authenticating protectors. A volume encrypted in this manner still requires user interaction to turn on BitLocker protection, even though the command successfully completed because an authentication method needs to be added to the volume for it to be fully protected.
-
Command line users need to determine the appropriate syntax for a given situation. The following section covers general encryption for operating system volumes and data volumes.
### Operating system volume
@@ -222,9 +196,7 @@ Listed below are examples of basic valid commands for operating system volumes.
A good practice when using manage-bde is to determine the volume status on the target system. Use the following command to determine volume status:
-``` syntax
-manage-bde -status
-```
+`manage-bde -status`
This command returns the volumes on the target, current encryption status and volume type (operating system or data) for each volume. Using this information, users can determine the best encryption method for their environment.
@@ -241,23 +213,17 @@ manage-bde -on C:
It is possible to encrypt the operating system volume without any defined protectors using manage-bde. The command to do this is:
-``` syntax
-manage-bde -on C:
-```
+`manage-bde -on C:`
This will encrypt the drive using the TPM as the protector. If a user is unsure of the protector for a volume, they can use the -protectors option in manage-bde to list this information with the command:
-``` syntax
- manage-bde -protectors -get
-```
+`manage-bde -protectors -get `
**Provisioning BitLocker with two protectors**
Another example is a user on non-TPM hardware who wishes to add a password and SID-based protector to the operating system volume. In this instance, the user adds the protectors first. This is done with the command:
-``` syntax
-manage-bde -protectors -add C: -pw -sid
-```
+`manage-bde -protectors -add C: -pw -sid `
This command will require the user to enter and then confirm the password protector before adding them to the volume. With the protectors enabled on the volume, the user just needs to turn BitLocker on.
@@ -273,14 +239,11 @@ A common protector for a data volume is the password protector. In the example b
manage-bde -protectors -add -pw C:
manage-bde -on C:
```
-
## Using manage-bde to encrypt volumes with BitLocker
-
### Encrypting volumes using the BitLocker Windows PowerShell cmdlets
Windows PowerShell cmdlets provide an alternative way to work with BitLocker. Using Windows PowerShell's scripting capabilities, administrators can integrate BitLocker options into existing scripts with ease. The list below displays the available BitLocker cmdlets.
-
@@ -407,62 +370,41 @@ Windows PowerShell cmdlets provide an alternative way to work with BitLocker. Us
-
-
Similar to manage-bde, the Windows PowerShell cmdlets allow configuration beyond the options offered in the control panel. As with manage-bde, users need to consider the specific needs of the volume they are encrypting prior to running Windows PowerShell cmdlets.
-
A good initial step is to determine the current state of the volume(s) on the computer. You can do this using the `Get-BitLocker` volume cmdlet. The output from this cmdlet displays information on the volume type, protectors, protection status, and other useful information.
-
Occasionally, all protectors may not be shown when using **Get-BitLockerVolume** due to lack of space in the output display. If you do not see all of the protectors for a volume, you can use the Windows PowerShell pipe command (|) to format a listing of the protectors.
-**Note**
-In the event that there are more than four protectors for a volume, the pipe command may run out of display space. For volumes with more than four protectors, use the method described in the section below to generate a listing of all protectors with protector ID.
-
+> **Note:** In the event that there are more than four protectors for a volume, the pipe command may run out of display space. For volumes with more than four protectors, use the method described in the section below to generate a listing of all protectors with protector ID.
-
-``` syntax
-Get-BitLockerVolume C: | fl
-```
+`Get-BitLockerVolume C: | fl`
If you wanted to remove the existing protectors prior to provisioning BitLocker on the volume, you can utilize the `Remove-BitLockerKeyProtector` cmdlet. Accomplishing this requires the GUID associated with the protector to be removed.
-
A simple script can pipe the values of each **Get-BitLockerVolume** return out to another variable as seen below:
-
``` syntax
$vol = Get-BitLockerVolume
$keyprotectors = $vol.KeyProtector
```
-
Using this, we can display the information in the **$keyprotectors** variable to determine the GUID for each protector.
-
Using this information, we can then remove the key protector for a specific volume using the command:
-
``` syntax
Remove-BitLockerKeyProtector : -KeyProtectorID "{GUID}"
```
-
-**Note**
-The BitLocker cmdlet requires the key protector GUID enclosed in quotation marks to execute. Ensure the entire GUID, with braces, is included in the command.
-
+> **Note:** The BitLocker cmdlet requires the key protector GUID enclosed in quotation marks to execute. Ensure the entire GUID, with braces, is included in the command.
-
### Operating system volume
Using the BitLocker Windows PowerShell cmdlets is similar to working with the manage-bde tool for encrypting operating system volumes. Windows PowerShell offers users a lot of flexibility. For example, users can add the desired protector as part command for encrypting the volume. Below are examples of common user scenarios and steps to accomplish them using the BitLocker cmdlets for Windows PowerShell.
-
To enable BitLocker with just the TPM protector. This can be done using the command:
``` syntax
Enable-BitLocker C:
```
-
The example below adds one additional protector, the StartupKey protectors, and chooses to skip the BitLocker hardware test. In this example, encryption starts immediately without the need for a reboot.
``` syntax
Enable-BitLocker C: -StartupKeyProtector -StartupKeyPath -SkipHardwareTest
```
-
### Data volume
Data volume encryption using Windows PowerShell is the same as for operating system volumes. You should add the desired protectors prior to encrypting the volume. The following example adds a password protector to the E: volume using the variable $pw as the password. The $pw variable is held as a SecureString value to store the user defined password. Last, encryption begins.
@@ -472,52 +414,35 @@ $pw = Read-Host -AsSecureString
Enable-BitLockerKeyProtector E: -PasswordProtector -Password $pw
```
-
### Using a SID based protector in Windows PowerShell
The ADAccountOrGroup protector is an Active Directory SID-based protector. This protector can be added to both operating system and data volumes, although it does not unlock operating system volumes in the pre-boot environment. The protector requires the SID for the domain account or group to link with the protector. BitLocker can protect a cluster-aware disk by adding a SID-based protector for the Cluster Name Object (CNO) that lets the disk properly failover and be unlocked to any member computer of the cluster.
-**Warning**
-The SID-based protector requires the use of an additional protector (such as TPM, PIN, recovery key, etc.) when used on operating system volumes.
-
+>**Warning:** The SID-based protector requires the use of an additional protector (such as TPM, PIN, recovery key, etc.) when used on operating system volumes.
-
To add an ADAccountOrGroup protector to a volume requires either the actual domain SID or the group name preceded by the domain and a backslash. In the example below, the CONTOSO\\Administrator account is added as a protector to the data volume G.
``` syntax
Enable-BitLocker G: -AdAccountOrGroupProtector -AdAccountOrGroup CONTOSO\Administrator
```
-
For users who wish to use the SID for the account or group, the first step is to determine the SID associated with the account. To get the specific SID for a user account in Windows PowerShell, use the following command:
``` syntax
get-aduser -filter {samaccountname -eq "administrator"}
```
-
-**Note**
-Use of this command requires the RSAT-AD-PowerShell feature.
-
+> **Note:** Use of this command requires the RSAT-AD-PowerShell feature.
-
-**Tip**
-In addition to the Windows PowerShell command above, information about the locally logged on user and group membership can be found using: WHOAMI /ALL. This does not require the use of additional features.
-
+> **Tip:** In addition to the Windows PowerShell command above, information about the locally logged on user and group membership can be found using: WHOAMI /ALL. This does not require the use of additional features.
-
In the example below, the user wishes to add a domain SID based protector to the previously encrypted operating system volume. The user knows the SID for the user account or group they wish to add and uses the following command:
``` syntax
Add-BitLockerKeyProtector C: -ADAccountOrGroupProtector -ADAccountOrGroup ""
```
-
-**Note**
-Active Directory-based protectors are normally used to unlock Failover Cluster enabled volumes.
-
+> **Note:** Active Directory-based protectors are normally used to unlock Failover Cluster enabled volumes.
-
## Using PowerShell to encrypt volumes with BitLocker
-
### Checking BitLocker status
To check the BitLocker status of a particular volume, administrators can look at the status of the drive in the BitLocker control panel applet, Windows Explorer, manage-bde command line tool, or Windows PowerShell cmdlets. Each option offers different levels of detail and ease of use. We will look at each of the available methods in the following section.
@@ -526,41 +451,15 @@ To check the BitLocker status of a particular volume, administrators can look at
Checking BitLocker status with the control panel is the most common method used by most users. Once opened, the status for each volume will display next to the volume description and drive letter. Available status return values with the control panel include:
-
-
-
-
-
-
-
-Status |
-Description |
-
-
-On |
-BitLocker is enabled for the volume |
-
-
-Off |
-BitLocker is not enabled for the volume |
-
-
-Suspended |
-BitLocker is suspended and not actively protecting the volume |
-
-
-Waiting for Activation |
-BitLocker is enabled with a clear protector key and requires further action to be fully protected |
-
-
-
-
+| Status | Description |
+| - | - |
+| **On**|BitLocker is enabled for the volume |
+| **Off**| BitLocker is not enabled for the volume |
+| **Suspended** | BitLocker is suspended and not actively protecting the volume |
+| **Waiting for Activation**| BitLocker is enabled with a clear protector key and requires further action to be fully protected|
-
If a drive is pre-provisioned with BitLocker, a status of "Waiting for Activation" displays with a yellow exclamation icon on volume E. This status means that there was only a clear protector used when encrypting the volume. In this case, the volume is not in a protected state and needs to have a secure key added to the volume before the drive is fully protected. Administrators can use the control panel, manage-bde tool, or WMI APIs to add an appropriate key protector. Once complete, the control panel will update to reflect the new status.
-
Using the control panel, administrators can choose **Turn on BitLocker** to start the BitLocker Drive Encryption wizard and add a protector, like PIN for an operating system volume (or password if no TPM exists), or a password or smart card protector to a data volume.
-
The drive security window displays prior to changing the volume status. Selecting **Activate BitLocker** will complete the encryption process.
Once BitLocker protector activation is completed, the completion notice is displayed.
@@ -574,12 +473,8 @@ To check the status of a volume using manage-bde, use the following command:
``` syntax
manage-bde -status
```
-
-**Note**
-If no volume letter is associated with the -status command, all volumes on the computer display their status.
-
+> **Note:** If no volume letter is associated with the -status command, all volumes on the computer display their status.
-
### Checking BitLocker status with Windows PowerShell
Windows PowerShell commands offer another way to query BitLocker status for volumes. Like manage-bde, Windows PowerShell includes the advantage of being able to check the status of a volume on a remote computer.
@@ -589,7 +484,6 @@ Using the Get-BitLockerVolume cmdlet, each volume on the system will display its
``` syntax
Get-BitLockerVolume -Verbose | fl
```
-
This command will display information about the encryption method, volume type, key protectors, etc.
### Provisioning BitLocker during operating system deployment
@@ -603,7 +497,6 @@ Decrypting volumes removes BitLocker and any associated protectors from the volu
### Decrypting volumes using the BitLocker control panel applet
BitLocker decryption using the control panel is done using a Wizard. The control panel can be called from Windows Explorer or by opening the directly. After opening the BitLocker control panel, users will select the Turn off BitLocker option to begin the process.
-
Once selected, the user chooses to continue by clicking the confirmation dialog. With Turn off BitLocker confirmed, the drive decryption process will begin and report status to the control panel.
The control panel does not report decryption progress but displays it in the notification area of the task bar. Selecting the notification area icon will open a modal dialog with progress.
@@ -617,13 +510,11 @@ Decrypting volumes using manage-bde is very straightforward. Decryption with man
``` syntax
manage-bde -off C:
```
-
This command disables protectors while it decrypts the volume and removes all protectors when decryption is complete. If a user wishes to check the status of the decryption, they can use the following command:
``` syntax
manage-bde -status C:
```
-
### Decrypting volumes using the BitLocker Windows PowerShell cmdlets
Decryption with Windows PowerShell cmdlets is straightforward, similar to manage-bde. The additional advantage Windows PowerShell offers is the ability to decrypt multiple drives in one pass. In the example below, the user has three encrypted volumes, which they wish to decrypt.
@@ -633,33 +524,16 @@ Using the Disable-BitLocker command, they can remove all protectors and encrypti
``` syntax
DisableBitLocker
```
-
If a user did not want to input each mount point individually, using the `-MountPoint` parameter in an array can sequence the same command into one line without requiring additional user input. An example command is:
``` syntax
Disable-BitLocker -MountPoint E:,F:,G:
```
-
## See also
-
-[Prepare your organization for BitLocker: Planning and p\\olicies](prepare-your-organization-for-bitlocker-planning-and-policies.md)
-
-
-[BitLocker recovery guide](bitlocker-recovery-guide-plan.md)
-
-
-[BitLocker: How to enable Network Unlock](bitlocker-how-to-enable-network-unlock.md)
-
-
-[BitLocker overview](bitlocker-overview.md)
-
-
+- [Prepare your organization for BitLocker: Planning and p\\olicies](prepare-your-organization-for-bitlocker-planning-and-policies.md)
+- [BitLocker recovery guide](bitlocker-recovery-guide-plan.md)
+- [BitLocker: How to enable Network Unlock](bitlocker-how-to-enable-network-unlock.md)
+- [BitLocker overview](bitlocker-overview.md)
-
-
-
-
-
-
diff --git a/windows/keep-secure/bitlocker-countermeasures.md b/windows/keep-secure/bitlocker-countermeasures.md
index 2b1a79a0b6..687bf6047b 100644
--- a/windows/keep-secure/bitlocker-countermeasures.md
+++ b/windows/keep-secure/bitlocker-countermeasures.md
@@ -5,22 +5,18 @@ ms.assetid: ebdb0637-2597-4da1-bb18-8127964686ea
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
-
# BitLocker Countermeasures
-
**Applies to**
-
- Windows 10
Windows uses technologies including TPM, Secure Boot, Trusted Boot, and Early Launch Antimalware (ELAM) to protect against attacks on the BitLocker encryption key.
-
BitLocker is part of a strategic approach to securing mobile data through encryption technology. Data on a lost or stolen computer is vulnerable to unauthorized access, either by running a software attack tool against it or by transferring the computer’s hard disk to a different computer. Today, BitLocker helps mitigate unauthorized data access on lost or stolen computers before the operating system is started by:
- **Encrypting the hard drives on your computer.** For example, you can turn on BitLocker for your operating system drive, a fixed data drive, or a removable data drive (such as a USB flash drive). Turning on BitLocker for your operating system drive encrypts all system files on the operating system drive, including the swap files and hibernation files.
-
- **Ensuring the integrity of early boot components and boot configuration data.** On devices that have a TPM version 1.2 or higher, BitLocker uses the enhanced security capabilities of the TPM to help ensure that your data is accessible only if the computer’s boot components appear unaltered and the encrypted disk is located in the original computer.
The sections that follow provide more detailed information about the different technologies that Windows uses to protect against attacks on the BitLocker encryption key in four different boot phases: before startup, during pre-boot, during startup, and finally after startup.
@@ -34,9 +30,7 @@ Before Windows starts, you must rely on security features implemented as part of
Software alone isn’t sufficient to protect a system. After an attacker has compromised software, the software might be unable to detect the compromise. Therefore, a single successful software compromise results in an untrusted system that might never be detected. Hardware, however, is much more difficult to modify.
A TPM is a microchip designed to provide basic security-related functions, primarily involving encryption keys. The TPM is usually installed on the motherboard of a computer and communicates with the rest of the system through a hardware bus. Physically, TPMs are designed to be tamper-proof. If an attacker tries to physically retrieve data directly from the chip, they’ll probably destroy the chip in the process.
-
By binding the BitLocker encryption key with the TPM and properly configuring the device, it’s nearly impossible for an attacker to gain access to the BitLocker-encrypted data without obtaining an authorized user’s credentials. Therefore, computers with a TPM can provide a high level of protection against attacks that attempt to directly retrieve the BitLocker encryption key.
-
For more info about TPM, see [Trusted Platform Module](trusted-platform-module-overview.md).
**UEFI and Secure Boot**
@@ -48,39 +42,34 @@ The UEFI is a programmable boot environment introduced as a replacement for BIOS
Recent implementations of UEFI (starting with version 2.3.1) can verify the digital signatures of the device’s firmware before running it. Because only the PC’s hardware manufacturer has access to the digital certificate required to create a valid firmware signature, UEFI can prevent firmware-based bootkits. Thus, UEFI is the first link in the chain of trust.
Secure Boot is the foundation of platform and firmware security and was created to enhance security in the pre-boot environment regardless of device architecture. Using signatures to validate the integrity of firmware images before they are allowed to execute, Secure Boot helps reduce the risk of bootloader attacks. The purpose of Secure Boot is to block untrusted firmware and bootloaders (signed or unsigned) from being able to start on the system.
-
With the legacy BIOS boot process, the pre–operating system environment is vulnerable to attacks by redirecting bootloader handoff to possible malicious loaders. These loaders could remain undetected to operating system and antimalware software. The diagram in Figure 1 contrasts the BIOS and UEFI startup processes.
**Figure 1.** The BIOS and UEFI startup processes
-With Secure Boot enabled, UEFI, in coordination with the TPM, can examine the bootloader and determine whether it’s trustworthy. To determine whether the bootloader is trustworthy, UEFI examines the bootloader’s digital signature. Using the digital signature, UEFI verifies that the bootloader was signed using a trusted certificate.
+With Secure Boot enabled, UEFI, in coordination with the TPM, can examine the bootloader and determine whether it’s trustworthy. To determine whether the bootloader is trustworthy, UEFI examines the bootloader’s digital signature.
+Using the digital signature, UEFI verifies that the bootloader was signed using a trusted certificate.
If the bootloader passes these two tests, UEFI knows that the bootloader isn’t a bootkit and starts it. At this point, Trusted Boot takes over, and the Windows bootloader, using the same cryptographic technologies that UEFI used to verify the bootloader, then verifies that the Windows system files haven’t been changed.
All Windows 8–certified devices must meet several requirements related to UEFI-based Secure Boot:
- They must have Secure Boot enabled by default.
-
- They must trust Microsoft’s certificate (and thus any bootloader Microsoft has signed).
-
- They must allow the user to configure Secure Boot to trust other signed bootloaders.
-
- Except for Windows RT devices, they must allow the user to completely disable Secure Boot.
These requirements help protect you from rootkits while allowing you to run any operating system you want. You have three options for running non-Microsoft operating systems:
-- **Use an operating system with a certified bootloader.** Microsoft can analyze and sign non-Microsoft bootloaders so that they can be trusted. The Linux community is using this process to enable Linux to take advantage of Secure Boot on Windows-certified devices.
+- **Use an operating system with a certified bootloader.** Microsoft can analyze and sign non-Microsoft bootloaders so that they can be trusted. The Linux community is using this process to enable Linux to take advantage of
+Secure Boot on Windows-certified devices.
- **Configure UEFI to trust your custom bootloader.** Your device can trust a signed, non-certified bootloader that you specify in the UEFI database, allowing you to run any operating system, including homemade operating systems.
-
- **Turn off Secure Boot.** You can turn off Secure Boot. This does not help protect you from bootkits, however.
To prevent malware from abusing these options, the user has to manually configure the UEFI firmware to trust a non-certified bootloader or to turn off Secure Boot. Software cannot change the Secure Boot settings.
-
Any device that doesn’t require Secure Boot or a similar bootloader-verification technology, regardless of the architecture or operating system, is vulnerable to bootkits, which can be used to compromise the encryption solution.
-
UEFI is secure by design, but it’s critical to protect the Secure Boot configuration by using password protection. In addition, although several well-publicized attacks against UEFI have occurred, they were exploiting faulty UEFI implementations. Those attacks are ineffective when UEFI is implemented properly.
For more information about Secure Boot, refer to [Securing the Windows 8.1 Boot Process](http://technet.microsoft.com/windows/dn168167.aspx).
@@ -96,11 +85,8 @@ The BitLocker pre-boot authentication capability is not specifically designed to
On computers with a compatible TPM, operating system drives that are BitLocker-protected can be unlocked in four ways:
- **TPM-only.** Using TPM-only validation does not require any interaction with the user to decrypt and provide access to the drive. If the TPM validation succeeds, the user logon experience is the same as a standard logon. If the TPM is missing or changed or if the TPM detects changes to critical operating system startup files, BitLocker enters its recovery mode, and the user must enter a recovery password to regain access to the data.
-
- **TPM with startup key.** In addition to the protection that the TPM provides, part of the encryption key is stored on a USB flash drive, referred to as a startup key. Data on the encrypted volume cannot be accessed without the startup key.
-
- **TPM with PIN.** In addition to the protection that the TPM provides, BitLocker requires that the user enter a PIN. Data on the encrypted volume cannot be accessed without entering the PIN.
-
- **TPM with startup key and PIN.** In addition to the core component protection that the TPM provides, part of the encryption key is stored on a USB flash drive, and a PIN is required to authenticate the user to the TPM. This configuration provides multifactor authentication so that if the USB key is lost or stolen, it cannot be used for access to the drive, because the correct PIN is also required.
For many years, Microsoft has recommended using pre-boot authentication to protect against DMA and memory remanence attacks. Today, Microsoft only recommends using pre-boot authentication on PCs where the mitigations described in this document cannot be implemented. These mitigations may be inherent to the device or may come by way of configurations that IT can provision to devices and Windows itself.
@@ -108,13 +94,11 @@ For many years, Microsoft has recommended using pre-boot authentication to prote
Although effective, pre-boot authentication is inconvenient to users. In addition, if a user forgets their PIN or loses their startup key, they’re denied access to their data until they can contact their organization’s support team to obtain a recovery key. Today, most new PCs running Windows 10, Windows 8.1, or Windows 8 provide sufficient protection against DMA attacks without requiring pre-boot authentication. For example, most modern PCs include USB port options (which are not vulnerable to DMA attacks) but do not include FireWire or Thunderbolt ports (which are vulnerable to DMA attacks).
BitLocker-encrypted devices with DMA ports enabled, including FireWire or Thunderbolt ports, should be configured with pre-boot authentication if they are running Windows 10, Windows 7, Windows 8, or Windows 8.1 and disabling the ports using policy or firmware configuration is not an option. Windows 8.1 and later InstantGo devices do not need pre-boot authentication to defend against DMA-based port attacks, as the ports will not be present on certified devices. A non-InstantGo Windows 8.1 and later device requires pre-boot authentication if DMA ports are enabled on the device and additional mitigations described in this document are not implemented. Many customers find that the DMA ports on their devices are never used, and they choose to eliminate the possibility of an attack by disabling the DMA ports themselves, either at the hardware level or through Group Policy.
-
Many new mobile devices have the system memory soldered to the motherboard, which helps prevent the cold boot–style attack, where the system memory is frozen, removed, and then placed into another device. Those devices, and most PCs, can still be vulnerable when booting to a malicious operating system, however.
You can mitigate the risk of booting to a malicious operating system:
- **Windows 10 (without Secure Boot), Windows 8.1 (without Secure Boot), Windows 8 (without UEFI-based Secure Boot), or Windows 7 (with or without a TPM).** Disable booting from external media, and require a firmware password to prevent the attacker from changing that option.
-
- **Windows 10, Windows 8.1, or Windows 8 (certified or with Secure Boot).** Password protect the firmware, and do not disable Secure Boot.
### Protection During Startup
@@ -134,15 +118,11 @@ Because UEFI-based Secure Boot has protected the bootloader and Trusted Boot has
The purpose of ELAM is to load an antimalware driver before drivers that are flagged as boot-start can be executed. This approach provides the ability for an antimalware driver to register as a trusted boot-critical driver. It is launched during the Trusted Boot process, and with that, Windows ensures that it is loaded before any other non-Microsoft software.
With this solution in place, boot drivers are initialized based on the classification that the ELAM driver returns according to an initialization policy. IT pros have the ability to change this policy through Group Policy.
-
ELAM classifies drivers as follows:
- **Good.** The driver has been signed and has not been tampered with.
-
- **Bad.** The driver has been identified as malware. It is recommended that you not allow known bad drivers to be initialized.
-
- **Bad but required for boot.** The driver has been identified as malware, but the computer cannot successfully boot without loading this driver.
-
- **Unknown.** This driver has not been attested to by your malware-detection application or classified by the ELAM boot-start driver.
While the features listed above protect the Windows boot process from malware threats that could compromise BitLocker security, it is important to note that DMA ports may be enabled during the window of time between when BitLocker unlocks the drive and Windows boots to the point that Windows can set any port related policies that have been configured. This period of time where the encryption key could be exposed to a DMA attack could be less than a minute on recent devices or longer depending on system performance. The use of pre-boot authentication with a PIN can be used to successfully mitigate against an attack.
@@ -152,21 +132,7 @@ While the features listed above protect the Windows boot process from malware th
Windows InstantGo–certified devices do not have DMA ports, eliminating the risk of DMA attacks. On other devices, you can disable FireWire, Thunderbolt, or other ports that support DMA.
## See also
-
-
- [Types of Attacks for Volume Encryption Keys](types-of-attacks-for-volume-encryption-keys.md)
-
- [Choose the right BitLocker countermeasure](choose-the-right-bitlocker-countermeasure.md)
-
- [Protect BitLocker from pre-boot attacks](protect-bitlocker-from-pre-boot-attacks.md)
-
- [BitLocker overview](bitlocker-overview.md)
-
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/bitlocker-frequently-asked-questions.md b/windows/keep-secure/bitlocker-frequently-asked-questions.md
index 0d127689fd..4d179869fb 100644
--- a/windows/keep-secure/bitlocker-frequently-asked-questions.md
+++ b/windows/keep-secure/bitlocker-frequently-asked-questions.md
@@ -5,14 +5,13 @@ ms.assetid: c40f87ac-17d3-47b2-afc6-6c641f72ecee
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# BitLocker frequently asked questions (FAQ)
-
**Applies to**
-
- Windows 10
This topic for the IT professional answers frequently asked questions concerning the requirements to use, upgrade, deploy and administer, and key management policies for BitLocker.
@@ -20,26 +19,17 @@ This topic for the IT professional answers frequently asked questions concerning
BitLocker is a data protection feature that encrypts the hard drives on your computer to provide enhanced protection against data theft or exposure on computers and removable drives that are lost or stolen, and more secure data deletion when BitLocker-protected computers are decommissioned as it is much more difficult to recover deleted data from an encrypted drive than from a non-encrypted drive.
- [Overview and requirements](#bkmk-overview)
-
- [Upgrading](#bkmk-upgrading)
-
- [Deployment and administration](#bkmk-deploy)
-
- [Key management](#bkmk-keymanagement)
-
- [BitLocker To Go](#bkmk-btgsect)
-
- [Active Directory Domain Services (AD DS)](#bkmk-adds)
-
- [Security](#bkmk-security)
-
- [BitLocker Network Unlock](#bkmk-bnusect)
-
- [Other questions](#bkmk-other)
## Overview and requirements
-
### How does BitLocker work?
**How BitLocker works with operating system drives**
@@ -56,11 +46,8 @@ Yes, BitLocker supports multifactor authentication for operating system drives.
### What are the BitLocker hardware and software requirements?
-**Note**
-Dynamic disks are not supported by BitLocker. Dynamic data volumes will not be displayed in the Control Panel. Although the operating system volume will always be displayed in the Control Panel, regardless of whether it is a Dynamic disk, if it is a dynamic disk it is cannot be protected by BitLocker.
-
+> **Note:** Dynamic disks are not supported by BitLocker. Dynamic data volumes will not be displayed in the Control Panel. Although the operating system volume will always be displayed in the Control Panel, regardless of whether it is a Dynamic disk, if it is a dynamic disk it is cannot be protected by BitLocker.
-
### Why are two partitions required? Why does the system drive have to be so large?
Two partitions are required to run BitLocker because pre-startup authentication and system integrity verification must occur on a separate partition from the encrypted operating system drive. This configuration helps protect the operating system and the information in the encrypted drive.
@@ -76,7 +63,6 @@ Open the TPM MMC console (tpm.msc) and look under the **Status** heading.
### Can I use BitLocker on an operating system drive without a TPM?
Yes, you can enable BitLocker on an operating system drive without a TPM version 1.2 or higher, if the BIOS or UEFI firmware has the ability to read from a USB flash drive in the boot environment. This is because BitLocker will not unlock the protected drive until BitLocker's own volume master key is first released by either the computer's TPM or by a USB flash drive containing the BitLocker startup key for that computer. However, computers without TPMs will not be able to use the system integrity verification that BitLocker can also provide.
-
To help determine whether a computer can read from a USB device during the boot process, use the BitLocker system check as part of the BitLocker setup process. This system check performs tests to confirm that the computer can properly read from the USB devices at the appropriate time and that the computer meets other BitLocker requirements.
### How do I obtain BIOS support for the TPM on my computer?
@@ -84,7 +70,6 @@ To help determine whether a computer can read from a USB device during the boot
Contact the computer manufacturer to request a Trusted Computing Group (TCG)-compliant BIOS or UEFI boot firmware that meets the following requirements:
- It is compliant with the TCG standards for a client computer.
-
- It has a secure update mechanism to help prevent a malicious BIOS or boot firmware from being installed on the computer.
### What credentials are required to use BitLocker?
@@ -97,7 +82,6 @@ You should configure the startup options of your computer to have the hard disk
## Upgrading
-
### Can I upgrade my Windows 7 or Windows 8 computer to Windows 10 with BitLocker enabled?
Yes. Open the **BitLocker Drive Encryption** Control Panel, click **Manage BitLocker**, and then and click **Suspend**. Suspending protection does not decrypt the drive; it disables the authentication mechanisms used by BitLocker and uses a clear key on the drive to enable access. After the upgrade has completed, open Windows Explorer, right-click the drive, and then click **Resume Protection**. This reapplies the BitLocker authentication methods and deletes the clear key.
@@ -147,17 +131,11 @@ The following table lists what action you need to take before you perform an upg
-
-
-**Note**
-If you have suspended BitLocker, you can resume BitLocker protection after you have installed the upgrade or update. Upon resuming protection, BitLocker will reseal the encryption key to the new values of the measured components that changed as a part of the upgrade or update. If these types of upgrades or updates are applied without suspending BitLocker, your computer will enter recovery mode when restarting and will require a recovery key or password to access the computer.
-
+> **Note:** If you have suspended BitLocker, you can resume BitLocker protection after you have installed the upgrade or update. Upon resuming protection, BitLocker will reseal the encryption key to the new values of the measured components that changed as a part of the upgrade or update. If these types of upgrades or updates are applied without suspending BitLocker, your computer will enter recovery mode when restarting and will require a recovery key or password to access the computer.
-
## Deployment and administration
-
### Can BitLocker deployment be automated in an enterprise environment?
Yes, you can automate the deployment and configuration of BitLocker and the TPM using either WMI or Windows PowerShell scripts. How you choose to implement the scripts depends on your environment. You can also use Manage-bde.exe to locally or remotely configure BitLocker. For more info about writing scripts that use the BitLocker WMI providers, see [BitLocker Drive Encryption Provider](http://go.microsoft.com/fwlink/p/?LinkId=80600). For more info about using Windows PowerShell cmdlets with BitLocker Drive Encryption, see [BitLocker Cmdlets in Windows PowerShell](http://technet.microsoft.com/library/jj649829.aspx).
@@ -187,7 +165,6 @@ No, BitLocker does not encrypt and decrypt the entire drive when reading and wri
### How can I prevent users on a network from storing data on an unencrypted drive?
You can can Group Policy settings to require that data drives be BitLocker-protected before a BitLocker-protected computer can write data to them. For more info, see [BitLocker Group Policy settings](bitlocker-group-policy-settings.md).
-
When these policy settings are enabled, the BitLocker-protected operating system will mount any data drives that are not protected by BitLocker as read-only.
### What system changes would cause the integrity check on my operating system drive to fail?
@@ -195,13 +172,9 @@ When these policy settings are enabled, the BitLocker-protected operating system
The following types of system changes can cause an integrity check failure and prevent the TPM from releasing the BitLocker key to decrypt the protected operating system drive:
- Moving the BitLocker-protected drive into a new computer.
-
- Installing a new motherboard with a new TPM.
-
- Turning off, disabling, or clearing the TPM.
-
- Changing any boot configuration settings.
-
- Changing the BIOS, UEFI firmware, master boot record, boot sector, boot manager, option ROM, or other early boot components or boot configuration data.
### What causes BitLocker to start into recovery mode when attempting to start the operating system drive?
@@ -217,16 +190,13 @@ Yes, you can swap multiple hard disks on the same computer if BitLocker is enabl
Yes, if the drive is a data drive, you can unlock it from the **BitLocker Drive Encryption** Control Panel item just as you would any other data drive by using a password or smart card. If the data drive was configured for automatic unlock only, you will have to unlock it by using the recovery key. The encrypted hard disk can be unlocked by a data recovery agent (if one was configured) or it can be unlocked by using the recovery key.
### Why is "Turn BitLocker on" not available when I right-click a drive?
-
Some drives cannot be encrypted with BitLocker. Reasons a drive cannot be encrypted include insufficient disk size, an incompatible file system, if the drive is a dynamic disk, or a drive is designated as the system partition. By default, the system drive (or system partition) is hidden from display. However, if it is not created as a hidden drive when the operating system was installed due to a custom installation process, that drive might be displayed but cannot be encrypted.
### What type of disk configurations are supported by BitLocker?
-
Any number of internal, fixed data drives can be protected with BitLocker. On some versions ATA and SATA-based, direct-attached storage devices are also supported.
## Key management
-
### What is the difference between a TPM owner password, recovery password, recovery key, password, PIN, enhanced PIN, and startup key?
There are multiple keys that can be generated and used by BitLocker. Some keys are required and some are optional protectors you can choose to use depending on the level of security you require.
@@ -243,19 +213,16 @@ A domain administrator can additionally configure Group Policy to automatically
You can use the Manage-bde.exe command-line tool to replace your TPM-only authentication mode with a multifactor authentication mode. For example, if BitLocker is enabled with TPM authentication only and you want to add PIN authentication, use the following commands from an elevated command prompt, replacing *<4-20 digit numeric PIN>* with the numeric PIN you want to use:
-**manage-bde –protectors –delete %systemdrive% -type tpm**
+`manage-bde –protectors –delete %systemdrive% -type tpm`
-**manage-bde –protectors –add %systemdrive% -tpmandpin** *<4-20 digit numeric PIN>*
+`manage-bde –protectors –add %systemdrive% -tpmandpin <4-20 digit numeric PIN>`
### If I lose my recovery information, will the BitLocker-protected data be unrecoverable?
BitLocker is designed to make the encrypted drive unrecoverable without the required authentication. When in recovery mode, the user needs the recovery password or recovery key to unlock the encrypted drive.
-**Important**
-Store the recovery information in AD DS, along with your Microsoft Account, or another safe location.
-
+>**Important:** Store the recovery information in AD DS, along with your Microsoft Account, or another safe location.
-
### Can the USB flash drive that is used as the startup key also be used to store the recovery key?
While this is technically possible, it is not a best practice to use one USB flash drive to store both keys. If the USB flash drive that contains your startup key is lost or stolen, you also lose access to your recovery key. In addition, inserting this key would cause your computer to automatically boot from the recovery key even if TPM-measured files have changed, which circumvents the TPM's system integrity check.
@@ -297,7 +264,6 @@ When using an enhanced PIN, users should run the optional system check during th
It is possible that a personal identification number (PIN) can be discovered by an attacker performing a brute force attack. A brute force attack occurs when an attacker uses an automated tool to try different PIN combinations until the correct one is discovered. For BitLocker-protected computers, this type of attack, also known as a dictionary attack, requires that the attacker have physical access to the computer.
The TPM has the built-in ability to detect and react to these types of attacks. Because different manufacturers' TPMs may support different PIN and attack mitigations, contact your TPM's manufacturer to determine how your computer's TPM mitigates PIN brute force attacks.
-
After you have determined your TPM's manufacturer, contact the manufacturer to gather the TPM's vendor-specific information. Most manufacturers use the PIN authentication failure count to exponentially increase lockout time to the PIN interface. However, each manufacturer has different policies regarding when and how the failure counter is decreased or reset.
### How can I determine the manufacturer of my TPM?
@@ -309,9 +275,7 @@ You can determine your TPM manufacturer in the TPM MMC console (tpm.msc) under t
The following questions can assist you when asking a TPM manufacturer about the design of a dictionary attack mitigation mechanism:
- How many failed authorization attempts can occur before lockout?
-
- What is the algorithm for determining the duration of a lockout based on the number of failed attempts and any other relevant parameters?
-
- What actions can cause the failure count and lockout duration to be decreased or reset?
### Can PIN length and complexity be managed with Group Policy?
@@ -322,12 +286,10 @@ For more info, see [BitLocker Group Policy settings](bitlocker-group-policy-sett
## BitLocker To Go
-
BitLocker To Go is BitLocker Drive Encryption on removable data drives. This includes the encryption of USB flash drives, SD cards, external hard disk drives, and other drives formatted by using the NTFS, FAT16, FAT32, or exFAT file systems.
## Active Directory Domain Services (AD DS)
-
### What if BitLocker is enabled on a computer before the computer has joined the domain?
If BitLocker is enabled on a drive before Group Policy has been applied to enforce backup, the recovery information will not be automatically backed up to AD DS when the computer joins the domain or when Group Policy is subsequently applied. However, you can use the **Choose how BitLocker-protected operating system drives can be recovered**, **Choose how BitLocker-protected fixed drives can be recovered** and **Choose how BitLocker-protected removable drives can be recovered** Group Policy settings to require that the computer be connected to a domain before BitLocker can be enabled to help ensure that recovery information for BitLocker-protected drives in your organization is backed up to AD DS.
@@ -336,11 +298,8 @@ For more info, see [BitLocker Group Policy settings](bitlocker-group-policy-sett
The BitLocker Windows Management Instrumentation (WMI) interface does allow administrators to write a script to back up or synchronize an online client's existing recovery information; however, BitLocker does not automatically manage this process. The manage-bde command-line tool can also be used to manually back up recovery information to AD DS. For example, to back up all of the recovery information for the C: drive to AD DS, you would use the following command from an elevated command prompt: **manage-bde -protectors -adbackup C:**.
-**Important**
-Joining a computer to the domain should be the first step for new computers within an organization. After computers are joined to a domain, storing the BitLocker recovery key to AD DS is automatic (when enabled in Group Policy).
-
+>**Important:** Joining a computer to the domain should be the first step for new computers within an organization. After computers are joined to a domain, storing the BitLocker recovery key to AD DS is automatic (when enabled in Group Policy).
-
### Is there an event log entry recorded on the client computer to indicate the success or failure of the Active Directory backup?
Yes, an event log entry that indicates the success or failure of an Active Directory backup is recorded on the client computer. However, even if an event log entry says "Success," the information could have been subsequently removed from AD DS, or BitLocker could have been reconfigured in such a way that the Active Directory information can no longer unlock the drive (such as by removing the recovery password key protector). In addition, it is also possible that the log entry could be spoofed.
@@ -363,7 +322,6 @@ When an administrator clears these check boxes, the administrator is allowing a
## Security
-
### What form of encryption does BitLocker use? Is it configurable?
BitLocker uses Advanced Encryption Standard (AES) as its encryption algorithm with configurable key lengths of 128 or 256 bits. The default encryption setting is AES-128, but the options are configurable by using Group Policy.
@@ -380,27 +338,23 @@ BitLocker on operating system drives in its basic configuration (with a TPM but
Most operating systems use a shared memory space and rely on the operating system to manage physical memory. A TPM is a hardware component that uses its own internal firmware and logic circuits for processing instructions, thus shielding it from external software vulnerabilities. Attacking the TPM requires physical access to the computer. Additionally, the tools and skills necessary to attack hardware are often more expensive, and usually are not as available as the ones used to attack software. And because each TPM is unique to the computer that contains it, attacking multiple TPM computers would be difficult and time-consuming.
-**Note**
-Configuring BitLocker with an additional factor of authentication provides even more protection against TPM hardware attacks.
-
+>**Note:** Configuring BitLocker with an additional factor of authentication provides even more protection against TPM hardware attacks.
-
## BitLocker Network Unlock
-
BitLocker Network Unlock enables easier management for BitLocker-enabled desktops and servers that use the TPM+PIN protection method in a domain environment. When a computer that is connected to a wired corporate network is rebooted, Network Unlock allows the PIN entry prompt to be bypassed. It automatically unlocks BitLocker-protected operating system volumes by using a trusted key that is provided by the Windows Deployment Services server as its secondary authentication method.
To use Network Unlock you must also have a PIN configured for your computer. When your computer is not connected to the network you will need to provide the PIN to unlock it.
BitLocker Network Unlock has software and hardware requirements for both client computers, Windows Deployment services, and domain controllers that must be met before you can use it.
-Network Unlock uses two protectors, the TPM protector and the one provided by the network or by your PIN, whereas automatic unlock uses a single protector, the one stored in the TPM. If the computer is joined to a network without the key protector it will prompt you to enter your PIN. If the PIN is not available you will need to use the recovery key to unlock the computer if it can ot be connected to the network.
+Network Unlock uses two protectors, the TPM protector and the one provided by the network or by your PIN, whereas automatic unlock uses a single protector, the one stored in the TPM. If the computer is joined to a network without the key protector it will prompt you to enter your PIN. If the PIN is
+not available you will need to use the recovery key to unlock the computer if it can ot be connected to the network.
For more info, see [BitLocker: How to enable Network Unlock](bitlocker-how-to-enable-network-unlock.md).
## Other questions
-
### Can I run a kernel debugger with BitLocker?
Yes. However, the debugger should be turned on before enabling BitLocker. Turning on the debugger ensures that the correct measurements are calculated when sealing to the TPM, allowing the computer to start properly. If you need to turn debugging on or off when using BitLocker, be sure to suspend BitLocker first to avoid putting your computer into recovery mode.
@@ -426,17 +380,11 @@ We do not recommend modifying the master boot record on computers whose operatin
The system check is designed to ensure your computer's BIOS or UEFI firmware is compatible with BitLocker and that the TPM is working correctly. The system check can fail for several reasons:
- The computer's BIOS or UEFI firmware cannot read USB flash drives.
-
- The computer's BIOS, uEFI firmware, or boot menu does not have reading USB flash drives enabled.
-
- There are multiple USB flash drives inserted into the computer.
-
- The PIN was not entered correctly.
-
- The computer's BIOS or UEFI firmware only supports using the function keys (F1–F10) to enter numerals in the pre-boot environment.
-
- The startup key was removed before the computer finished rebooting.
-
- The TPM has malfunctioned and fails to unseal the keys.
### What can I do if the recovery key on my USB flash drive cannot be read?
@@ -459,14 +407,11 @@ Limited BitLocker functionality is available in Safe Mode. BitLocker-protected d
Both fixed and removable data drives can be locked by using the Manage-bde command-line tool and the –lock command.
-**Note**
-Ensure all data is saved to the drive before locking it. Once locked, the drive will become inaccessible.
-
+>**Note:** Ensure all data is saved to the drive before locking it. Once locked, the drive will become inaccessible.
-
The syntax of this command is:
-**manage-bde** *<driveletter>* **-lock**
+`manage-bde -lock`
Outside of using this command, data drives will be locked on shutdown and restart of the operating system. A removable data drive will also be locked automatically when the drive is removed from the computer.
@@ -480,28 +425,11 @@ BitLocker is not supported on bootable VHDs, but BitLocker is supported on data
## More information
-
- [Prepare your organization for BitLocker: Planning and Policies](prepare-your-organization-for-bitlocker-planning-and-policies.md)
-
- [BitLocker Group Policy settings](bitlocker-group-policy-settings.md)
-
- [BCD settings and BitLocker](bcd-settings-and-bitlocker.md)
-
- [BitLocker: How to enable Network Unlock](bitlocker-how-to-enable-network-unlock.md)
-
- [BitLocker: How to deploy on Windows Server 2012](bitlocker-how-to-deploy-on-windows-server.md)
-
- [BitLocker: Use BitLocker Drive Encryption Tools to manage BitLocker](bitlocker-use-bitlocker-drive-encryption-tools-to-manage-bitlocker.md)
-
- [BitLocker: Use BitLocker Recovery Password Viewer](bitlocker-use-bitlocker-recovery-password-viewer.md)
-
- [BitLocker Cmdlets in Windows PowerShell](http://technet.microsoft.com/library/6f49f904-e04d-4b90-afbc-84bc45d4d30d)
-
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/bitlocker-group-policy-settings.md b/windows/keep-secure/bitlocker-group-policy-settings.md
index ca750b9147..77412bda71 100644
--- a/windows/keep-secure/bitlocker-group-policy-settings.md
+++ b/windows/keep-secure/bitlocker-group-policy-settings.md
@@ -5,130 +5,90 @@ ms.assetid: 4904e336-29fe-4cef-bb6c-3950541864af
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# BitLocker Group Policy settings
-
**Applies to**
-
- Windows 10
This topic for IT professionals describes the function, location, and effect of each Group Policy setting that is used to manage BitLocker Drive Encryption.
To control what drive encryption tasks the user can perform from the Windows Control Panel or to modify other configuration options, you can use Group Policy administrative templates or local computer policy settings. How you configure these policy settings depends on how you implement BitLocker and what level of user interaction will be allowed.
-**Note**
-A separate set of Group Policy settings supports the use of the Trusted Platform Module (TPM). For details about those settings, see [Trusted Platform Module Group Policy settings](trusted-platform-module-services-group-policy-settings.md).
-
+>**Note:** A separate set of Group Policy settings supports the use of the Trusted Platform Module (TPM). For details about those settings, see [Trusted Platform Module Group Policy settings](trusted-platform-module-services-group-policy-settings.md).
-
BitLocker Group Policy settings can be accessed using the Local Group Policy Editor and the Group Policy Management Console (GPMC) under **Computer Configuration\\Administrative Templates\\Windows Components\\BitLocker Drive Encryption**.
-
Most of the BitLocker Group Policy settings are applied when BitLocker is initially turned on for a drive. If a computer is not compliant with existing Group Policy settings, BitLocker may not be turned on or modified until the computer is in a compliant state. When a drive is out of compliance with Group Policy settings (for example, if a Group Policy setting was changed after the initial BitLocker deployment in your organization, and then the setting was applied to previously encrypted drives), no change can be made to the BitLocker configuration of that drive except a change that will bring it into compliance.
-If multiple changes are necessary to bring the drive into compliance, you must suspend BitLocker protection, make the necessary changes, and then resume protection. This situation could occur, for example, if a removable drive was initially configured to be unlocked with a password and then Group Policy settings are changed to disallow passwords and require smart cards. In this situation, you need to suspend BitLocker protection by using the [Manage-bde](http://technet.microsoft.com/library/ff829849.aspx) command-line tool, delete the password unlock method, and add the smart card method. After this is complete, BitLocker is compliant with the Group Policy setting and BitLocker protection on the drive can be resumed.
+If multiple changes are necessary to bring the drive into compliance, you must suspend BitLocker protection, make the necessary changes, and then resume protection. This situation could occur, for example, if a removable drive was initially configured to be unlocked with a password and then Group
+Policy settings are changed to disallow passwords and require smart cards. In this situation, you need to suspend BitLocker protection by using the [Manage-bde](http://technet.microsoft.com/library/ff829849.aspx) command-line tool, delete the password unlock method, and add the smart card method. After this is complete, BitLocker is compliant with the Group Policy setting and BitLocker protection on the drive can be resumed.
## BitLocker Group Policy settings
-
The following sections provide a comprehensive list of BitLocker Group Policy settings that are organized by usage. BitLocker Group Policy settings include settings for specific drive types (operating system drives, fixed data drives, and removable data drives) and settings that are applied to all drives.
The following policy settings can be used to determine how a BitLocker-protected drive can be unlocked.
- [Allow network unlock at startup](#bkmk-netunlock)
-
- [Require additional authentication at startup](#bkmk-unlockpol1)
-
- [Allow enhanced PINs for startup](#bkmk-unlockpol2)
-
- [Configure minimum PIN length for startup](#bkmk-unlockpol3)
-
- [Disallow standard users from changing the PIN or password](#bkmk-dpinchange)
-
- [Configure use of passwords for operating system drives](#bkmk-ospw)
-
- [Require additional authentication at startup (Windows Server 2008 and Windows Vista)](#bkmk-unlockpol4)
-
- [Configure use of smart cards on fixed data drives](#bkmk-unlockpol5)
-
- [Configure use of passwords on fixed data drives](#bkmk-unlockpol6)
-
- [Configure use of smart cards on removable data drives](#bkmk-unlockpol7)
-
- [Configure use of passwords on removable data drives](#bkmk-unlockpol8)
-
- [Validate smart card certificate usage rule compliance](#bkmk-unlockpol9)
-
- [Enable use of BitLocker authentication requiring preboot keyboard input on slates](#bkmk-slates)
The following policy settings are used to control how users can access drives and how they can use BitLocker on their computers.
- [Deny write access to fixed drives not protected by BitLocker](#bkmk-driveaccess1)
-
- [Deny write access to removable drives not protected by BitLocker](#bkmk-driveaccess2)
-
- [Control use of BitLocker on removable drives](#bkmk-driveaccess3)
The following policy settings determine the encryption methods and encryption types that are used with BitLocker.
- [Choose drive encryption method and cipher strength](#bkmk-encryptmeth)
-
- [Configure use of hardware-based encryption for fixed data drives](#bkmk-hdefxd)
-
- [Configure use of hardware-based encryption for operating system drives](#bkmk-hdeosd)
-
- [Configure use of hardware-based encryption for removable data drives](#bkmk-hderdd)
-
- [Enforce drive encryption type on fixed data drives](#bkmk-detypefdd)
-
- [Enforce drive encryption type on operating system drives](#bkmk-detypeosd)
-
- [Enforce drive encryption type on removable data drives](#bkmk-detyperdd)
The following policy settings define the recovery methods that can be used to restore access to a BitLocker-protected drive if an authentication method fails or is unable to be used.
- [Choose how BitLocker-protected operating system drives can be recovered](#bkmk-rec1)
-
- [Choose how users can recover BitLocker-protected drives (Windows Server 2008 and Windows Vista)](#bkmk-rec2)
-
- [Store BitLocker recovery information in Active Directory Domain Services (Windows Server 2008 and Windows Vista)](#bkmk-rec3)
-
- [Choose default folder for recovery password](#bkmk-rec4)
-
- [Choose how BitLocker-protected fixed drives can be recovered](#bkmk-rec6)
-
- [Choose how BitLocker-protected removable drives can be recovered](#bkmk-rec7)
-
- [Configure the pre-boot recovery message and URL](#bkmk-configurepreboot)
The following policies are used to support customized deployment scenarios in your organization.
- [Allow Secure Boot for integrity validation](#bkmk-secboot)
-
- [Provide the unique identifiers for your organization](#bkmk-depopt1)
-
- [Prevent memory overwrite on restart](#bkmk-depopt2)
-
- [Configure TPM platform validation profile for BIOS-based firmware configurations](#bkmk-tpmbios)
-
- [Configure TPM platform validation profile (Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2)](#bkmk-depopt3)
-
- [Configure TPM platform validation profile for native UEFI firmware configurations](#bkmk-tpmvaluefi)
-
- [Reset platform validation data after BitLocker recovery](#bkmk-resetrec)
-
- [Use enhanced Boot Configuration Data validation profile](#bkmk-enbcd)
-
- [Allow access to BitLocker-protected fixed data drives from earlier versions of Windows](#bkmk-depopt4)
-
- [Allow access to BitLocker-protected removable data drives from earlier versions of Windows](#bkmk-depopt5)
### Allow network unlock at startup
This policy controls a portion of the behavior of the Network Unlock feature in BitLocker. This policy is required to enable BitLocker Network Unlock on a network because it allows clients running BitLocker to create the necessary network key protector during encryption. This policy is used in addition to the BitLocker Drive Encryption Network Unlock Certificate security policy (located in the **Public Key Policies** folder of Local Computer Policy) to allow systems that are connected to a trusted network to properly utilize the Network Unlock feature.
-
+
@@ -165,18 +125,13 @@ This policy controls a portion of the behavior of the Network Unlock feature in
-
-
**Reference**
To use a network key protector to unlock the computer, the computer and the server that hosts BitLocker Drive Encryption Network Unlock must be provisioned with a Network Unlock certificate. The Network Unlock certificate is used to create a network key protector and to protect the information exchange with the server to unlock the computer. You can use the Group Policy setting **Computer Configuration\\Windows Settings\\Security Settings\\Public Key Policies\\BitLocker Drive Encryption Network Unlock Certificate** on the domain controller to distribute this certificate to computers in your organization. This unlock method uses the TPM on the computer, so computers that do not have a TPM cannot create network key protectors to automatically unlock by using Network Unlock.
-**Note**
-For reliability and security, computers should also have a TPM startup PIN that can be used when the computer is disconnected from the wired network or cannot connect to the domain controller at startup.
-
+>**Note:** For reliability and security, computers should also have a TPM startup PIN that can be used when the computer is disconnected from the wired network or cannot connect to the domain controller at startup.
-
For more information about Network Unlock, see [BitLocker: How to enable Network Unlock](bitlocker-how-to-enable-network-unlock.md).
### Require additional authentication at startup
@@ -221,9 +176,7 @@ This policy setting is used to control which unlock options are available for op
-
-
**Reference**
If you want to use BitLocker on a computer without a TPM, select the **Allow BitLocker without a compatible TPM** check box. In this mode, a USB drive is required for startup. Key information that is used to encrypt the drive is stored on the USB drive, which creates a USB key. When the USB key is inserted, access to the drive is authenticated and the drive is accessible. If the USB key is lost or unavailable, you need to use one of the BitLocker recovery options to access the drive.
@@ -231,11 +184,8 @@ If you want to use BitLocker on a computer without a TPM, select the **Allow Bit
On a computer with a compatible TPM, four types of authentication methods can be used at startup to provide added protection for encrypted data. When the computer starts, it can use:
- only the TPM for authentication
-
- insertion of a USB flash drive containing the startup key
-
- the entry of a 4-digit to 20-digit personal identification number (PIN)
-
- a combination of the PIN and the USB flash drive
There are four options for TPM-enabled computers or devices:
@@ -243,33 +193,22 @@ There are four options for TPM-enabled computers or devices:
- Configure TPM startup
- Allow TPM
-
- Require TPM
-
- Do not allow TPM
-
- Configure TPM startup PIN
- Allow startup PIN with TPM
-
- Require startup PIN with TPM
-
- Do not allow startup PIN with TPM
-
- Configure TPM startup key
- Allow startup key with TPM
-
- Require startup key with TPM
-
- Do not allow startup key with TPM
-
- Configure TPM startup key and PIN
- Allow TPM startup key with PIN
-
- Require startup key and PIN with TPM
-
- Do not allow TPM startup key with PIN
### Allow enhanced PINs for startup
@@ -312,18 +251,14 @@ This policy setting permits the use of enhanced PINs when you use an unlock meth
-
**Reference**
Enhanced startup PINs permit the use of characters (including uppercase and lowercase letters, symbols, numbers, and spaces). This policy setting is applied when you turn on BitLocker.
-**Important**
-Not all computers support enhanced PIN characters in the preboot environment. It is strongly recommended that users perform a system check during the BitLocker setup to verify that enhanced PIN characters can be used.
-
+>**Important:** Not all computers support enhanced PIN characters in the preboot environment. It is strongly recommended that users perform a system check during the BitLocker setup to verify that enhanced PIN characters can be used.
-
### Configure minimum PIN length for startup
This policy setting is used to set a minimum PIN length when you use an unlock method that includes a PIN.
@@ -364,9 +299,7 @@ This policy setting is used to set a minimum PIN length when you use an unlock m
-
-
**Reference**
This policy setting is applied when you turn on BitLocker. The startup PIN must have a minimum length of 4 digits and can have a maximum length of 20 digits.
@@ -411,7 +344,6 @@ This policy setting allows you to configure whether standard users are allowed t
-
**Reference**
@@ -465,28 +397,21 @@ This policy controls how non-TPM based systems utilize the password protector. U
-
**Reference**
If non-TPM protectors are allowed on operating system drives, you can provision a password, enforce complexity requirements on the password, and configure a minimum length for the password. For the complexity requirement setting to be effective, the Group Policy setting **Password must meet complexity requirements**, which is located at **Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Password Policy\\** must be also enabled.
-**Note**
-These settings are enforced when turning on BitLocker, not when unlocking a volume. BitLocker allows unlocking a drive with any of the protectors that are available on the drive.
-
+>**Note:** These settings are enforced when turning on BitLocker, not when unlocking a volume. BitLocker allows unlocking a drive with any of the protectors that are available on the drive.
-
When set to **Require complexity**, a connection to a domain controller is necessary when BitLocker is enabled to validate the complexity the password. When set to **Allow complexity**, a connection to a domain controller is attempted to validate that the complexity adheres to the rules set by the policy. If no domain controllers are found, the password will be accepted regardless of actual password complexity, and the drive will be encrypted by using that password as a protector. When set to **Do not allow complexity**, there is no password complexity validation.
-
Passwords must be at least 8 characters. To configure a greater minimum length for the password, enter the desired number of characters in the **Minimum password length** box.
When this policy setting is enabled, you can set the option **Configure password complexity for operating system drives** to:
- Allow password complexity
-
- Do not allow password complexity
-
- Require password complexity
### Require additional authentication at startup (Windows Server 2008 and Windows Vista)
@@ -529,9 +454,7 @@ This policy setting is used to control what unlock options are available for com
-
-
**Reference**
On a computer with a compatible TPM, two authentication methods can be used at startup to provide added protection for encrypted data. When the computer starts, it can require users to insert a USB drive that contains a startup key. It can also require users to enter a 4-digit to 20-digit startup PIN.
@@ -543,17 +466,12 @@ There are two options for TPM-enabled computers or devices:
- Configure TPM startup PIN
- Allow startup PIN with TPM
-
- Require startup PIN with TPM
-
- Do not allow startup PIN with TPM
-
- Configure TPM startup key
- Allow startup key with TPM
-
- Require startup key with TPM
-
- Do not allow startup key with TPM
These options are mutually exclusive. If you require the startup key, you must not allow the startup PIN. If you require the startup PIN, you must not allow the startup key. Otherwise, a policy error will occur.
@@ -604,16 +522,11 @@ This policy setting is used to require, allow, or deny the use of smart cards wi
-
-
**Reference**
-**Note**
-These settings are enforced when turning on BitLocker, not when unlocking a drive. BitLocker allows unlocking a drive by using any of the protectors that are available on the drive.
-
+>**Note:** These settings are enforced when turning on BitLocker, not when unlocking a drive. BitLocker allows unlocking a drive by using any of the protectors that are available on the drive.
-
### Configure use of passwords on fixed data drives
This policy setting is used to require, allow, or deny the use of passwords with fixed data drives.
@@ -658,9 +571,7 @@ This policy setting is used to require, allow, or deny the use of passwords with
-
-
**Reference**
When set to **Require complexity**, a connection to a domain controller is necessary to validate the complexity of the password when BitLocker is enabled.
@@ -671,22 +582,15 @@ When set to **Do not allow complexity**, no password complexity validation is pe
Passwords must be at least 8 characters. To configure a greater minimum length for the password, enter the desired number of characters in the **Minimum password length** box.
-**Note**
-These settings are enforced when turning on BitLocker, not when unlocking a drive. BitLocker allows unlocking a drive with any of the protectors that are available on the drive.
-
+>**Note:** These settings are enforced when turning on BitLocker, not when unlocking a drive. BitLocker allows unlocking a drive with any of the protectors that are available on the drive.
-
For the complexity requirement setting to be effective, the Group Policy setting **Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Password Policy\\Password must meet complexity requirements** must also be enabled.
-
This policy setting is configured on a per-computer basis. This means that it applies to local user accounts and domain user accounts. Because the password filter that is used to validate password complexity is located on the domain controllers, local user accounts cannot access the password filter because they are not authenticated for domain access. When this policy setting is enabled, if you sign in with a local user account, and you attempt to encrypt a drive or change a password on an existing BitLocker-protected drive, an "Access denied" error message is displayed. In this situation, the password key protector cannot be added to the drive.
Enabling this policy setting requires that connectivity to a domain be established before adding a password key protector to a BitLocker-protected drive. Users who work remotely and have periods of time in which they cannot connect to the domain should be made aware of this requirement so that they can schedule a time when they will be connected to the domain to turn on BitLocker or to change a password on a BitLocker-protected data drive.
-**Important**
-Passwords cannot be used if FIPS compliance is enabled. The **System cryptography: Use FIPS-compliant algorithms for encryption, hashing, and signing** policy setting in **Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options** specifies whether FIPS compliance is enabled.
-
+>**Important:** Passwords cannot be used if FIPS compliance is enabled. The **System cryptography: Use FIPS-compliant algorithms for encryption, hashing, and signing** policy setting in **Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options** specifies whether FIPS compliance is enabled.
-
### Configure use of smart cards on removable data drives
This policy setting is used to require, allow, or deny the use of smart cards with removable data drives.
@@ -731,16 +635,11 @@ This policy setting is used to require, allow, or deny the use of smart cards wi
-
-
**Reference**
-**Note**
-These settings are enforced when turning on BitLocker, not when unlocking a drive. BitLocker allows unlocking a drive with any of the protectors that are available on the drive.
-
+>**Note:** These settings are enforced when turning on BitLocker, not when unlocking a drive. BitLocker allows unlocking a drive with any of the protectors that are available on the drive.
-
### Configure use of passwords on removable data drives
This policy setting is used to require, allow, or deny the use of passwords with removable data drives.
@@ -785,18 +684,14 @@ This policy setting is used to require, allow, or deny the use of passwords with
-
-
**Reference**
-If you choose to allow the use of a password, you can require a password to be used, enforce complexity requirements, and configure a minimum length. For the complexity requirement setting to be effective, the Group Policy setting **Password must meet complexity requirements**, which is located at **Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Password Policy** must also be enabled.
-
-**Note**
-These settings are enforced when turning on BitLocker, not when unlocking a drive. BitLocker allows unlocking a drive with any of the protectors that are available on the drive.
+If you choose to allow the use of a password, you can require a password to be used, enforce complexity requirements, and configure a minimum length. For the complexity requirement setting to be effective, the Group Policy setting **Password must meet complexity requirements**, which is located at
+**Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Password Policy** must also be enabled.
+>**Note:** These settings are enforced when turning on BitLocker, not when unlocking a drive. BitLocker allows unlocking a drive with any of the protectors that are available on the drive.
-
Passwords must be at least 8 characters. To configure a greater minimum length for the password, enter the desired number of characters in the **Minimum password length** box.
When set to **Require complexity**, a connection to a domain controller is necessary when BitLocker is enabled to validate the complexity the password.
@@ -805,11 +700,8 @@ When set to **Allow complexity**, a connection to a domain controller will be at
When set to **Do not allow complexity**, no password complexity validation will be done.
-**Note**
-Passwords cannot be used if FIPS compliance is enabled. The **System cryptography: Use FIPS-compliant algorithms for encryption, hashing, and signing** policy setting in **Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options** specifies whether FIPS compliance is enabled.
-
+>**Note:** Passwords cannot be used if FIPS compliance is enabled. The **System cryptography: Use FIPS-compliant algorithms for encryption, hashing, and signing** policy setting in **Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options** specifies whether FIPS compliance is enabled.
-
For information about this setting, see [System cryptography: Use FIPS-compliant algorithms for encryption, hashing, and signing](http://technet.microsoft.com/library/jj852211.aspx).
### Validate smart card certificate usage rule compliance
@@ -852,9 +744,7 @@ This policy setting is used to determine what certificate to use with BitLocker.
-
-
**Reference**
This policy setting is applied when you turn on BitLocker.
@@ -863,11 +753,8 @@ The object identifier is specified in the enhanced key usage (EKU) of a certific
The default object identifier is 1.3.6.1.4.1.311.67.1.1.
-**Note**
-BitLocker does not require that a certificate have an EKU attribute; however, if one is configured for the certificate, it must be set to an object identifier that matches the object identifier configured for BitLocker.
-
+>**Note:** BitLocker does not require that a certificate have an EKU attribute; however, if one is configured for the certificate, it must be set to an object identifier that matches the object identifier configured for BitLocker.
-
### Enable use of BitLocker authentication requiring preboot keyboard input on slates
This policy setting allows users to enable authentication options that require user input from the preboot environment even if the platform indicates a lack of preboot input capability.
@@ -908,9 +795,7 @@ This policy setting allows users to enable authentication options that require u
-
-
**Reference**
The Windows touch keyboard (such as used by tablets) is not available in the preboot environment where BitLocker requires additional information, such as a PIN or password.
@@ -922,9 +807,7 @@ When the Windows Recovery Environment is not enabled and this policy is not enab
If you do not enable this policy setting, the following options in the **Require additional authentication at startup** policy might not be available:
- Configure TPM startup PIN: Required and Allowed
-
- Configure TPM startup key and PIN: Required and Allowed
-
- Configure use of passwords for operating system drives
### Deny write access to fixed drives not protected by BitLocker
@@ -967,9 +850,7 @@ This policy setting is used to require encryption of fixed drives prior to grant
-
-
**Reference**
This policy setting is applied when you turn on BitLocker.
@@ -977,15 +858,11 @@ This policy setting is applied when you turn on BitLocker.
Conflict considerations include:
1. When this policy setting is enabled, users receive "Access denied" error messages when they try to save data to unencrypted fixed data drives. See the Reference section for additional conflicts.
-
2. If BdeHdCfg.exe is run on a computer when this policy setting is enabled, you could encounter the following issues:
- If you attempted to shrink the drive and create the system drive, the drive size is successfully reduced and a raw partition is created. However, the raw partition is not formatted. The following error message is displayed: "The new active drive cannot be formatted. You may need to manually prepare your drive for BitLocker."
-
- If you attempt to use unallocated space to create the system drive, a raw partition will be created. However, the raw partition will not be formatted. The following error message is displayed: "The new active drive cannot be formatted. You may need to manually prepare your drive for BitLocker."
-
- If you attempt to merge an existing drive into the system drive, the tool fails to copy the required boot file onto the target drive to create the system drive. The following error message is displayed: "BitLocker setup failed to copy boot files. You may need to manually prepare your drive for BitLocker."
-
3. If this policy setting is enforced, a hard drive cannot be repartitioned because the drive is protected. If you are upgrading computers in your organization from a previous version of Windows, and those computers were configured with a single partition, you should create the required BitLocker system partition before you apply this policy setting to the computers.
### Deny write access to removable drives not protected by BitLocker
@@ -1028,24 +905,17 @@ This policy setting is used to require that removable drives are encrypted prior
-
-
**Reference**
If the **Deny write access to devices configured in another organization** option is selected, only drives with identification fields that match the computer's identification fields are given Write access. When a removable data drive is accessed, it is checked for a valid identification field and allowed identification fields. These fields are defined by the **Provide the unique identifiers for your organization** policy setting.
-**Note**
-You can override this policy setting with the policy settings under **User Configuration\\Administrative Templates\\System\\Removable Storage Access**. If the **Removable Disks: Deny write access** policy setting is enabled, this policy setting will be ignored.
-
+>**Note:** You can override this policy setting with the policy settings under **User Configuration\\Administrative Templates\\System\\Removable Storage Access**. If the **Removable Disks: Deny write access** policy setting is enabled, this policy setting will be ignored.
-
Conflict considerations include:
1. Use of BitLocker with the TPM plus a startup key or with the TPM plus a PIN and startup key must be disallowed if the **Deny write access to removable drives not protected by BitLocker** policy setting is enabled.
-
2. Use of recovery keys must be disallowed if the **Deny write access to removable drives not protected by BitLocker** policy setting is enabled.
-
3. You must enable the **Provide the unique identifiers for your organization** policy setting if you want to deny Write access to drives that were configured in another organization.
### Control use of BitLocker on removable drives
@@ -1092,9 +962,7 @@ This policy setting is used to prevent users from turning BitLocker on or off on
-
-
**Reference**
This policy setting is applied when you turn on BitLocker.
@@ -1104,7 +972,6 @@ For information about suspending BitLocker protection, see [BitLocker Basic Depl
The options for choosing property settings that control how users can configure BitLocker are:
- **Allow users to apply BitLocker protection on removable data drives** Enables the user to run the BitLocker Setup Wizard on a removable data drive.
-
- **Allow users to suspend and decrypt BitLocker on removable data drives** Enables the user to remove BitLocker from the drive or to suspend the encryption while performing maintenance.
### Choose drive encryption method and cipher strength
@@ -1147,20 +1014,14 @@ This policy setting is used to control the encryption method and cipher strength
-
-
**Reference**
By default, BitLocker uses AES 128-bit encryption. Available options are AES-128 and AES-256. The values of this policy determine the strength of the cipher that BitLocker uses for encryption. Enterprises may want to control the encryption level for increased security (AES-256 is stronger than AES-128).
-
Changing the encryption method has no effect if the drive is already encrypted or if encryption is in progress. In these cases, this policy setting is ignored.
-**Warning**
-This policy does not apply to encrypted drives. Encrypted drives utilize their own algorithm, which is set by the drive during partitioning.
-
+>**Warning:** This policy does not apply to encrypted drives. Encrypted drives utilize their own algorithm, which is set by the drive during partitioning.
-
When this policy setting is disabled, BitLocker uses AES with the same bit strength (128-bit or 256-bit) as specified in the policy setting **Choose drive encryption method and cipher strength (Windows Vista, Windows Server 2008, Windows 7)**. If neither policy is set, BitLocker uses the default encryption method, AES-128, or the encryption method that is specified in the setup script.
### Configure use of hardware-based encryption for fixed data drives
@@ -1207,20 +1068,14 @@ This policy controls how BitLocker reacts to systems that are equipped with encr
-
-
**Reference**
-**Note**
-The **Choose drive encryption method and cipher strength** policy setting does not apply to hardware-based encryption.
-
+>**Note:** The **Choose drive encryption method and cipher strength** policy setting does not apply to hardware-based encryption.
-
The encryption algorithm that is used by hardware-based encryption is set when the drive is partitioned. By default, BitLocker uses the algorithm that is configured on the drive to encrypt the drive. The **Restrict encryption algorithms and cipher suites allowed for hardware-based encryption** option of this setting enables you to restrict the encryption algorithms that BitLocker can use with hardware encryption. If the algorithm that is set for the drive is not available, BitLocker disables the use of hardware-based encryption. Encryption algorithms are specified by object identifiers (OID), for example:
- Advanced Encryption Standard (AES) 128 in Cipher Block Chaining (CBC) mode OID: 2.16.840.1.101.3.4.1.2
-
- AES 256 in CBC mode OID: 2.16.840.1.101.3.4.1.42
### Configure use of hardware-based encryption for operating system drives
@@ -1267,22 +1122,16 @@ This policy controls how BitLocker reacts when encrypted drives are used as oper
-
-
**Reference**
If hardware-based encryption is not available, BitLocker software-based encryption is used instead.
-**Note**
-The **Choose drive encryption method and cipher strength** policy setting does not apply to hardware-based encryption.
-
+>**Note:** The **Choose drive encryption method and cipher strength** policy setting does not apply to hardware-based encryption.
-
The encryption algorithm that is used by hardware-based encryption is set when the drive is partitioned. By default, BitLocker uses the algorithm that is configured on the drive to encrypt the drive. The **Restrict encryption algorithms and cipher suites allowed for hardware-based encryption** option of this setting enables you to restrict the encryption algorithms that BitLocker can use with hardware encryption. If the algorithm that is set for the drive is not available, BitLocker disables the use of hardware-based encryption. Encryption algorithms are specified by object identifiers (OID), for example:
- Advanced Encryption Standard (AES) 128 in Cipher Block Chaining (CBC) mode OID: 2.16.840.1.101.3.4.1.2
-
- AES 256 in CBC mode OID: 2.16.840.1.101.3.4.1.42
### Configure use of hardware-based encryption for removable data drives
@@ -1329,22 +1178,16 @@ This policy controls how BitLocker reacts to encrypted drives when they are used
-
-
**Reference**
If hardware-based encryption is not available, BitLocker software-based encryption is used instead.
-**Note**
-The **Choose drive encryption method and cipher strength** policy setting does not apply to hardware-based encryption.
-
+>**Note:** The **Choose drive encryption method and cipher strength** policy setting does not apply to hardware-based encryption.
-
The encryption algorithm that is used by hardware-based encryption is set when the drive is partitioned. By default, BitLocker uses the algorithm that is configured on the drive to encrypt the drive. The **Restrict encryption algorithms and cipher suites allowed for hardware-based encryption** option of this setting enables you to restrict the encryption algorithms that BitLocker can use with hardware encryption. If the algorithm that is set for the drive is not available, BitLocker disables the use of hardware-based encryption. Encryption algorithms are specified by object identifiers (OID), for example:
- Advanced Encryption Standard (AES) 128 in Cipher Block Chaining (CBC) mode OID: 2.16.840.1.101.3.4.1.2
-
- AES 256 in CBC mode OID: 2.16.840.1.101.3.4.1.42
### Enforce drive encryption type on fixed data drives
@@ -1387,18 +1230,13 @@ This policy controls whether fixed data drives utilize Used Space Only encryptio
-
-
**Reference**
This policy setting is applied when you turn on BitLocker. Changing the encryption type has no effect if the drive is already encrypted or if encryption is in progress. Choose Full encryption to require that the entire drive be encrypted when BitLocker is turned on. Choose Used Space Only encryption to require that only the portion of the drive that is used to store data is encrypted when BitLocker is turned on.
-**Note**
-This policy is ignored when you are shrinking or expanding a volume and the BitLocker driver uses the current encryption method. For example, when a drive that is using Used Space Only encryption is expanded, the new free space is not wiped as it would be for a drive that is using Full encryption. The user could wipe the free space on a Used Space Only drive by using the following command: **manage-bde -w**. If the volume is shrunk, no action is taken for the new free space.
-
+>**Note:** This policy is ignored when you are shrinking or expanding a volume and the BitLocker driver uses the current encryption method. For example, when a drive that is using Used Space Only encryption is expanded, the new free space is not wiped as it would be for a drive that is using Full encryption. The user could wipe the free space on a Used Space Only drive by using the following command: **manage-bde -w**. If the volume is shrunk, no action is taken for the new free space.
-
For more information about the tool to manage BitLocker, see [Manage-bde](https://technet.microsoft.com/library/ff829849.aspx).
### Enforce drive encryption type on operating system drives
@@ -1441,18 +1279,13 @@ This policy controls whether operating system drives utilize Full encryption or
-
-
**Reference**
This policy setting is applied when you turn on BitLocker. Changing the encryption type has no effect if the drive is already encrypted or if encryption is in progress. Choose Full encryption to require that the entire drive be encrypted when BitLocker is turned on. Choose Used Space Only encryption to require that only the portion of the drive that is used to store data is encrypted when BitLocker is turned on.
-**Note**
-This policy is ignored when shrinking or expanding a volume, and the BitLocker driver uses the current encryption method. For example, when a drive that is using Used Space Only encryption is expanded, the new free space is not wiped as it would be for a drive that uses Full encryption. The user could wipe the free space on a Used Space Only drive by using the following command: **manage-bde -w**. If the volume is shrunk, no action is taken for the new free space.
-
+>**Note:** This policy is ignored when shrinking or expanding a volume, and the BitLocker driver uses the current encryption method. For example, when a drive that is using Used Space Only encryption is expanded, the new free space is not wiped as it would be for a drive that uses Full encryption. The user could wipe the free space on a Used Space Only drive by using the following command: **manage-bde -w**. If the volume is shrunk, no action is taken for the new free space.
-
For more information about the tool to manage BitLocker, see [Manage-bde](https://technet.microsoft.com/library/ff829849.aspx).
### Enforce drive encryption type on removable data drives
@@ -1495,18 +1328,13 @@ This policy controls whether fixed data drives utilize Full encryption or Used S
-
-
**Reference**
This policy setting is applied when you turn on BitLocker. Changing the encryption type has no effect if the drive is already encrypted or if encryption is in progress. Choose Full encryption to require that the entire drive be encrypted when BitLocker is turned on. Choose Used Space Only encryption to require that only the portion of the drive that is used to store data is encrypted when BitLocker is turned on.
-**Note**
-This policy is ignored when shrinking or expanding a volume, and the BitLocker driver uses the current encryption method. For example, when a drive that is using Used Space Only encryption is expanded, the new free space is not wiped as it would be for a drive that is using Full Encryption. The user could wipe the free space on a Used Space Only drive by using the following command: **manage-bde -w**. If the volume is shrunk, no action is taken for the new free space.
-
+>**Note:** This policy is ignored when shrinking or expanding a volume, and the BitLocker driver uses the current encryption method. For example, when a drive that is using Used Space Only encryption is expanded, the new free space is not wiped as it would be for a drive that is using Full Encryption. The user could wipe the free space on a Used Space Only drive by using the following command: **manage-bde -w**. If the volume is shrunk, no action is taken for the new free space.
-
For more information about the tool to manage BitLocker, see [Manage-bde](https://technet.microsoft.com/library/ff829849.aspx).
### Choose how BitLocker-protected operating system drives can be recovered
@@ -1550,9 +1378,7 @@ This policy setting is used to configure recovery methods for operating system d
-
-
**Reference**
This policy setting is applied when you turn on BitLocker.
@@ -1563,17 +1389,15 @@ For more information about adding data recovery agents, see [BitLocker basic dep
In **Configure user storage of BitLocker recovery information**, select whether users are allowed, required, or not allowed to generate a 48-digit recovery password.
-Select **Omit recovery options from the BitLocker setup wizard** to prevent users from specifying recovery options when they enable BitLocker on a drive. This means that you will not be able to specify which recovery option to use when you enable BitLocker. Instead, BitLocker recovery options for the drive are determined by the policy setting.
+Select **Omit recovery options from the BitLocker setup wizard** to prevent users from specifying recovery options when they enable BitLocker on a drive. This means that you will not be able to specify which recovery option to use when you enable BitLocker. Instead, BitLocker recovery options for
+the drive are determined by the policy setting.
In **Save BitLocker recovery information to Active Directory Domain Services**, choose which BitLocker recovery information to store in Active Directory Domain Services (AD DS) for operating system drives. If you select **Store recovery password and key packages**, the BitLocker recovery password and the key package are stored in AD DS. Storing the key package supports recovering data from a drive that is physically corrupted. If you select **Store recovery password only**, only the recovery password is stored in AD DS.
Select the **Do not enable BitLocker until recovery information is stored in AD DS for operating system drives** check box if you want to prevent users from enabling BitLocker unless the computer is connected to the domain and the backup of BitLocker recovery information to AD DS succeeds.
-**Note**
-If the **Do not enable BitLocker until recovery information is stored in AD DS for operating system drives** check box is selected, a recovery password is automatically generated.
-
+>**Note:** If the **Do not enable BitLocker until recovery information is stored in AD DS for operating system drives** check box is selected, a recovery password is automatically generated.
-
### Choose how users can recover BitLocker-protected drives (Windows Server 2008 and Windows Vista)
This policy setting is used to configure recovery methods for BitLocker-protected drives on computers running Windows Server 2008 or Windows Vista.
@@ -1614,9 +1438,7 @@ This policy setting is used to configure recovery methods for BitLocker-protecte
-
-
**Reference**
This policy is only applicable to computers running Windows Server 2008 or Windows Vista. This policy setting is applied when you turn on BitLocker.
@@ -1625,18 +1447,11 @@ Two recovery options can be used to unlock BitLocker-encrypted data in the absen
Saving the recovery password to a USB drive stores the 48-digit recovery password as a text file and the 256-bit recovery key as a hidden file. Saving it to a folder stores the 48-digit recovery password as a text file. Printing it sends the 48-digit recovery password to the default printer. For example, not allowing the 48-digit recovery password prevents users from printing or saving recovery information to a folder.
-**Important**
-If TPM initialization is performed during the BitLocker setup, TPM owner information is saved or printed with the BitLocker recovery information.
-
+>**Important:** If TPM initialization is performed during the BitLocker setup, TPM owner information is saved or printed with the BitLocker recovery information.
The 48-digit recovery password is not available in FIPS-compliance mode.
-
-
-**Important**
-To prevent data loss, you must have a way to recover BitLocker encryption keys. If you do not allow both recovery options, you must enable the backup of BitLocker recovery information to AD DS. Otherwise, a policy error occurs.
-
+>**Important:** To prevent data loss, you must have a way to recover BitLocker encryption keys. If you do not allow both recovery options, you must enable the backup of BitLocker recovery information to AD DS. Otherwise, a policy error occurs.
-
### Store BitLocker recovery information in Active Directory Domain Services (Windows Server 2008 and Windows Vista)
This policy setting is used to configure the storage of BitLocker recovery information in AD DS. This provides an administrative method of recovering data that is encrypted by BitLocker to prevent data loss due to lack of key information.
@@ -1677,9 +1492,7 @@ This policy setting is used to configure the storage of BitLocker recovery infor
-
-
**Reference**
This policy is only applicable to computers running Windows Server 2008 or Windows Vista.
@@ -1693,11 +1506,9 @@ If you select **Require BitLocker backup to AD DS**, BitLocker cannot be turned
A recovery password is a 48-digit number that unlocks access to a BitLocker-protected drive. A key package contains a drive’s BitLocker encryption key, which is secured by one or more recovery passwords. Key packages may help perform specialized recovery when the disk is damaged or corrupted.
If the **Require BitLocker backup to AD DS** option is not selected, AD DS backup is attempted, but network or other backup failures do not prevent the BitLocker setup. The Backup process is not automatically retried, and the recovery password might not be stored in AD DS during BitLocker setup.
-
TPM initialization might be needed during the BitLocker setup. Enable the **Turn on TPM backup to Active Directory Domain Services** policy setting in **Computer Configuration\\Administrative Templates\\System\\Trusted Platform Module Services** to ensure that TPM information is also backed up.
For more information about this setting, see [TPM Group Policy settings](trusted-platform-module-services-group-policy-settings.md).
-
If you are using domain controllers running Windows Server 2003 with Service Pack 1, you must first set up appropriate schema extensions and access control settings on the domain before a backup to AD DS can succeed. For more info, see [Backup the TPM recovery Information to AD DS](backup-tpm-recovery-information-to-ad-ds.md).
### Choose default folder for recovery password
@@ -1740,18 +1551,13 @@ This policy setting is used to configure the default folder for recovery passwor
-
-
**Reference**
This policy setting is applied when you turn on BitLocker.
-**Note**
-This policy setting does not prevent the user from saving the recovery password in another folder.
-
+>**Note:** This policy setting does not prevent the user from saving the recovery password in another folder.
-
### Choose how BitLocker-protected fixed drives can be recovered
This policy setting is used to configure recovery methods for fixed data drives.
@@ -1793,9 +1599,7 @@ This policy setting is used to configure recovery methods for fixed data drives.
-
-
**Reference**
This policy setting is applied when you turn on BitLocker.
@@ -1806,17 +1610,15 @@ In **Configure user storage of BitLocker recovery information**, select whether
Select **Omit recovery options from the BitLocker setup wizard** to prevent users from specifying recovery options when they enable BitLocker on a drive. This means that you cannot specify which recovery option to use when you enable BitLocker. Instead, BitLocker recovery options for the drive are determined by the policy setting.
-In **Save BitLocker recovery information to Active Directory Doman Services**, choose which BitLocker recovery information to store in AD DS for fixed data drives. If you select **Backup recovery password and key package**, the BitLocker recovery password and the key package are stored in AD DS. Storing the key package supports recovering data from a drive that has been physically corrupted. To recover this data, you can use the **Repair-bde** command-line tool. If you select **Backup recovery password only**, only the recovery password is stored in AD DS.
+In **Save BitLocker recovery information to Active Directory Doman Services**, choose which BitLocker recovery information to store in AD DS for fixed data drives. If you select **Backup recovery password and key package**, the BitLocker recovery password and the key package are stored in AD DS.
+Storing the key package supports recovering data from a drive that has been physically corrupted. To recover this data, you can use the **Repair-bde** command-line tool. If you select **Backup recovery password only**, only the recovery password is stored in AD DS.
For more information about the BitLocker repair tool, see [Repair-bde](http://technet.microsoft.com/library/ff829851.aspx).
Select the **Do not enable BitLocker until recovery information is stored in AD DS for fixed data drives** check box if you want to prevent users from enabling BitLocker unless the computer is connected to the domain and the backup of BitLocker recovery information to AD DS succeeds.
-**Note**
-If the **Do not enable BitLocker until recovery information is stored in AD DS for fixed data drives** check box is selected, a recovery password is automatically generated.
-
+>**Note:** If the **Do not enable BitLocker until recovery information is stored in AD DS for fixed data drives** check box is selected, a recovery password is automatically generated.
-
### Choose how BitLocker-protected removable drives can be recovered
This policy setting is used to configure recovery methods for removable data drives.
@@ -1858,9 +1660,7 @@ This policy setting is used to configure recovery methods for removable data dri
-
-
**Reference**
This policy setting is applied when you turn on BitLocker.
@@ -1875,11 +1675,8 @@ In **Save BitLocker recovery information to Active Directory Domain Services**,
Select the **Do not enable BitLocker until recovery information is stored in AD DS for removable data drives** check box if you want to prevent users from enabling BitLocker unless the computer is connected to the domain and the backup of BitLocker recovery information to AD DS succeeds.
-**Note**
-If the **Do not enable BitLocker until recovery information is stored in AD DS for fixed data drives** check box is selected, a recovery password is automatically generated.
-
+>**Note:** If the **Do not enable BitLocker until recovery information is stored in AD DS for fixed data drives** check box is selected, a recovery password is automatically generated.
-
### Configure the pre-boot recovery message and URL
This policy setting is used to configure the entire recovery message and to replace the existing URL that is displayed on the pre-boot recovery screen when the operating system drive is locked.
@@ -1920,9 +1717,7 @@ This policy setting is used to configure the entire recovery message and to repl
-
-
**Reference**
Enabling the **Configure the pre-boot recovery message and URL** policy setting allows you to customize the default recovery screen message and URL to assist customers in recovering their key.
@@ -1930,21 +1725,13 @@ Enabling the **Configure the pre-boot recovery message and URL** policy setting
Once you enable the setting you have three options:
- If you select the **Use default recovery message and URL** option, the default BitLocker recovery message and URL will be displayed on the pre-boot recovery screen.
-
- If you select the **Use custom recovery message** option, type the custom message in the **Custom recovery message option** text box. The message that you type in the **Custom recovery message option** text box will be displayed on the pre-boot recovery screen. If a recovery URL is available, include it in the message.
-
- If you select the **Use custom recovery URL** option, type the custom message URL in the **Custom recovery URL option** text box. The URL that you type in the **Custom recovery URL option** text box replaces the default URL in the default recovery message, which will be displayed on the pre-boot recovery screen.
-**Important**
-Not all characters and languages are supported in the pre-boot environment. We strongly recommended that you verify the correct appearance of the characters that you use for the custom message and URL on the pre-boot recovery screen.
-
+>**Important:** Not all characters and languages are supported in the pre-boot environment. We strongly recommended that you verify the correct appearance of the characters that you use for the custom message and URL on the pre-boot recovery screen.
-
-**Important**
-Because you can alter the BCDEdit commands manually before you have set Group Policy settings, you cannot return the policy setting to the default setting by selecting the **Not Configured** option after you have configured this policy setting. To return to the default pre-boot recovery screen leave the policy setting enabled and select the **Use default message** options from the **Choose an option for the pre-boot recovery message** drop-down list box.
-
+>**Important:** Because you can alter the BCDEdit commands manually before you have set Group Policy settings, you cannot return the policy setting to the default setting by selecting the **Not Configured** option after you have configured this policy setting. To return to the default pre-boot recovery screen leave the policy setting enabled and select the **Use default message** options from the **Choose an option for the pre-boot recovery message** drop-down list box.
-
### Allow Secure Boot for integrity validation
This policy controls how BitLocker-enabled system volumes are handled in conjunction with the Secure Boot feature. Enabling this feature forces Secure Boot validation during the boot process and verifies Boot Configuration Data (BCD) settings according to the Secure Boot policy.
@@ -1986,20 +1773,14 @@ This policy controls how BitLocker-enabled system volumes are handled in conjunc
-
-
**Reference**
Secure Boot ensures that the computer's preboot environment loads only firmware that is digitally signed by authorized software publishers. Secure Boot also provides more flexibility for managing preboot configurations than BitLocker integrity checks prior to Windows Server 2012 and Windows 8.
-
When this policy is enabled and the hardware is capable of using Secure Boot for BitLocker scenarios, the **Use enhanced Boot Configuration Data validation profile** Group Policy setting is ignored, and Secure Boot verifies BCD settings according to the Secure Boot policy setting, which is configured separately from BitLocker.
-**Warning**
-Enabling this policy might result in BitLocker recovery when manufacturer-specific firmware is updated. If you disable this policy, suspend BitLocker prior to applying firmware updates.
-
+>**Warning:** Enabling this policy might result in BitLocker recovery when manufacturer-specific firmware is updated. If you disable this policy, suspend BitLocker prior to applying firmware updates.
-
### Provide the unique identifiers for your organization
This policy setting is used to establish an identifier that is applied to all drives that are encrypted in your organization.
@@ -2040,9 +1821,7 @@ This policy setting is used to establish an identifier that is applied to all dr
-
-
**Reference**
These identifiers are stored as the identification field and the allowed identification field. The identification field allows you to associate a unique organizational identifier to BitLocker-protected drives. This identifier is automatically added to new BitLocker-protected drives, and it can be updated on existing BitLocker-protected drives by using the [Manage-bde](https://technet.microsoft.com/library/ff829849.aspx) command-line tool.
@@ -2099,9 +1878,7 @@ This policy setting is used to control whether the computer's memory will be ove
-
-
**Reference**
This policy setting is applied when you turn on BitLocker. BitLocker secrets include key material that is used to encrypt data. This policy setting applies only when BitLocker protection is enabled.
@@ -2146,65 +1923,39 @@ This policy setting determines what values the TPM measures when it validates ea
-
-
**Reference**
This policy setting does not apply if the computer does not have a compatible TPM or if BitLocker has already been turned on with TPM protection.
-**Important**
-This Group Policy setting only applies to computers with BIOS configurations or to computers with UEFI firmware with the CSM enabled. Computers that use a native UEFI firmware configuration store different values in the Platform Configuration Registers (PCRs). Use the **Configure TPM platform validation profile for native UEFI firmware configurations** Group Policy setting to configure the TPM PCR profile for computers that use native UEFI firmware.
-
+>**Important:** This Group Policy setting only applies to computers with BIOS configurations or to computers with UEFI firmware with the CSM enabled. Computers that use a native UEFI firmware configuration store different values in the Platform Configuration Registers (PCRs). Use the **Configure TPM platform validation profile for native UEFI firmware configurations** Group Policy setting to configure the TPM PCR profile for computers that use native UEFI firmware.
-
A platform validation profile consists of a set of PCR indices that range from 0 to 23. The default platform validation profile secures the encryption key against changes to the following:
- Core Root of Trust of Measurement (CRTM), BIOS, and Platform Extensions (PCR 0)
-
- Option ROM Code (PCR 2)
-
- Master Boot Record (MBR) Code (PCR 4)
-
- NTFS Boot Sector (PCR 8)
-
- NTFS Boot Block (PCR 9)
-
- Boot Manager (PCR 10)
-
- BitLocker Access Control (PCR 11)
-**Note**
-Changing from the default platform validation profile affects the security and manageability of your computer. BitLocker’s sensitivity to platform modifications (malicious or authorized) is increased or decreased depending on inclusion or exclusion (respectively) of the PCRs.
-
+>**Note:** Changing from the default platform validation profile affects the security and manageability of your computer. BitLocker’s sensitivity to platform modifications (malicious or authorized) is increased or decreased depending on inclusion or exclusion (respectively) of the PCRs.
-
The following list identifies all of the PCRs available:
- PCR 0: Core root-of-trust for measurement, BIOS, and Platform extensions
-
- PCR 1: Platform and motherboard configuration and data.
-
- PCR 2: Option ROM code
-
- PCR 3: Option ROM data and configuration
-
- PCR 4: Master Boot Record (MBR) code
-
- PCR 5: Master Boot Record (MBR) partition table
-
- PCR 6: State transition and wake events
-
- PCR 7: Computer manufacturer-specific
-
- PCR 8: NTFS boot sector
-
- PCR 9: NTFS boot block
-
- PCR 10: Boot manager
-
- PCR 11: BitLocker access control
-
- PCR 12-23: Reserved for future use
### Configure TPM platform validation profile (Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2)
@@ -2247,9 +1998,7 @@ This policy setting determines what values the TPM measures when it validates ea
-
-
**Reference**
This policy setting does not apply if the computer does not have a compatible TPM or if BitLocker is already turned on with TPM protection.
@@ -2257,57 +2006,33 @@ This policy setting does not apply if the computer does not have a compatible TP
A platform validation profile consists of a set of PCR indices that range from 0 to 23. The default platform validation profile secures the encryption key against changes to the following:
- Core Root of Trust of Measurement (CRTM), BIOS, and Platform Extensions (PCR 0)
-
- Option ROM Code (PCR 2)
-
- Master Boot Record (MBR) Code (PCR 4)
-
- NTFS Boot Sector (PCR 8)
-
- NTFS Boot Block (PCR 9)
-
- Boot Manager (PCR 10)
-
- BitLocker Access Control (PCR 11)
-**Note**
-The default TPM validation profile PCR settings for computers that use an Extensible Firmware Interface (EFI) are the PCRs 0, 2, 4, and 11 only.
-
+>**Note:** The default TPM validation profile PCR settings for computers that use an Extensible Firmware Interface (EFI) are the PCRs 0, 2, 4, and 11 only.
-
The following list identifies all of the PCRs available:
- PCR 0: Core root-of-trust for measurement, EFI boot and run-time services, EFI drivers embedded in system ROM, ACPI static tables, embedded SMM code, and BIOS code
-
- PCR 1: Platform and motherboard configuration and data. Hand-off tables and EFI variables that affect system configuration
-
- PCR 2: Option ROM code
-
- PCR 3: Option ROM data and configuration
-
- PCR 4: Master Boot Record (MBR) code or code from other boot devices
-
- PCR 5: Master Boot Record (MBR) partition table. Various EFI variables and the GPT table
-
- PCR 6: State transition and wake events
-
- PCR 7: Computer manufacturer-specific
-
- PCR 8: NTFS boot sector
-
- PCR 9: NTFS boot block
-
- PCR 10: Boot manager
-
- PCR 11: BitLocker access control
-
- PCR 12 - 23: Reserved for future use
-**Warning**
-Changing from the default platform validation profile affects the security and manageability of your computer. BitLocker's sensitivity to platform modifications (malicious or authorized) is increased or decreased depending on inclusion or exclusion (respectively) of the PCRs.
-
+>**Warning:** Changing from the default platform validation profile affects the security and manageability of your computer. BitLocker's sensitivity to platform modifications (malicious or authorized) is increased or decreased depending on inclusion or exclusion (respectively) of the PCRs.
-
### Configure TPM platform validation profile for native UEFI firmware configurations
This policy setting determines what values the TPM measures when it validates early boot components before unlocking an operating system drive on a computer with native UEFI firmware configurations.
@@ -2350,61 +2075,39 @@ This policy setting determines what values the TPM measures when it validates ea
-
-
**Reference**
This policy setting does not apply if the computer does not have a compatible TPM or if BitLocker is already turned on with TPM protection.
-**Important**
-This Group Policy setting only applies to computers with a native UEFI firmware configuration. Computers with BIOS or UEFI firmware with a Compatibility Support Module (CSM) enabled store different values in the Platform Configuration Registers (PCRs). Use the **Configure TPM platform validation profile for BIOS-based firmware configurations** Group Policy setting to configure the TPM PCR profile for computers with BIOS configurations or for computers with UEFI firmware with a CSM enabled.
-
+>**Important:** This Group Policy setting only applies to computers with a native UEFI firmware configuration. Computers with BIOS or UEFI firmware with a Compatibility Support Module (CSM) enabled store different values in the Platform Configuration Registers (PCRs). Use the **Configure TPM platform validation profile for BIOS-based firmware configurations** Group Policy setting to configure the TPM PCR profile for computers with BIOS configurations or for computers with UEFI firmware with a CSM enabled.
-
A platform validation profile consists of a set of Platform Configuration Register (PCR) indices ranging from 0 to 23. The default platform validation profile secures the encryption key against changes to the core system firmware executable code (PCR 0), extended or pluggable executable code (PCR 2), boot manager (PCR 4), and the BitLocker access control (PCR 11).
The following list identifies all of the PCRs available:
- PCR 0: Core System Firmware executable code
-
- PCR 1: Core System Firmware data
-
- PCR 2: Extended or pluggable executable code
-
- PCR 3: Extended or pluggable firmware data
-
- PCR 4: Boot Manager
-
- PCR 5: GPT/Partition Table
-
- PCR 6: Resume from S4 and S5 Power State Events
-
- PCR 7: Secure Boot State
For more information about this PCR, see [Platform Configuration Register (PCR)](#bkmk-pcr) in this topic.
- PCR 8: Initialized to 0 with no Extends (reserved for future use)
-
- PCR 9: Initialized to 0 with no Extends (reserved for future use)
-
- PCR 10: Initialized to 0 with no Extends (reserved for future use)
-
- PCR 11: BitLocker access control
-
- PCR 12: Data events and highly volatile events
-
- PCR 13: Boot Module Details
-
- PCR 14: Boot Authorities
-
- PCR 15 – 23: Reserved for future use
-**Warning**
-Changing from the default platform validation profile affects the security and manageability of your computer. BitLocker's sensitivity to platform modifications (malicious or authorized) is increased or decreased depending on inclusion or exclusion (respectively) of the PCRs.
-
+>**Warning:** Changing from the default platform validation profile affects the security and manageability of your computer. BitLocker's sensitivity to platform modifications (malicious or authorized) is increased or decreased depending on inclusion or exclusion (respectively) of the PCRs.
-
### Reset platform validation data after BitLocker recovery
This policy setting determines if you want platform validation data to refresh when Windows is started following a BitLocker recovery. A platform validation data profile consists of the values in a set of Platform Configuration Register (PCR) indices that range from 0 to 23.
@@ -2449,9 +2152,7 @@ This policy setting determines if you want platform validation data to refresh w
-
-
**Reference**
For more information about the recovery process, see the [BitLocker recovery guide](bitlocker-recovery-guide-plan.md).
@@ -2500,16 +2201,11 @@ This policy setting determines specific Boot Configuration Data (BCD) settings t
-
-
**Reference**
-**Note**
-The setting that controls boot debugging (0x16000010) is always validated, and it has no effect if it is included in the inclusion or the exclusion list.
-
+>**Note:** The setting that controls boot debugging (0x16000010) is always validated, and it has no effect if it is included in the inclusion or the exclusion list.
-
### Allow access to BitLocker-protected fixed data drives from earlier versions of Windows
This policy setting is used to control whether access to drives is allowed by using the BitLocker To Go Reader, and if the application is installed on the drive.
@@ -2550,16 +2246,11 @@ This policy setting is used to control whether access to drives is allowed by us
-
-
**Reference**
-**Note**
-This policy setting does not apply to drives that are formatted with the NTFS file system.
-
+>**Note:** This policy setting does not apply to drives that are formatted with the NTFS file system.
-
When this policy setting is enabled, select the **Do not install BitLocker To Go Reader on FAT formatted fixed drives** check box to help prevent users from running BitLocker To Go Reader from their fixed drives. If BitLocker To Go Reader (bitlockertogo.exe) is present on a drive that does not have an identification field specified, or if the drive has the same identification field as specified in the **Provide unique identifiers for your organization** policy setting, the user is prompted to update BitLocker, and BitLocker To Go Reader is deleted from the drive. In this situation, for the fixed drive to be unlocked on computers running Windows Vista, Windows XP with SP3, or Windows XP with SP2, BitLocker To Go Reader must be installed on the computer. If this check box is not selected, BitLocker To Go Reader will be installed on the fixed drive to enable users to unlock the drive on computers running Windows Vista, Windows XP with SP3, or Windows XP with SP2.
### Allow access to BitLocker-protected removable data drives from earlier versions of Windows
@@ -2602,21 +2293,15 @@ This policy setting controls access to removable data drives that are using the
-
-
**Reference**
-**Note**
-This policy setting does not apply to drives that are formatted with the NTFS file system.
-
+>**Note:** This policy setting does not apply to drives that are formatted with the NTFS file system.
-
When this policy setting is enabled, select the **Do not install BitLocker To Go Reader on FAT formatted removable drives** check box to help prevent users from running BitLocker To Go Reader from their removable drives. If BitLocker To Go Reader (bitlockertogo.exe) is present on a drive that does not have an identification field specified, or if the drive has the same identification field as specified in the **Provide unique identifiers for your organization** policy setting, the user will be prompted to update BitLocker, and BitLocker To Go Reader is deleted from the drive. In this situation, for the removable drive to be unlocked on computers running Windows Vista, Windows XP with SP3, or Windows XP with SP2, BitLocker To Go Reader must be installed on the computer. If this check box is not selected, BitLocker To Go Reader will be installed on the removable drive to enable users to unlock the drive on computers running Windows Vista, Windows XP with SP3, or Windows XP with SP2 that do not have BitLocker To Go Reader installed.
## FIPS setting
-
You can configure the Federal Information Processing Standard (FIPS) setting for FIPS compliance. As an effect of FIPS compliance, users cannot create or save a BitLocker password for recovery or as a key protector. The use of a recovery key is permitted.
@@ -2655,9 +2340,7 @@ You can configure the Federal Information Processing Standard (FIPS) setting for
-
-
**Reference**
This policy needs to be enabled before any encryption key is generated for BitLocker. Note that when this policy is enabled, BitLocker prevents creating or using recovery passwords, so recovery keys should be used instead.
@@ -2670,7 +2353,6 @@ For more information about setting this policy, see [System cryptography: Use FI
## Power management Group Policy settings: Sleep and Hibernate
-
PCs default power settings for a computer will cause the computer to enter Sleep mode frequently to conserve power when idle and to help extend the system’s battery life. When a computer transitions to Sleep, open programs and documents are persisted in memory. When a computer resumes from Sleep, users are not required to re-authenticate with a PIN or USB startup key to access encrypted data. This might lead to conditions where data security is compromised.
However, when a computer hibernates the drive is locked, and when it resumes from hibernation the drive is unlocked, which means that users will need to provide a PIN or a startup key if using multifactor authentication with BitLocker. Therefore, organizations that use BitLocker may want to use Hibernate instead of Sleep for improved security. This setting does not have an impact on TPM-only mode, because it provides a transparent user experience at startup and when resuming from the Hibernate states.
@@ -2678,47 +2360,26 @@ However, when a computer hibernates the drive is locked, and when it resumes fro
You can use disable the following Group Policy settings, which are located in **Computer Configuration\\Administrative Templates\\System\\Power Management** to disable all available sleep states:
- Allow Standby States (S1-S3) When Sleeping (Plugged In)
-
- Allow Standby States (S1-S3) When Sleeping (Battery)
## About the Platform Configuration Register (PCR)
-
A platform validation profile consists of a set of PCR indices that range from 0 to 23. The scope of the values can be specific to the version of the operating system.
Changing from the default platform validation profile affects the security and manageability of your computer. BitLocker’s sensitivity to platform modifications (malicious or authorized) is increased or decreased depending on inclusion or exclusion (respectively) of the PCRs.
**About PCR 7**
-PCR 7 measures the state of Secure Boot. With PCR 7, BitLocker can leverage Secure Boot for integrity validation. Secure Boot ensures that the computer's preboot environment loads only firmware that is digitally signed by authorized software publishers. PCR 7 measurements indicate whether Secure Boot is on and which keys are trusted on the platform. If Secure Boot is on and the firmware measures PCR 7 correctly per the UEFI specification, BitLocker can bind to this information rather than to PCRs 0, 2, and 4 which have the measurements of the exact firmware and Bootmgr images loaded. This reduces the likelihood of BitLocker starting in recovery mode as a result of firmware and image updates, and it provides you with greater flexibility to manage the preboot configuration.
+PCR 7 measures the state of Secure Boot. With PCR 7, BitLocker can leverage Secure Boot for integrity validation. Secure Boot ensures that the computer's preboot environment loads only firmware that is digitally signed by authorized software publishers. PCR 7 measurements indicate whether Secure Boot is on and which keys are trusted on the platform. If Secure Boot is on and the firmware measures PCR 7 correctly per the UEFI specification, BitLocker can bind to this information rather than to PCRs 0, 2, and 4 which have the measurements of the exact firmware and Bootmgr images loaded. This
+reduces the likelihood of BitLocker starting in recovery mode as a result of firmware and image updates, and it provides you with greater flexibility to manage the preboot configuration.
PCR 7 measurements must follow the guidance that is described in [Appendix A Trusted Execution Environment EFI Protocol](http://msdn.microsoft.com/library/windows/hardware/jj923068.aspx).
PCR 7 measurements are a mandatory logo requirement for systems that support InstantGo (also known as Always On, Always Connected PCs), such as the Microsoft Surface RT. On such systems, if the TPM with PCR 7 measurement and Secure Boot are correctly configured, BitLocker binds to PCR 7 and PCR 11 by default.
## See also
-
-
-[Trusted Platform Module](trusted-platform-module-overview.md)
-
-
-[TPM Group Policy settings](trusted-platform-module-services-group-policy-settings.md)
-
-
-[BitLocker frequently asked questions (FAQ)](bitlocker-frequently-asked-questions.md)
-
-
-[BitLocker overview](bitlocker-overview.md)
-
-
-[Prepare your organization for BitLocker: Planning and policies](prepare-your-organization-for-bitlocker-planning-and-policies.md)
-
-
-
-
-
-
-
-
-
-
+- [Trusted Platform Module](trusted-platform-module-overview.md)
+- [TPM Group Policy settings](trusted-platform-module-services-group-policy-settings.md)
+- [BitLocker frequently asked questions (FAQ)](bitlocker-frequently-asked-questions.md)
+- [BitLocker overview](bitlocker-overview.md)
+- [Prepare your organization for BitLocker: Planning and policies](prepare-your-organization-for-bitlocker-planning-and-policies.md)
diff --git a/windows/keep-secure/bitlocker-how-to-deploy-on-windows-server.md b/windows/keep-secure/bitlocker-how-to-deploy-on-windows-server.md
index 0a0de22f5c..e7035aa4e8 100644
--- a/windows/keep-secure/bitlocker-how-to-deploy-on-windows-server.md
+++ b/windows/keep-secure/bitlocker-how-to-deploy-on-windows-server.md
@@ -5,14 +5,13 @@ ms.assetid: 91c18e9e-6ab4-4607-8c75-d983bbe2542f
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# BitLocker: How to deploy on Windows Server 2012 and later
-
**Applies to**
-
- Windows 10
This topic for the IT professional explains how to deploy BitLocker and Windows Server 2012 and later.
@@ -21,47 +20,32 @@ For all Windows Server editions, BitLocker must be installed using Server Manage
## Installing BitLocker
-
BitLocker requires administrator privileges on the server to install. You can install BitLocker either by using Server Manager or Windows PowerShell cmdlets.
- To install BitLocker using Server Manager
-
- To install BitLocker using Windows PowerShell
### To install BitLocker using Server Manager
1. Open Server Manager by selecting the Server Manager icon or running servermanager.exe.
-
2. Select **Manage** from the **Server Manager Navigation** bar and select **Add Roles and Features** to start the **Add Roles and Features Wizard.**
-
3. With the **Add Roles and Features Wizard** open, select **Next** at the **Before you begin** pane (if shown).
-
4. Select **Role-based or feature-based installation** on the **Installation type** pane of the **Add Roles and Features Wizard** pane and select **Next** to continue.
-
5. Select the **Select a server from the server pool option** in the **Server Selection** pane and confirm the server for the BitLocker feature install.
-
6. Server roles and features install using the same wizard in Server Manager. Select **Next** on the **Server Roles** pane of the **Add Roles and Features** wizard to proceed to the **Features** pane.
-
7. Select the check box next to **BitLocker Drive Encryption** within the **Features** pane of the **Add Roles and Features Wizard**. The wizard will show the additional management features available for BitLocker. If you do not want to install these features, deselect the **Include management tools option** and select **Add Features**. Once optional features selection is complete, select **Next** to proceed in the wizard.
- **Note**
- The **Enhanced Storage** feature is a required feature for enabling BitLocker. This feature enables support for Encrypted Hard Drives on capable systems.
-
+ > **Note:** The **Enhanced Storage** feature is a required feature for enabling BitLocker. This feature enables support for Encrypted Hard Drives on capable systems.
-
8. Select **Install** on the **Confirmation** pane of the **Add Roles and Features Wizard** to begin BitLocker feature installation. The BitLocker feature requires a restart to complete. Selecting the **Restart the destination server automatically if required** option in the **Confirmation** pane will force a restart of the computer after installation is complete.
-
9. If the **Restart the destination server automatically if required** check box is not selected, the **Results pane** of the **Add Roles and Features Wizard** will display the success or failure of the BitLocker feature installation. If required, a notification of additional action necessary to complete the feature installation, such as the restart of the computer, will be displayed in the results text.
### To install BitLocker using Windows PowerShell
Windows PowerShell offers administrators another option for BitLocker feature installation. Windows PowerShell installs features using the `servermanager` or `dism` module; however, the `servermanager` and `dism` modules do not always share feature name parity. Because of this, it is advisable to confirm the feature or role name prior to installation.
-**Note**
-You must restart the server to complete the installation of BitLocker.
-
+>**Note:** You must restart the server to complete the installation of BitLocker.
-
### Using the servermanager module to install BitLocker
The `servermanager` Windows PowerShell module can use either the `Install-WindowsFeature` or `Add-WindowsFeature` to install the BitLocker feature. The `Add-WindowsFeature` cmdlet is merely a stub to the `Install-WindowsFeature`. This example uses the `Install-WindowsFeature` cmdlet. The feature name for BitLocker in the `servermanager` module is `BitLocker`. This can be determined using the `Get-WindowsFeature` cmdlet with a query such as:
@@ -69,7 +53,6 @@ The `servermanager` Windows PowerShell module can use either the `Install-Window
``` syntax
Get-WindowsFeature Bit
```
-
The results of this command displays a table of all of the feature names beginning with “Bit” as their prefix. This allows you to confirm that the feature name is `BitLocker` for the BitLocker feature.
By default, installation of features in Windows PowerShell does not include optional sub-features or management tools as part of the install process. This can be seen using the `-WhatIf` option in Windows PowerShell.
@@ -77,7 +60,6 @@ By default, installation of features in Windows PowerShell does not include opti
``` syntax
Install-WindowsFeature BitLocker -WhatIf
```
-
The results of this command show that only the BitLocker Drive Encryption feature installs using this command.
To see what would be installed with the BitLocker feature including all available management tools and sub-features, use the following command:
@@ -89,17 +71,11 @@ Install-WindowsFeature BitLocker -IncludeAllSubFeature -IncludeManagementTools -
The result of this command displays the following list of all the administration tools for BitLocker that would be installed along with the feature, including tools for use with Active Directory Domain Services (AD DS) and Active Directory Lightweight Directory Services (AD LDS).
- BitLocker Drive Encryption
-
- BitLocker Drive Encryption Tools
-
- BitLocker Drive Encryption Administration Utilities
-
- BitLocker Recovery Password Viewer
-
- AD DS Snap-Ins and Command-Line Tools
-
- AD DS Tools
-
- AD DS and AD LDS Tools
The command to complete a full installation of the BitLocker feature with all available features and then rebooting the server at completion is:
@@ -108,11 +84,8 @@ The command to complete a full installation of the BitLocker feature with all av
Install-WindowsFeature BitLocker -IncludeAllSubFeature -IncludeManagementTools -Restart
```
-**Important**
-Installing the BitLocker feature using Windows PowerShell does not install the Enhanced Storage feature. Administrators wishing to support Encrypted Hard Drives in their environment will need to install the Enhanced Storage feature separately.
-
+>**Important:** Installing the BitLocker feature using Windows PowerShell does not install the Enhanced Storage feature. Administrators wishing to support Encrypted Hard Drives in their environment will need to install the Enhanced Storage feature separately.
-
### Using the dism module to install BitLocker
The `dism` Windows PowerShell module uses the `Enable-WindowsOptionalFeature` cmdlet to install features. The BitLocker feature name for BitLocker is `BitLocker`. The `dism` module does not support wildcards when searching for feature names. To list feature names for the `dism` module, use the `Get-WindowsOptionalFeatures` cmdlet. The following command will list all of the optional features in an online (running) operating system.
@@ -134,23 +107,9 @@ This command will prompt the user for a reboot. The Enable-WindowsOptionalFeatur
``` syntax
Enable-WindowsOptionalFeature -Online -FeatureName BitLocker, BitLocker-Utilities -All
```
-
## More information
-
-[BitLocker overview](bitlocker-overview.md)
-
-[BitLocker frequently asked questions (FAQ)](bitlocker-frequently-asked-questions.md)
-
-[Prepare your organization for BitLocker: Planning and policies](prepare-your-organization-for-bitlocker-planning-and-policies.md)
-
-[BitLocker: How to enable Network Unlock](bitlocker-how-to-enable-network-unlock.md)
-
-
-
-
-
-
-
-
-
+- [BitLocker overview](bitlocker-overview.md)
+- [BitLocker frequently asked questions (FAQ)](bitlocker-frequently-asked-questions.md)
+- [Prepare your organization for BitLocker: Planning and policies](prepare-your-organization-for-bitlocker-planning-and-policies.md)
+- [BitLocker: How to enable Network Unlock](bitlocker-how-to-enable-network-unlock.md)
diff --git a/windows/keep-secure/bitlocker-how-to-enable-network-unlock.md b/windows/keep-secure/bitlocker-how-to-enable-network-unlock.md
index 20a2231f7e..37e9e8b02d 100644
--- a/windows/keep-secure/bitlocker-how-to-enable-network-unlock.md
+++ b/windows/keep-secure/bitlocker-how-to-enable-network-unlock.md
@@ -5,20 +5,18 @@ ms.assetid: be45bc28-47db-4931-bfec-3c348151d2e9
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# BitLocker: How to enable Network Unlock
-
**Applies to**
-
- Windows 10
This topic for the IT professional describes how BitLocker Network Unlock works and how to configure it.
Network Unlock was introduced in Windows 8 and Windows Server 2012 as a BitLocker protector option for operating system volumes. Network Unlock enables easier management for BitLocker enabled desktops and servers in a domain environment by providing automatic unlock of operating system volumes at system reboot when connected to a wired corporate network. This feature requires the client hardware to have a DHCP driver implemented in its UEFI firmware.
-
Without Network Unlock, operating system volumes protected by TPM+PIN protectors require a PIN to be entered when a computer reboots or resumes from hibernation (for example, by Wake on LAN). This can make it difficult to enterprises to roll out software patches to unattended desktops and remotely administered servers.
Network Unlock allows BitLocker-enabled systems with TPM+PIN and that meet the hardware requirements to boot into Windows without user intervention. Network Unlock works in a similar fashion to the TPM+StartupKey at boot. Rather than needing to read the StartupKey from USB media, however, the key for Network Unlock is composed from a key stored in the TPM and an encrypted network key that is sent to the server, decrypted and returned to the client in a secure session.
@@ -26,49 +24,32 @@ Network Unlock allows BitLocker-enabled systems with TPM+PIN and that meet the h
This topic contains:
- [Network Unlock core requirements](#bkmk-nunlockcorereqs)
-
- [Network Unlock sequence](#bkmk-networkunlockseq)
-
- [Configure Network Unlock](#bkmk-configuringnetworkunlock)
-
- [Create the certificate template for Network Unlock](#bkmk-createcerttmpl)
-
- [Turning off Network Unlock](#bkmk-turnoffnetworkunlock)
-
- [Update Network Unlock certificates](#bkmk-updatecerts)
-
- [Troubleshoot Network Unlock](#bkmk-troubleshoot)
-
- [Configure Network Unlock on unsupported systems](#bkmk-unsupportedsystems)
## Network Unlock core requirements
-
Network Unlock must meet mandatory hardware and software requirements before the feature can automatically unlock domain joined systems. These requirements include:
- You must be running at least Windows 8 or Windows Server 2012.
-
- Any supported operating system with UEFI DHCP drivers can be Network Unlock clients.
-
- A server running the Windows Deployment Services (WDS) role on any supported server operating system.
-
- BitLocker Network Unlock optional feature installed on any supported server operating system.
-
- A DHCP server, separate from the WDS server.
-
- Properly configured public/private key pairing.
-
- Network Unlock Group Policy settings configured.
The network stack must be enabled to use the Network Unlock feature. Equipment manufacturers deliver their products in various states and with different BIOS menus, so you need to confirm that the network stack has been enabled in the BIOS before starting the computer.
-**Note**
-To properly support DHCP within UEFI, the UEFI-based system should be in native mode without a compatibility support module (CSM) enabled.
+>**Note:** To properly support DHCP within UEFI, the UEFI-based system should be in native mode without a compatibility support module (CSM) enabled.
For Network Unlock to work reliably on computers running Windows 8 and later, the first network adapter on the computer, usually the onboard adapter, must be configured to support DHCP and used for Network Unlock. This is especially worth noting when you have multiple adapters, and you wish to configure one without DHCP, such as for a lights-out management protocol. This configuration is necessary because Network Unlock will stop enumerating adapters when it reaches one with a DHCP port failure for any reason. Thus, if the first enumerated adapter does not support DHCP, is not plugged into the network, or fails to report availability of the DHCP port for any reason, then Network Unlock will fail.
-
-
The Network Unlock server component installs on supported versions of Windows Server 2012 and later as a Windows feature using Server Manager or Windows PowerShell cmdlets. The feature name is BitLocker Network Unlock in Server Manager and BitLocker-NetworkUnlock in Windows PowerShell. This feature is a core requirement.
Network Unlock requires Windows Deployment Services (WDS) in the environment where the feature will be utilized. Configuration of the WDS installation is not required; however, the WDS service needs to be running on the server.
@@ -77,7 +58,6 @@ The network key is stored on the system drive along with an AES 256 session key,
## Network Unlock sequence
-
The unlock sequence starts on the client side, when the Windows boot manager detects the existence of Network Unlock protector. It leverages the DHCP driver in UEFI to obtain an IP address for IPv4 and then broadcasts a vendor-specific DHCP request that contains the network key and a session key for the reply, all encrypted by the server's Network Unlock certificate, as described above. The Network Unlock provider on the supported WDS server recognizes the vendor-specific request, decrypts it with the RSA private key, and returns the network key encrypted with the session key via its own vendor-specific DHCP reply.
On the server side, the WDS server role has an optional plugin component, like a PXE provider, which is what handles the incoming Network Unlock requests. The provider can also be configured with subnet restrictions, which would require that the IP address provided by the client in the Network Unlock request belong to a permitted subnet in order to release the network key to the client. In instances where the Network Unlock provider is unavailable, BitLocker fails over to the next available protector to unlock the drive. In a typical configuration, this means the standard TPM+PIN unlock screen is presented to unlock the drive.
@@ -89,26 +69,17 @@ The server side configuration to enable Network Unlock also requires provisionin
**Phases in the Network Unlock process**
1. The Windows boot manager detects that a Network Unlock protector exists in the BitLocker configuration.
-
2. The client computer uses its DHCP driver in the UEFI to obtain a valid IPv4 IP address.
-
3. The client computer broadcasts a vendor-specific DHCP request that contains the Network Key (a 256-bit intermediate key) and an AES-256 session key for the reply. Both of these keys are encrypted using the 2048-bit RSA Public Key of the Network Unlock certificate from the WDS server.
-
4. The Network Unlock provider on the WDS server recognizes the vendor-specific request.
-
5. The provider decrypts it with the WDS server’s BitLocker Network Unlock certificate RSA private key.
-
6. The WDS provider then returns the network key encrypted with the session key using its own vendor-specific DHCP reply to the client computer. This forms an intermediate key.
-
7. The returned intermediate key is then combined with another local 256-bit intermediate key that can only be decrypted by the TPM.
-
8. This combined key is used to create an AES-256 key that unlocks the volume.
-
9. Windows continues the boot sequence.
## Configure Network Unlock
-
The following steps allow an administrator to configure Network Unlock in a domain where the Domain Functional Level is at least Windows Server 2012.
### Step One: Install the WDS Server role
@@ -132,7 +103,6 @@ To confirm the service is running using Windows PowerShell, use the following co
``` syntax
Get-Service WDSServer
```
-
### Step Three: Install the Network Unlock feature
To install the Network Unlock feature, use Server Manager or Windows PowerShell. To install the feature using Server Manager, select the **BitLocker Network Unlock** feature in the Server Manager console.
@@ -142,7 +112,6 @@ To install the feature using Windows PowerShell, use the following command:
``` syntax
Install-WindowsFeature BitLocker-NetworkUnlock
```
-
### Step Four: Create the Network Unlock certificate
Network Unlock can use imported certificates from an existing PKI infrastructure, or you can use a self-signed certificate.
@@ -150,48 +119,35 @@ Network Unlock can use imported certificates from an existing PKI infrastructure
To enroll a certificate from an existing certification authority (CA), do the following:
1. Open Certificate Manager on the WDS server using **certmgr.msc**
-
2. Under the Certificates - Current User item, right-click Personal
-
3. Select All Tasks, then **Request New Certificate**
-
4. Select **Next** when the Certificate Enrollment wizard opens
-
5. Select Active Directory Enrollment Policy
-
6. Choose the certificate template created for Network Unlock on the Domain controller and select **Enroll**. When prompted for more information, add the following attribute to the certificate:
- Select the **Subject Name** pane and provide a friendly name value. It is suggested that this friendly name include information for the domain or organizational unit for the certificate. For example "BitLocker Network Unlock Certificate for Contoso domain"
7. Create the certificate. Ensure the certificate appears in the Personal folder.
-
8. Export the public key certificate for Network Unlock
1. Create a .cer file by right-clicking the previously created certificate, choosing **All Tasks**, then **Export**.
-
2. Select **No, do not export the private key**.
-
3. Select **DER encoded binary X.509** and complete exporting the certificate to a file.
-
4. Give the file a name such as BitLocker-NetworkUnlock.cer.
9. Export the public key with a private key for Network Unlock
1. Create a .pfx file by right-clicking the previously created certificate, choosing **All Tasks**, then **Export**.
-
2. Select **Yes, export the private key**.
-
3. Complete the wizard to create the .pfx file.
To create a self-signed certificate, do the following:
1. Create a text file with an .inf extension. For example, notepad.exe BitLocker-NetworkUnlock.inf
-
2. Add the following contents to the previously created file:
``` syntax
[NewRequest]
-
Subject="CN=BitLocker Network Unlock certificate"
Exportable=true
RequestType=Cert
@@ -201,11 +157,9 @@ To create a self-signed certificate, do the following:
Keyspec="AT_KEYEXCHANGE"
SMIME=FALSE
HashAlgorithm=sha512
-
[Extensions]
1.3.6.1.4.1.311.21.10 = "{text}"
_continue_ = "OID=1.3.6.1.4.1.311.67.1.1"
-
2.5.29.37 = "{text}"
_continue_ = "1.3.6.1.4.1.311.67.1.1"
```
@@ -217,9 +171,7 @@ To create a self-signed certificate, do the following:
```
4. Verify the previous command properly created the certificate by confirming the .cer file exists
-
5. Launch the Certificate Manager by running **certmgr.msc**
-
6. Create a .pfx file by opening the **Certificates – Current User\\Personal\\Certificates** path in the navigation pane, right-clicking the previously imported certificate, selecting **All Tasks**, then **Export**. Follow through the wizard to create the .pfx file.
### Step Five: Deploy the private key and certificate to the WDS server
@@ -227,11 +179,8 @@ To create a self-signed certificate, do the following:
With the certificate and key created, deploy them to the infrastructure to properly unlock systems. To deploy the certificates, do the following:
1. On the WDS server, open a new MMC and add the certificates snap-in. Select the computer account and local computer when given the options.
-
2. Right-click the Certificates (Local Computer) - BitLocker Drive Encryption Network Unlock item, choose All Tasks, then **Import**
-
3. In the **File to Import** dialog, choose the .pfx file created previously.
-
4. Enter the password used to create the .pfx and complete the wizard.
### Step Six: Configure Group Policy settings for Network Unlock
@@ -241,45 +190,30 @@ With certificate and key deployed to the WDS server for Network Unlock, the fina
The following steps describe how to enable the Group Policy setting that is a requirement for configuring Network Unlock.
1. Open Group Policy Management Console (gpmc.msc)
-
2. Enable the policy **Require additional authentication at startup** and select the **Require startup PIN with TPM** option
-
3. Turn on BitLocker with TPM+PIN protectors on all domain-joined computers
The following steps describe how to deploy the required Group Policy setting:
-**Note**
-The Group Policy settings **Allow network unlock at startup** and **Add Network Unlock Certificate** were introduced in Windows Server 2012.
-
+>**Note:** The Group Policy settings **Allow network unlock at startup** and **Add Network Unlock Certificate** were introduced in Windows Server 2012.
-
1. Copy the .cer file created for Network Unlock to the domain controller
-
2. On the domain controller, launch Group Policy Management Console (gpmc.msc)
-
3. Create a new Group Policy Object or modify an existing object to enable the **Allow network unlock at startup** setting.
-
4. Deploy the public certificate to clients
1. Within Group Policy Management Console, navigate to the following location: **Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Public Key Policies\\BitLocker Drive Encryption Network Unlock Certificate**
-
2. Right-click the folder and choose **Add Network Unlock Certificate**
-
3. Follow the wizard steps and import the .cer file that was copied earlier.
-**Note**
-Only one network unlock certificate can be available at a time. If a new certificate is required, delete the current certificate before deploying a new one. The Network Unlock certificate is located in the **HKEY\_LOCAL\_MACHINE\\Software\\Policies\\Microsoft\\SystemCertificates\\FVE\_NKP** key on the client computer.
-
+>**Note:** Only one network unlock certificate can be available at a time. If a new certificate is required, delete the current certificate before deploying a new one. The Network Unlock certificate is located in the **HKEY\_LOCAL\_MACHINE\\Software\\Policies\\Microsoft\\SystemCertificates\\FVE\_NKP** key on the client computer.
-
### Step Seven: Require TPM+PIN protectors at startup
An additional step is for enterprises to use TPM+PIN protectors for an extra level of security. To require TPM+PIN protectors in an environment, do the following:
1. Open Group Policy Management Console (gpmc.msc)
-
2. Enable the policy **Require additional authentication at startup** and select the **Require startup PIN with TPM** option
-
3. Turn on BitLocker with TPM+PIN protectors on all domain-joined computers
### Create the certificate template for Network Unlock
@@ -287,41 +221,25 @@ An additional step is for enterprises to use TPM+PIN protectors for an extra lev
The following steps detail how to create a certificate template for use with BitLocker Network Unlock. A properly configured Active Directory Services Certification Authority can use this certificate to create and issue Network Unlock certificates.
1. Open the Certificates Template snap-in (certtmpl.msc).
-
2. Locate the User template. Right-click the template name and select **Duplicate Template**
-
3. On the **Compatibility** tab, change the **Certification Authority** and **Certificate recipient** fields to Windows Server 2012 and Windows 8respectively. Ensure the **Show resulting changes** dialog box is selected.
-
4. Select the **General** tab of the template. The **Template display name** and **Template name** should clearly identify that the template will be used for Network Unlock. Clear the checkbox for the **Publish certificate in Active Directory** option.
-
5. Select the **Request Handling** tab. Select **Encryption** from the **Purpose** drop down menu. Ensure the **Allow private key to be exported** option is selected.
-
6. Select the **Cryptography** tab. Set the **Minimum key size** to 2048. (Any Microsoft cryptographic provider that supports RSA can be used for this template, but for simplicity and forward compatibility we recommend using the **Microsoft Software Key Storage Provider**.)
-
7. Select the **Requests must use one of the following providers** option and clear all options except for the cryptography provider you selected, such as the **Microsoft Software Key Storage Provider**.
-
8. Select the **Subject Name** tab. Select **Supply in the request**. Select **OK** if the certificate templates pop-up dialog appears.
-
9. Select the **Issuance Requirements** tab. Select both **CA certificate manager approval** and **Valid existing certificate** options.
-
10. Select the **Extensions** tab. Select **Application Policies** and choose **Edit…**.
-
11. In the **Edit Application Policies Extension** options dialog box, select **Client Authentication**, **Encrypting File System**, **and Secure Email** and choose **Remove**.
-
12. On the **Edit Application Policies Extension** dialog box, select **Add**.
-
13. On the **Add Application Policy** dialog box, select **New**. In the **New Application Policy** dialog box enter the following information in the space provided and then click **OK** to create the BitLocker Network Unlock application policy:
- **Name:** **BitLocker Network Unlock**
-
- **Object Identifier:** **1.3.6.1.4.1.311.67.1.1**
14. Select the newly created **BitLocker Network Unlock** application policy and select **OK**
-
15. With the **Extensions** tab still open, select the **Edit Key Usage Extension** dialog, select the **Allow key exchange only with key encryption (key encipherment)** option. Select the **Make this extension critical** option.
-
16. Select the **Security** tab. Confirm that the **Domain Admins** group has been granted **Enroll** permission
-
17. Select **OK** to complete configuration of the template.
To add the Network Unlock template to the Certification Authority, open the Certification Authority snap-in (certsrv.msc). Right-click the **Certificate Templates** item and choose **New, Certificate Template to issue**. Select the previously created BitLocker Network Unlock certificate.
@@ -336,33 +254,24 @@ The configuration file, called bde-network-unlock.ini, must be located in the sa
The subnet policy configuration file must use a “\[SUBNETS\]” section to identify the specific subnets. The named subnets may then be used to specify restrictions in certificate subsections. Subnets are defined as simple name-value pairs, in the common INI format, where each subnet has its own line, with the name on the left of the equals sign, and the subnet identified on the right of the equal sign as a Classless Inter-Domain Routing (CIDR) address or range. The key word “ENABLED” is disallowed for subnet names.
-``` syntax
- [SUBNETS]
-SUBNET1=10.185.250.0/24 ; comment about this subrange could be here, after the semi-colon
-SUBNET2=10.185.252.200/28
-SUBNET3= 2001:4898:a:2::/64 ; an IPv6 subnet
-SUBNET4=2001:4898:a:3::/64; in production, the admin would likely give more useful names, like BUILDING9-EXCEPT-RECEP.
-```
+ [SUBNETS]
+ SUBNET1=10.185.250.0/24 ; comment about this subrange could be here, after the semi-colon
+ SUBNET2=10.185.252.200/28
+ SUBNET3= 2001:4898:a:2::/64 ; an IPv6 subnet
+ SUBNET4=2001:4898:a:3::/64; in production, the admin would likely give more useful names, like BUILDING9-EXCEPT-RECEP.
+ ```
+ Following the \[SUBNETS\] section, there can be sections for each Network Unlock certificate, identified by the certificate thumbprint formatted without any spaces, which define subnets clients can be unlocked from with that certificate.
-Following the \[SUBNETS\] section, there can be sections for each Network Unlock certificate, identified by the certificate thumbprint formatted without any spaces, which define subnets clients can be unlocked from with that certificate.
-
-**Note**
-When specifying the certificate thumbprint, do not include any spaces. If spaces are included in the thumbprint the subnet configuration will fail because the thumbprint will not be recognized as valid.
-
-
-
-Subnet restrictions are defined within each certificate section by denoting the allowed list of permitted subnets. If any subnet is listed in a certificate section, then only those subnets listed are permitted for that certificate. If no subnet is listed in a certificate section, then all subnets are permitted for that certificate. If a certificate does not have a section in the subnet policy configuration file, then no subnet restrictions are applied for unlocking with that certificate. This means for restrictions to apply to every certificate, there must be a certificate section for every Network Unlock certificate on the server, and an explicit allowed list set for each certificate section.
-
-Subnet lists are created by putting the name of a subnet from the \[SUBNETS\] section on its own line below the certificate section header. Then, the server will only unlock clients with this certificate on the subnet(s) specified as in the list. For troubleshooting, a subnet can be quickly excluded without deleting it from the section by simply commenting it out with a prepended semi-colon.
-
-``` syntax
- [2158a767e1c14e88e27a4c0aee111d2de2eafe60]
-;Comments could be added here to indicate when the cert was issued, which Group Policy should get it, and so on.
-;This list shows this cert is only allowed to unlock clients on SUBNET1 and SUBNET3 subnets. In this example, SUBNET2 is commented out.
-SUBNET1
-;SUBNET2
-SUBNET3
-```
+ >**Note:** When specifying the certificate thumbprint, do not include any spaces. If spaces are included in the thumbprint the subnet configuration will fail because the thumbprint will not be recognized as valid.
+
+ Subnet restrictions are defined within each certificate section by denoting the allowed list of permitted subnets. If any subnet is listed in a certificate section, then only those subnets listed are permitted for that certificate. If no subnet is listed in a certificate section, then all subnets are permitted for that certificate. If a certificate does not have a section in the subnet policy configuration file, then no subnet restrictions are applied for unlocking with that certificate. This means for restrictions to apply to every certificate, there must be a certificate section for every Network Unlock certificate on the server, and an explicit allowed list set for each certificate section.
+ Subnet lists are created by putting the name of a subnet from the \[SUBNETS\] section on its own line below the certificate section header. Then, the server will only unlock clients with this certificate on the subnet(s) specified as in the list. For troubleshooting, a subnet can be quickly excluded without deleting it from the section by simply commenting it out with a prepended semi-colon.
+ [2158a767e1c14e88e27a4c0aee111d2de2eafe60]
+ ;Comments could be added here to indicate when the cert was issued, which Group Policy should get it, and so on.
+ ;This list shows this cert is only allowed to unlock clients on SUBNET1 and SUBNET3 subnets. In this example, SUBNET2 is commented out.
+ SUBNET1
+ ;SUBNET2
+ SUBNET3
To disallow the use of a certificate altogether, its subnet list may contain the line “DISABLED".
@@ -370,41 +279,28 @@ To disallow the use of a certificate altogether, its subnet list may contain the
To turn off the unlock server, the PXE provider can be unregistered from the WDS server or uninstalled altogether. However, to stop clients from creating Network Unlock protectors the **Allow Network Unlock at startup** Group Policy setting should be disabled. When this policy setting is updated to disabled on client computers any Network Unlock key protectors on the computer will be deleted. Alternatively, the BitLocker Network Unlock certificate policy can be deleted on the domain controller to accomplish the same task for an entire domain.
-**Note**
-Removing the FVENKP certificate store that contains the Network Unlock certificate and key on the WDS server will also effectively disable the server’s ability to respond to unlock requests for that certificate. However, this is seen as an error condition and is not a supported or recommended method for turning off the Network Unlock server.
-
+>**Note:** Removing the FVENKP certificate store that contains the Network Unlock certificate and key on the WDS server will also effectively disable the server’s ability to respond to unlock requests for that certificate. However, this is seen as an error condition and is not a supported or recommended method for turning off the Network Unlock server.
-
### Update Network Unlock certificates
To update the certificates used by Network Unlock, administrators need to import or generate the new certificate for the server and then update the Network Unlock certificate Group Policy setting on the domain controller.
## Troubleshoot Network Unlock
-
Troubleshooting Network Unlock issues begins by verifying the environment. Many times, a small configuration issue will be the root cause of the failure. Items to verify include:
- Verify client hardware is UEFI-based and is on firmware version is 2.3.1 and that the UEFI firmware is in native mode without a Compatibility Support Module (CSM) for BIOS mode enabled. Do this by checking that the firmware does not have an option enabled such as "Legacy mode" or "Compatibility mode" or that the firmware does not appear to be in a BIOS-like mode.
-
- All required roles and services are installed and started
-
- Public and private certificates have been published and are in the proper certificate containers. The presence of the Network Unlock certificate can be verified in the Microsoft Management Console (MMC.exe) on the WDS server with the certificate snap-ins for the local computer enabled. The client certificate can be verified by checking the registry key **HKEY\_LOCAL\_MACHINE\\Software\\Policies\\Microsoft\\SystemCertificates\\FVE\_NKP** on the client computer.
-
- Group policy for Network Unlock is enabled and linked to the appropriate domains
-
- Verify group policy is reaching the clients properly. This can be done using the GPRESULT.exe or RSOP.msc utilities.
-
- Verify the **Network (Certificate Based)** protector is listed on the client. This can be done using either manage-bde or Windows PowerShell cmdlets. For example the following command will list the key protectors currently configured on the C: drive of the lcoal computer:
``` syntax
Manage-bde –protectors –get C:
```
-
-**Note**
-Use the output of manage-bde along with the WDS debug log to determine if the proper certificate thumbprint is being used for Network Unlock
-
+>**Note:** Use the output of manage-bde along with the WDS debug log to determine if the proper certificate thumbprint is being used for Network Unlock
-
Files to gather when troubleshooting BitLocker Network Unlock include:
1. The Windows event logs. Specifically the BitLocker event logs and the Microsoft-Windows-Deployment-Services-Diagnostics-Debug log
@@ -416,7 +312,6 @@ Files to gather when troubleshooting BitLocker Network Unlock include:
``` syntax
wevtutil sl Microsoft-Windows-Deployment-Services-Diagnostics/Debug /e:true
```
-
2. Open Event Viewer on the WDS server.
In the left pane, click **Applications and Services Logs**, click **Microsoft**, click **Windows**, click **Deployment-Services-Diagnostics**, and then click **Debug**.
@@ -424,72 +319,43 @@ Files to gather when troubleshooting BitLocker Network Unlock include:
In the right pane, click **Enable Log**.
2. The DHCP subnet configuration file (if one exists).
-
3. The output of the BitLocker status on the volume, this can be gathered into a text file using **manage-bde -status** or **Get-BitLockerVolume** in Windows PowerShell
-
4. Network Monitor capture on the server hosting the WDS role, filtered by client IP address
## Configure Network Unlock Group Policy settings on earlier versions
-
Network Unlock and the accompanying Group Policy settings were introduced in Windows Server 2012 but can be deployed using operating systems running Windows Server 2008 R2 and Windows Server 2008.
-
**Requirements**
- The server hosting WDS must be running any of the server operating systems designated in the **Applies To** list at the beginning of this topic.
-
- Client computers must be running any of the client operating systems designated in the **Applies To** list at the beginning of this topic.
The following steps can be used to configure Network Unlock on these older systems.
1. [Step One: Install the WDS Server role](#bkmk-stepone)
-
2. [Step Two: Confirm the WDS Service is running](#bkmk-steptwo)
-
3. [Step Three: Install the Network Unlock feature](#bkmk-stepthree)
-
4. [Step Four: Create the Network Unlock certificate](#bkmk-stepfour)
-
5. [Step Five: Deploy the private key and certificate to the WDS server](#bkmk-stepfive)
-
6. **Step Six: Configure registry settings for Network Unlock**
Apply the registry settings by running the following certutil script on each computer running any of the client operating systems designated in the **Applies To** list at the beginning of this topic.
-
- ``` syntax
- certutil -f -grouppolicy -addstore FVE_NKP BitLocker-NetworkUnlock.cer
-
- reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v OSManageNKP /t REG_DWORD /d 1 /f
- reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UseAdvancedStartup /t REG_DWORD /d 1 /f
- reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UsePIN /t REG_DWORD /d 2 /f
- reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UseTPMPIN /t REG_DWORD /d 2 /f
- reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UseTPM /t REG_DWORD /d 2 /f
- reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UseTPMKey /t REG_DWORD /d 2 /f
- reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UseTPMKeyPIN /t REG_DWORD /d 2 /f
- ```
+ certutil -f -grouppolicy -addstore FVE_NKP BitLocker-NetworkUnlock.cer
+ reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v OSManageNKP /t REG_DWORD /d 1 /f
+ reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UseAdvancedStartup /t REG_DWORD /d 1 /f
+ reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UsePIN /t REG_DWORD /d 2 /f
+ reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UseTPMPIN /t REG_DWORD /d 2 /f
+ reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UseTPM /t REG_DWORD /d 2 /f
+ reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UseTPMKey /t REG_DWORD /d 2 /f
+ reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UseTPMKeyPIN /t REG_DWORD /d 2 /f
7. [Create the Network Unlock certificate](#bkmk-stepfour)
-
8. [Deploy the private key and certificate to the WDS server](#bkmk-stepfive)
-
9. [Create the certificate template for Network Unlock](#bkmk-createcerttmpl)
-
10. [Require TPM+PIN protectors at startup](#bkmk-stepseven)
## See also
-
- [BitLocker overview](bitlocker-overview.md)
-
- [BitLocker frequently asked questions (FAQ)](bitlocker-frequently-asked-questions.md)
-
- [Prepare your organization for BitLocker: Planning and policies](prepare-your-organization-for-bitlocker-planning-and-policies.md)
-
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/bitlocker-overview.md b/windows/keep-secure/bitlocker-overview.md
index 80f734fc4e..897f3dd747 100644
--- a/windows/keep-secure/bitlocker-overview.md
+++ b/windows/keep-secure/bitlocker-overview.md
@@ -5,24 +5,23 @@ ms.assetid: 40526fcc-3e0d-4d75-90e0-c7d0615f33b2
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# BitLocker
-
**Applies to**
-
- Windows 10
This topic provides a high-level overview of BitLocker, including a list of system requirements, practical applications, and deprecated features.
##
-
BitLocker Drive Encryption is a data protection feature that integrates with the operating system and addresses the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned computers.
-BitLocker provides the most protection when used with a Trusted Platform Module (TPM) version 1.2 or later. The TPM is a hardware component installed in many newer computers by the computer manufacturers. It works with BitLocker to help protect user data and to ensure that a computer has not been tampered with while the system was offline.
+BitLocker provides the most protection when used with a Trusted Platform Module (TPM) version 1.2 or later. The TPM is a hardware component installed in many newer computers by the computer manufacturers. It works with BitLocker to help protect user data and to ensure that a computer has not been
+tampered with while the system was offline.
On computers that do not have a TPM version 1.2 or later, you can still use BitLocker to encrypt the Windows operating system drive. However, this implementation will require the user to insert a USB startup key to start the computer or resume from hibernation. Starting with Windows 8, you can use an operating system volume password to protect the operating system volume on a computer without TPM. Both options do not provide the pre-startup system integrity verification offered by BitLocker with a TPM.
@@ -30,27 +29,22 @@ In addition to the TPM, BitLocker offers the option to lock the normal startup p
## Practical applications
-
Data on a lost or stolen computer is vulnerable to unauthorized access, either by running a software-attack tool against it or by transferring the computer's hard disk to a different computer. BitLocker helps mitigate unauthorized data access by enhancing file and system protections. BitLocker also helps render data inaccessible when BitLocker-protected computers are decommissioned or recycled.
There are two additional tools in the Remote Server Administration Tools, which you can use to manage BitLocker.
- **BitLocker Recovery Password Viewer**. The BitLocker Recovery Password Viewer enables you to locate and view BitLocker Drive Encryption recovery passwords that have been backed up to Active Directory Domain Services (AD DS). You can use this tool to help recover data that is stored on a drive that has been encrypted by using BitLocker. The BitLocker Recovery Password Viewer tool is an extension for the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in.
-
By using this tool, you can examine a computer object's **Properties** dialog box to view the corresponding BitLocker recovery passwords. Additionally, you can right-click a domain container and then search for a BitLocker recovery password across all the domains in the Active Directory forest. To view recovery passwords, you must be a domain administrator, or you must have been delegated permissions by a domain administrator.
-- **BitLocker Drive Encryption Tools**. BitLocker Drive Encryption Tools include the command-line tools, manage-bde and repair-bde, and the BitLocker cmdlets for Windows PowerShell. Both manage-bde and the BitLocker cmdlets can be used to perform any task that can be accomplished through the BitLocker control panel, and they are appropriate to use for automated deployments and other scripting scenarios. Repair-bde is provided for disaster recovery scenarios in which a BitLocker protected drive cannot be unlocked normally or by using the recovery console.
+- **BitLocker Drive Encryption Tools**. BitLocker Drive Encryption Tools include the command-line tools, manage-bde and repair-bde, and the BitLocker cmdlets for Windows PowerShell. Both manage-bde and the BitLocker cmdlets can be used to perform any task that can be accomplished through the
+BitLocker control panel, and they are appropriate to use for automated deployments and other scripting scenarios. Repair-bde is provided for disaster recovery scenarios in which a BitLocker protected drive cannot be unlocked normally or by using the recovery console.
## New and changed functionality
-
To find out what's new in BitLocker for Windows 10, see [What's new in BitLocker?](../whats-new/bitlocker.md)
-
-
## System requirements
-
BitLocker has the following hardware requirements:
For BitLocker to use the system integrity check provided by a Trusted Platform Module (TPM), the computer must have TPM 1.2 or later. If your computer does not have a TPM, enabling BitLocker requires that you save a startup key on a removable device, such as a USB flash drive.
@@ -62,7 +56,6 @@ The system BIOS or UEFI firmware (for TPM and non-TPM computers) must support th
The hard disk must be partitioned with at least two drives:
- The operating system drive (or boot drive) contains the operating system and its support files. It must be formatted with the NTFS file system.
-
- The system drive contains the files that are needed to load Windows after the firmware has prepared the system hardware. BitLocker is not enabled on this drive. For BitLocker to work, the system drive must not be encrypted, must differ from the operating system drive, and must be formatted with the FAT32 file system on computers that use UEFI-based firmware or with the NTFS file system on computers that use BIOS firmware. We recommend that system drive be approximately 350 MB in size. After BitLocker is turned on it should have approximately 250 MB of free space.
When installed on a new computer, Windows will automatically create the partitions that are required for BitLocker.
@@ -71,77 +64,16 @@ When installing the BitLocker optional component on a server you will also need
## In this section
-
-
-
-
-
-
-
-
-
-
-
-[BitLocker frequently asked questions (FAQ)](bitlocker-frequently-asked-questions.md) |
-This topic for the IT professional answers frequently asked questions concerning the requirements to use, upgrade, deploy and administer, and key management policies for BitLocker. |
-
-
-[Prepare your organization for BitLocker: Planning and policies](prepare-your-organization-for-bitlocker-planning-and-policies.md) |
-This topic for the IT professional explains how can you plan your BitLocker deployment. |
-
-
-[BitLocker basic deployment](bitlocker-basic-deployment.md) |
-This topic for the IT professional explains how BitLocker features can be used to protect your data through drive encryption. |
-
-
-[BitLocker: How to deploy on Windows Server 2012 and later](bitlocker-how-to-deploy-on-windows-server.md) |
-This topic for the IT professional explains how to deploy BitLocker and Windows Server 2012 and later. |
-
-
-[BitLocker: How to enable Network Unlock](bitlocker-how-to-enable-network-unlock.md) |
-This topic for the IT professional describes how BitLocker Network Unlock works and how to configure it. |
-
-
-[BitLocker: Use BitLocker Drive Encryption Tools to manage BitLocker](bitlocker-use-bitlocker-drive-encryption-tools-to-manage-bitlocker.md) |
-This topic for the IT professional describes how to use tools to manage BitLocker. |
-
-
-[BitLocker: Use BitLocker Recovery Password Viewer](bitlocker-use-bitlocker-recovery-password-viewer.md) |
-This topic for the IT professional describes how to use the BitLocker Recovery Password Viewer. |
-
-
-[BitLocker Group Policy settings](bitlocker-group-policy-settings.md) |
-This topic for IT professionals describes the function, location, and effect of each Group Policy setting that is used to manage BitLocker Drive Encryption. |
-
-
-[BCD settings and BitLocker](bcd-settings-and-bitlocker.md) |
-This topic for IT professionals describes the BCD settings that are used by BitLocker. |
-
-
-[BitLocker Recovery Guide](bitlocker-recovery-guide-plan.md) |
-This topic for IT professionals describes how to recover BitLocker keys from AD DS. |
-
-
-[Protect BitLocker from pre-boot attacks](protect-bitlocker-from-pre-boot-attacks.md) |
-This detailed guide will help you understand the circumstances under which the use of pre-boot authentication is recommended for devices running Windows 10, Windows 8.1, Windows 8, or Windows 7; and when it can be safely omitted from a device’s configuration. |
-
-
-[Protecting cluster shared volumes and storage area networks with BitLocker](protecting-cluster-shared-volumes-and-storage-area-networks-with-bitlocker.md) |
-This topic for IT pros describes how to protect CSVs and SANs with BitLocker. |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+| Topic | Description |
+| - | - |
+| [BitLocker frequently asked questions (FAQ)](bitlocker-frequently-asked-questions.md) | This topic for the IT professional answers frequently asked questions concerning the requirements to use, upgrade, deploy and administer, and key management policies for BitLocker.|
+| [Prepare your organization for BitLocker: Planning and policies](prepare-your-organization-for-bitlocker-planning-and-policies.md)| This topic for the IT professional explains how can you plan your BitLocker deployment. |
+| [BitLocker basic deployment](bitlocker-basic-deployment.md) | This topic for the IT professional explains how BitLocker features can be used to protect your data through drive encryption. |
+| [BitLocker: How to deploy on Windows Server 2012 and later](bitlocker-how-to-deploy-on-windows-server.md)| This topic for the IT professional explains how to deploy BitLocker and Windows Server 2012 and later.|
+| [BitLocker: How to enable Network Unlock](bitlocker-how-to-enable-network-unlock.md) | This topic for the IT professional describes how BitLocker Network Unlock works and how to configure it. |
+| [BitLocker: Use BitLocker Drive Encryption Tools to manage BitLocker](bitlocker-use-bitlocker-drive-encryption-tools-to-manage-bitlocker.md)| This topic for the IT professional describes how to use tools to manage BitLocker.|
+| [BitLocker: Use BitLocker Recovery Password Viewer](bitlocker-use-bitlocker-recovery-password-viewer.md) | This topic for the IT professional describes how to use the BitLocker Recovery Password Viewer. |
+| [BCD settings and BitLocker](bcd-settings-and-bitlocker.md) | This topic for IT professionals describes the BCD settings that are used by BitLocker.|
+| [BitLocker Recovery Guide](bitlocker-recovery-guide-plan.md)| This topic for IT professionals describes how to recover BitLocker keys from AD DS. |
+| [Protect BitLocker from pre-boot attacks](protect-bitlocker-from-pre-boot-attacks.md)| This detailed guide will help you understand the circumstances under which the use of pre-boot authentication is recommended for devices running Windows 10, Windows 8.1, Windows 8, or Windows 7; and when it can be safely omitted from a device’s configuration. |
+| [Protecting cluster shared volumes and storage area networks with BitLocker](protecting-cluster-shared-volumes-and-storage-area-networks-with-bitlocker.md)| This topic for IT pros describes how to protect CSVs and SANs with BitLocker.|
diff --git a/windows/keep-secure/bitlocker-recovery-guide-plan.md b/windows/keep-secure/bitlocker-recovery-guide-plan.md
index 31c4fb595f..80df5a2c52 100644
--- a/windows/keep-secure/bitlocker-recovery-guide-plan.md
+++ b/windows/keep-secure/bitlocker-recovery-guide-plan.md
@@ -5,14 +5,14 @@ ms.assetid: d0f722e9-1773-40bf-8456-63ee7a95ea14
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
+
---
# BitLocker recovery guide
-
**Applies to**
-
- Windows 10
This topic for IT professionals describes how to recover BitLocker keys from AD DS.
@@ -26,26 +26,18 @@ This article does not detail how to configure AD DS to store the BitLocker reco
This article contains the following topics:
- [What Is BitLocker Recovery?](#bkmk-whatisrecovery)
-
- [Testing Recovery](#bkmk-testingrecovery)
-
- [Planning Your Recovery Process](#bkmk-planningrecovery)
-
- [Using Additional Recovery Information](#bkmk-usingaddrecovery)
-
- [Resetting Recovery Passwords](#bkmk-appendixb)
-
- [Retrieving the BitLocker Key Package](#bkmk-appendixc)
## What is BitLocker recovery?
-
BitLocker recovery is the process by which you can restore access to a BitLocker-protected drive in the event that you cannot unlock the drive normally. In a recovery scenario you have the following options to restore access to the drive:
- The user can supply the recovery password. If your organization allows users to print or store recovery passwords, the user can type in the 48-digit recovery password that they printed or stored on a USB drive or with your Microsoft Account online. (Saving a recovery password with your Microsoft Account online is only allowed when BitLocker is used on a PC that is not a member of a domain).
-
- A data recovery agent can use their credentials to unlock the drive. If the drive is an operating system drive, the drive must be mounted as a data drive on another computer for the data recovery agent to unlock it.
-
- A domain administrator can obtain the recovery password from AD DS and use it to unlock the drive. Storing recovery passwords in AD DS is recommended to provide a way for IT professionals to be able to obtain recovery passwords for drives in their organization if needed. This method requires that you have enabled this recovery method in the BitLocker Group Policy setting **Choose how BitLocker-protected operating system drives can be recovered** located at **Computer Configuration\\Administrative Templates\\Windows Components\\BitLocker Drive Encryption\\Operating System Drives** in the Local Group Policy Editor. For more information, see [BitLocker Group Policy settings](bitlocker-group-policy-settings.md).
### What causes BitLocker recovery?
@@ -53,123 +45,76 @@ BitLocker recovery is the process by which you can restore access to a BitLocker
The following list provides examples of specific events that will cause BitLocker to enter recovery mode when attempting to start the operating system drive:
- On PCs that use either BitLocker or Device Encryption when an attack is detected the device will immediately reboot and enter into BitLocker recovery mode. To take advantage of this functionality Administrators can set the **Interactive logon: Machine account lockout threshold** Group Policy setting located in **\\Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options** in the Local Group Policy Editor, or use the **MaxFailedPasswordAttempts** policy of [Exchange ActiveSync](http://technet.microsoft.com/library/aa998357.aspx) (also configurable through [Windows Intune](http://technet.microsoft.com/library/jj733621.aspx)), to limit the number of failed password attempts before the device goes into Device Lockout.
-
- Changing the boot order to boot another drive in advance of the hard drive.
-
- Having the CD or DVD drive before the hard drive in the BIOS boot order and then inserting or removing a CD or DVD.
-
- Failing to boot from a network drive before booting from the hard drive.
-
- Docking or undocking a portable computer. In some instances (depending on the computer manufacturer and the BIOS), the docking condition of the portable computer is part of the system measurement and must be consistent to validate the system status and unlock BitLocker. This means that if a portable computer is connected to its docking station when BitLocker is turned on, then it might also need to be connected to the docking station when it is unlocked. Conversely, if a portable computer is not connected to its docking station when BitLocker is turned on, then it might need to be disconnected from the docking station when it is unlocked.
-
- Changes to the NTFS partition table on the disk including creating, deleting, or resizing a primary partition.
-
- Entering the personal identification number (PIN) incorrectly too many times so that the anti-hammering logic of the TPM is activated. Anti-hammering logic is software or hardware methods that increase the difficulty and cost of a brute force attack on a PIN by not accepting PIN entries until after a certain amount of time has passed.
-
- Turning off the support for reading the USB device in the pre-boot environment from the BIOS or UEFI firmware if you are using USB-based keys instead of a TPM.
-
- Turning off, disabling, deactivating, or clearing the TPM.
-
- Upgrading critical early startup components, such as a BIOS or UEFI firmware upgrade, causing the related boot measurements to change.
-
- Forgetting the PIN when PIN authentication has been enabled.
-
- Updating option ROM firmware.
-
- Upgrading TPM firmware.
-
- Adding or removing hardware; for example, inserting a new card in the computer, including some PCMIA wireless cards.
-
- Removing, inserting, or completely depleting the charge on a smart battery on a portable computer.
-
- Changes to the master boot record on the disk.
-
- Changes to the boot manager on the disk.
-
- Hiding the TPM from the operating system. Some BIOS or UEFI settings can be used to prevent the enumeration of the TPM to the operating system. When implemented, this option can make the TPM hidden from the operating system. When the TPM is hidden, BIOS and UEFI secure startup are disabled, and the TPM does not respond to commands from any software.
-
- Using a different keyboard that does not correctly enter the PIN or whose keyboard map does not match the keyboard map assumed by the pre-boot environment. This can prevent the entry of enhanced PINs.
-
- Modifying the Platform Configuration Registers (PCRs) used by the TPM validation profile. For example, including **PCR\[1\]** would result in BitLocker measuring most changes to BIOS settings, causing BitLocker to enter recovery mode even when non-boot critical BIOS settings change.
- **Note**
- Some computers have BIOS settings that skip measurements to certain PCRs, such as **PCR\[2\]**. Changing this setting in the BIOS would cause BitLocker to enter recovery mode because the PCR measurement will be different.
-
+ >**Note:** Some computers have BIOS settings that skip measurements to certain PCRs, such as **PCR\[2\]**. Changing this setting in the BIOS would cause BitLocker to enter recovery mode because the PCR measurement will be different.
-
- Moving the BitLocker-protected drive into a new computer.
-
- Upgrading the motherboard to a new one with a new TPM.
-
- Losing the USB flash drive containing the startup key when startup key authentication has been enabled.
-
- Failing the TPM self-test.
-
- Having a BIOS, UEFI firmware, or an option ROM component that is not compliant with the relevant Trusted Computing Group standards for a client computer. For example, a non-compliant implementation may record volatile data (such as time) in the TPM measurements, causing different measurements on each startup and causing BitLocker to start in recovery mode.
-
- Changing the usage authorization for the storage root key of the TPM to a non-zero value.
- **Note**
- The BitLocker TPM initialization process sets the usage authorization value to zero, so another user or process must explicitly have changed this value.
-
+ >**Note:** The BitLocker TPM initialization process sets the usage authorization value to zero, so another user or process must explicitly have changed this value.
-
- Disabling the code integrity check or enabling test signing on Windows Boot Manager (Bootmgr).
-
- Pressing the F8 or F10 key during the boot process.
-
- Adding or removing add-in cards (such as video or network cards), or upgrading firmware on add-in cards.
-
- Using a BIOS hot key during the boot process to change the boot order to something other than the hard drive.
-**Note**
-Before you begin recovery, we recommend that you determine what caused recovery. This might help prevent the problem from occurring again in the future. For instance, if you determine that an attacker has modified your computer by obtaining physical access, you can create new security policies for tracking who has physical presence. After the recovery password has been used to recover access to the PC, BitLocker will reseal the encryption key to the current values of the measured components.
-
+>**Note:** Before you begin recovery, we recommend that you determine what caused recovery. This might help prevent the problem from occurring again in the future. For instance, if you determine that an attacker has modified your computer by obtaining physical access, you can create new security policies for tracking who has physical presence. After the recovery password has been used to recover access to the PC, BitLocker will reseal the encryption key to the current values of the measured components.
-
For planned scenarios, such as a known hardware or firmware upgrades, you can avoid initiating recovery by temporarily suspending BitLocker protection. Because suspending BitLocker leaves the drive fully encrypted, the administrator can quickly resume BitLocker protection after the planned task has been completed. Using suspend and resume also reseals the encryption key without requiring the entry of the recovery key.
-**Note**
-If suspended BitLocker will automatically resume protection when the PC is rebooted, unless a reboot count is specified using the manage-bde command line tool.
+>**Note:** If suspended BitLocker will automatically resume protection when the PC is rebooted, unless a reboot count is specified using the manage-bde command line tool.
If software maintenance requires the computer be restarted and you are using two-factor authentication, you can enable BitLocker Network Unlock to provide the secondary authentication factor when the computers do not have an on-premise user to provide the additional authentication method.
-
-
Recovery has been described within the context of unplanned or undesired behavior, but you can also cause recovery as an intended production scenario, in order to manage access control. For example, when you redeploy desktop or laptop computers to other departments or employees in your enterprise, you can force BitLocker into recovery before the computer is given to a new user.
## Testing recovery
-
Before you create a thorough BitLocker recovery process, we recommend that you test how the recovery process works for both end users (people who call your helpdesk for the recovery password) and administrators (people who help the end user get the recovery password). The –forcerecovery command of manage-bde is an easy way for you to step through the recovery process before your users encounter a recovery situation.
**To force a recovery for the local computer**
1. Click the **Start** button, type **cmd** in the **Start Search** box, right-click **cmd.exe**, and then click **Run as administrator**.
-
2. At the command prompt, type the following command and then press ENTER:
-
- **manage-bde -forcerecovery** *<Volume>*
-
+ `manage-bde -forcerecovery `
+
**To force recovery for a remote computer**
1. On the Start screen, type **cmd.exe**, and then click **Run as administrator**.
-
2. At the command prompt, type the following command and then press ENTER:
+ `manage-bde. -ComputerName -forcerecovery `
- **manage-bde. -ComputerName** *<ComputerName>***-forcerecovery** *<Volume>*
-
-**Note**
-*<ComputerName>* represents the name of the remote computer. *<Volume>* represents the volume on the remote computer that is protected with BitLocker.
-
+> **Note:** *ComputerName* represents the name of the remote computer. *Volume* represents the volume on the remote computer that is protected with BitLocker.
-
## Planning your recovery process
-
When planning the BitLocker recovery process, first consult your organization's current best practices for recovering sensitive information. For example: How does your enterprise handle lost Windows passwords? How does your organization perform smart card PIN resets? You can use these best practices and related resources (people and tools) to help formulate a BitLocker recovery model.
-Organizations that rely on BitLocker Drive Encryption and BitLocker To Go to protect data on a large number of computers and removable drives running the Windows 10, Windows 8, or Windows 7 operating systems and Windows to Go should consider using the Microsoft BitLocker Administration and Monitoring (MBAM) Tool version 2.0, which is included in the Microsoft Desktop Optimization Pack (MDOP) for Microsoft Software Assurance. MBAM makes BitLocker implementations easier to deploy and manage and allows administrators to provision and monitor encryption for operating system and fixed drives. MBAM prompts the user before encrypting fixed drives. MBAM also manages recovery keys for fixed and removable drives, making recovery easier to manage. MBAM can be used as part of a Microsoft System Center deployment or as a stand-alone solution. For more info, see [Microsoft BitLocker Administration and Monitoring](http://technet.microsoft.com/windows/hh826072.aspx).
+Organizations that rely on BitLocker Drive Encryption and BitLocker To Go to protect data on a large number of computers and removable drives running the Windows 10, Windows 8, or Windows 7 operating systems and Windows to Go should consider using the Microsoft BitLocker Administration and Monitoring (MBAM) Tool version 2.0, which is included in the Microsoft Desktop Optimization Pack (MDOP) for Microsoft Software Assurance. MBAM makes BitLocker implementations easier to deploy and manage and allows administrators to provision and monitor encryption for operating system and fixed drives. MBAM prompts the user before encrypting fixed drives. MBAM also manages recovery keys for fixed and removable drives, making recovery easier to manage. MBAM can be used as part of a Microsoft System Center deployment or as a stand-alone solution. For more info, see [Microsoft BitLocker
+Administration and Monitoring](http://technet.microsoft.com/windows/hh826072.aspx).
After a BitLocker recovery has been initiated, users can use a recovery password to unlock access to encrypted data. You must consider both self-recovery and recovery password retrieval methods for your organization.
@@ -178,7 +123,6 @@ When you determine your recovery process, you should:
- Become familiar with how you can retrieve the recovery password. See:
- [Self-recovery](#bkmk-selfrecovery)
-
- [Recovery password retrieval](#bkmk-recoveryretrieval)
- Determine a series of steps for post-recovery, including analyzing why the recovery occurred and resetting the recovery password. See:
@@ -194,30 +138,21 @@ In some cases, users might have the recovery password in a printout or a USB fla
If the user does not have a recovery password in a printout or on a USB flash drive, the user will need to be able to retrieve the recovery password from an online source. If the PC is a member of a domain the recovery password can be backed up to AD DS. However, this does not happen by default, you must have configured the appropriate Group Policy settings before BitLocker was enabled on the PC. BitLocker Group Policy settings can be found in the Local Group Policy Editor or the Group Policy Management Console (GPMC) under **Computer Configuration\\Administrative Templates\\Windows Components\\BitLocker Drive Encryption**. The following policy settings define the recovery methods that can be used to restore access to a BitLocker-protected drive if an authentication method fails or is unable to be used.
- **Choose how BitLocker-protected operating system drives can be recovered**
-
- **Choose how BitLocker-protected fixed drives can be recovered**
-
- **Choose how BitLocker-protected removable drives can be recovered**
+In each of these policies, select **Save BitLocker recovery information to Active Directory Domain Services** and then choose which BitLocker recovery information to store in Active Directory Domain Services (AD DS). Select the **Do not enable BitLocker until recovery information is stored in AD
+DS** check box if you want to prevent users from enabling BitLocker unless the computer is connected to the domain and the backup of BitLocker recovery information for the drive to AD DS succeeds.
-In each of these policies, select **Save BitLocker recovery information to Active Directory Domain Services** and then choose which BitLocker recovery information to store in Active Directory Domain Services (AD DS). Select the **Do not enable BitLocker until recovery information is stored in AD DS** check box if you want to prevent users from enabling BitLocker unless the computer is connected to the domain and the backup of BitLocker recovery information for the drive to AD DS succeeds.
-
-**Note**
-If the PCs are part of a workgroup, users should be advised to save their BitLocker recovery password with their Microsoft Account online. Having an online copy of your BitLocker recovery password is recommended to help ensure that you do not lose access to your data in the event that recovery is required.
-
+>**Note:** If the PCs are part of a workgroup, users should be advised to save their BitLocker recovery password with their Microsoft Account online. Having an online copy of your BitLocker recovery password is recommended to help ensure that you do not lose access to your data in the event that recovery is required.
-
The BitLocker Recovery Password Viewer for Active Directory Users and Computers tool allows domain administrators to view BitLocker recovery passwords for specific computer objects in Active Directory.
You can use the following list as a template for creating your own recovery process for recovery password retrieval. This sample process uses the BitLocker Recovery Password Viewer for Active Directory Users and Computers tool.
- [Record the name of the user's computer](#bkmk-recordcomputername)
-
- [Verify the user's identity](#bkmk-verifyidentity)
-
- [Locate the recovery password in AD DS](#bkmk-locatepassword)
-
- [Gather information to determine why recovery occurred](#bkmk-gatherinfo)
-
- [Give the user the recovery password](#bkmk-givepassword)
### Record the name of the user's computer
@@ -248,19 +183,16 @@ Before you give the user the recovery password, you should gather any informatio
Because the recovery password is 48 digits long the user may need to record the password by writing it down or typing it on a different computer. If you are using MBAM, the recovery password will be regenerated after it is recovered from the MBAM database to avoid the security risks associated with an uncontrolled password.
-**Note**
-Because the 48-digit recovery password is long and contains a combination of digits, the user might mishear or mistype the password. The boot-time recovery console uses built-in checksum numbers to detect input errors in each 6-digit block of the 48-digit recovery password, and offers the user the opportunity to correct such errors.
-
+>**Note:** Because the 48-digit recovery password is long and contains a combination of digits, the user might mishear or mistype the password. The boot-time recovery console uses built-in checksum numbers to detect input errors in each 6-digit block of the 48-digit recovery password, and offers the user the opportunity to correct such errors.
-
### Post-recovery analysis
-When a volume is unlocked using a recovery password, an event is written to the event log and the platform validation measurements are reset in the TPM to match the current configuration. Unlocking the volume means that the encryption key has been released and is ready for on-the-fly encryption when data is written to the volume, and on-the-fly decryption when data is read from the volume. After the volume is unlocked, BitLocker behaves the same way, regardless of how the access was granted.
+When a volume is unlocked using a recovery password, an event is written to the event log and the platform validation measurements are reset in the TPM to match the current configuration. Unlocking the volume means that the encryption key has been released and is ready for on-the-fly encryption
+when data is written to the volume, and on-the-fly decryption when data is read from the volume. After the volume is unlocked, BitLocker behaves the same way, regardless of how the access was granted.
If you notice that a computer is having repeated recovery password unlocks, you might want to have an administrator can perform post-recovery analysis to determine the root cause of the recovery and refresh BitLocker platform validation so that the user no longer needs to enter a recovery password each time that the computer starts up. See:
- [Determine the root cause of the recovery](#bkmk-determinecause)
-
- [Refresh BitLocker protection](#bkmk-refreshprotection)
### Determine the root cause of the recovery
@@ -272,15 +204,10 @@ While an administrator can remotely investigate the cause of recovery in some ca
Review and answer the following questions for your organization:
1. What BitLocker protection mode is in effect (TPM, TPM + PIN, TPM + startup key, startup key only)? Which PCR profile is in use on the PC?
-
2. Did the user merely forget the PIN or lose the startup key? If a token was lost, where might the token be?
-
3. If TPM mode was in effect, was recovery caused by a boot file change?
-
4. If recovery was caused by a boot file change, is this due to an intended user action (for example, BIOS upgrade), or to malicious software?
-
5. When was the user last able to start the computer successfully, and what might have happened to the computer since then?
-
6. Might the user have encountered malicious software or left the computer unattended since the last successful startup?
To help you answer these questions, use the BitLocker command-line tool to view the current configuration and protection mode (for example, **manage-bde -status**). Scan the event log to find events that help indicate why recovery was initiated (for example, if boot file change occurred). Both of these capabilities can be performed remotely.
@@ -291,17 +218,11 @@ After you have identified what caused recovery, you can reset BitLocker protecti
The details of this reset can vary according to the root cause of the recovery. If you cannot determine the root cause, or if malicious software or a rootkit might have infected the computer, Helpdesk should apply best-practice virus policies to react appropriately.
-**Note**
-You can perform a BitLocker validation profile reset by suspending and resuming BitLocker.
-
+>**Note:** You can perform a BitLocker validation profile reset by suspending and resuming BitLocker.
-
- [Unknown PIN](#bkmk-unknownpin)
-
- [Lost startup key](#bkmk-loststartup)
-
- [Changes to boot files](#bkmk-changebootknown)
-
### Unknown PIN
If a user has forgotten the PIN, you must reset the PIN while you are logged on to the computer in order to prevent BitLocker from initiating recovery each time the computer is restarted.
@@ -309,17 +230,10 @@ If a user has forgotten the PIN, you must reset the PIN while you are logged on
**To prevent continued recovery due to an unknown PIN**
1. Unlock the computer using the recovery password.
-
-2. Reset the PIN:
-
- 1.
-
- 2. Right-click the drive and then click **Change PIN**
-
- 3. In the BitLocker Drive Encryption dialog, click **Reset a forgotten PIN**. If you are not logged in with an administrator account you must provide administrative credentials at this time.
-
- 4. In the PIN reset dialog, provide and confirm the new PIN to use and then click **Finish**.
-
+2. Reset the PIN:
+ 1. Right-click the drive and then click **Change PIN**
+ 2. In the BitLocker Drive Encryption dialog, click **Reset a forgotten PIN**. If you are not logged in with an administrator account you must provide administrative credentials at this time.
+ 3. In the PIN reset dialog, provide and confirm the new PIN to use and then click **Finish**.
3. You will use the new PIN the next time you unlock the drive.
### Lost startup key
@@ -329,9 +243,7 @@ If you have lost the USB flash drive that contains the startup key, then you mus
**To prevent continued recovery due to a lost startup key**
1. Log on as an administrator to the computer that has the lost startup key.
-
2. Open Manage BitLocker.
-
3. Click **Duplicate start up key**, insert the clean USB drive on which you are going to write the key and then click **Save**.
### Changes to boot files
@@ -340,34 +252,27 @@ This error might occur if you updated the firmware. As a best practice you shoul
## Windows RE and BitLocker
-
Windows Recovery Environment (RE) can be used to recover access to a drive protected by BitLocker or by Device Encryption. If a PC is unable to boot after two failures, Startup Repair will automatically start. When Startup Repair is launched automatically due to boot failures, it will only execute operating system and driver file repairs, provided that the boot logs or any available crash dump point to a specific corrupted file. In Windows 8.1 and later, devices that include firmware to support specific TPM measurements for PCR\[7\] the TPM can validate that Windows RE is a trusted operating environment and will unlock any BitLocker-protected drives if Windows RE has not been modified. If the Windows RE environment has been modified, for example the TPM has been disabled, the drives will stay locked until the BitLocker recovery key is provided. If Startup Repair is not able to be run automatically from the PC and instead Windows RE is manually started from a repair disk, the BitLocker recovery key must be provided to unlock the BitLocker–protected drives.
## Using additional recovery information
-
Besides the 48-digit BitLocker recovery password, other types of recovery information are stored in Active Directory. This section describes how this additional information can be used.
### BitLocker key package
If the recovery methods discussed earlier in this document do not unlock the volume, you can use the BitLocker Repair tool to decrypt the volume at the block level. The tool uses the BitLocker key package to help recover encrypted data from severely damaged drives. You can then use this recovered data to salvage encrypted data, even after the correct recovery password has failed to unlock the damaged volume. We recommend that you still save the recovery password. A key package cannot be used without the corresponding recovery password.
-**Note**
-You must use the BitLocker Repair tool **repair-bde** to use the BitLocker key package.
-
+>**Note:** You must use the BitLocker Repair tool **repair-bde** to use the BitLocker key package.
-
The BitLocker key package is not saved by default. To save the package along with the recovery password in AD DS you must select the **Backup recovery password and key package** option in the Group Policy settings that control the recovery method. You can also export the key package from a working volume. For more details on how to export key packages, see [Retrieving the BitLocker Key Package](#bkmk-appendixc).
## Resetting recovery passwords
-
You should invalidate a recovery password after it has been provided and used. It should also be done when you intentionally want to invalidate an existing recovery password for any reason.
You can reset the recovery password in two ways:
- **Use manage-bde** You can use manage-bde to remove the old recovery password and add a new recovery password. The procedure identifies the command and the syntax for this method.
-
- **Run a script** You can run a script to reset the password without decrypting the volume. The sample script in the procedure illustrates this functionality. The sample script creates a new recovery password and invalidates all other passwords.
**To reset a recovery password using manage-bde**
@@ -382,58 +287,44 @@ You can reset the recovery password in two ways:
``` syntax
Manage-bde –protectors –add C: -RecoveryPassword
+
```
3. Get the ID of the new recovery password. From the screen copy the ID of the recovery password.
``` syntax
Manage-bde –protectors –get C: -Type RecoveryPassword
- ```
+ ```
4. Backup the new recovery password to AD DS
``` syntax
Manage-bde –protectors –adbackup C: -id {EXAMPLE6-5507-4924-AA9E-AFB2EB003692}
```
-
- **Warning**
- You must include the braces in the ID string.
-
+ >**Warning:** You must include the braces in the ID string.
-
**To run the sample recovery password script**
1. Save the following sample script in a VBScript file. For example: ResetPassword.vbs.
-
2. At the command prompt, type a command similar to the following:
**cscript ResetPassword.vbs**
-**Important**
-This sample script is configured to work only for the C volume. You must customize the script to match the volume where you want to test password reset.
-
+>**Important:** This sample script is configured to work only for the C volume. You must customize the script to match the volume where you want to test password reset.
-
-**Note**
-To manage a remote computer, you can specify the remote computer name rather than the local computer name.
-
+> **Note:** To manage a remote computer, you can specify the remote computer name rather than the local computer name.
-
You can use the following sample script to create a VBScript file to reset the recovery passwords.
``` syntax
' Target drive letter
strDriveLetter = "c:"
-
' Target computer name
' Use "." to connect to the local computer
strComputerName = "."
-
-
' --------------------------------------------------------------------------------
' Connect to the BitLocker WMI provider class
' --------------------------------------------------------------------------------
-
strConnectionStr = "winmgmts:" _
& "{impersonationLevel=impersonate,authenticationLevel=pktPrivacy}!\\" _
& strComputerName _
@@ -441,71 +332,46 @@ strConnectionStr = "winmgmts:" _
On Error Resume Next 'handle permission errors
-
Set objWMIService = GetObject(strConnectionStr)
-
-
If Err.Number <> 0 Then
WScript.Echo "Failed to connect to the BitLocker interface (Error 0x" & Hex(Err.Number) & ")."
Wscript.Echo "Ensure that you are running with administrative privileges."
WScript.Quit -1
End If
-
On Error GoTo 0
-
strQuery = "Select * from Win32_EncryptableVolume where DriveLetter='" & strDriveLetter & "'"
Set colTargetVolumes = objWMIService.ExecQuery(strQuery)
-
-
If colTargetVolumes.Count = 0 Then
WScript.Echo "FAILURE: Unable to find BitLocker-capable drive " & strDriveLetter & " on computer " & strComputerName & "."
WScript.Quit -1
End If
-
-
' there should only be one volume found
For Each objFoundVolume in colTargetVolumes
set objVolume = objFoundVolume
Next
-
-
' objVolume is now our found BitLocker-capable disk volume
-
-
' --------------------------------------------------------------------------------
' Perform BitLocker WMI provider functionality
' --------------------------------------------------------------------------------
-
-
' Add a new recovery password, keeping the ID around so it doesn't get deleted later
' ----------------------------------------------------------------------------------
-
nRC = objVolume.ProtectKeyWithNumericalPassword("Recovery Password Refreshed By Script", , sNewKeyProtectorID)
-
If nRC <> 0 Then
WScript.Echo "FAILURE: ProtectKeyWithNumericalPassword failed with return code 0x" & Hex(nRC)
WScript.Quit -1
End If
-
' Removes the other, "stale", recovery passwords
' ----------------------------------------------------------------------------------
-
nKeyProtectorTypeIn = 3 ' type associated with "Numerical Password" protector
-
nRC = objVolume.GetKeyProtectors(nKeyProtectorTypeIn, aKeyProtectorIDs)
-
If nRC <> 0 Then
WScript.Echo "FAILURE: GetKeyProtectors failed with return code 0x" & Hex(nRC)
WScript.Quit -1
End If
-
' Delete those key protectors other than the one we just added.
-
For Each sKeyProtectorID In aKeyProtectorIDs
-
If sKeyProtectorID <> sNewKeyProtectorID Then
nRC = objVolume.DeleteKeyProtector(sKeyProtectorID)
-
If nRC <> 0 Then
WScript.Echo "FAILURE: DeleteKeyProtector on ID " & sKeyProtectorID & " failed with return code 0x" & Hex(nRC)
WScript.Quit -1
@@ -514,11 +380,8 @@ Else
'WScript.Echo "SUCCESS: Key protector with ID " & sKeyProtectorID & " deleted"
End If
End If
-
Next
-
WScript.Echo "A new recovery password has been added. Old passwords have been removed."
-
' - some advanced output (hidden)
'WScript.Echo ""
'WScript.Echo "Type ""manage-bde -protectors -get " & strDriveLetter & " -type recoverypassword"" to view existing passwords."
@@ -526,11 +389,9 @@ WScript.Echo "A new recovery password has been added. Old passwords have been re
## Retrieving the BitLocker key package
-
You can use two methods to retrieve the key package, as described in [Using Additional Recovery Information](#bkmk-usingaddrecovery):
- **Export a previously-saved key package from AD DS.** You must have Read access to BitLocker recovery passwords that are stored in AD DS.
-
- **Export a new key package from an unlocked, BitLocker-protected volume.** You must have local administrator access to the working volume, before any damage has occurred.
The following sample script exports all previously-saved key packages from AD DS.
@@ -538,7 +399,6 @@ The following sample script exports all previously-saved key packages from AD D
**To run the sample key package retrieval script**
1. Save the following sample script in a VBScript file. For example: GetBitLockerKeyPackageADDS.vbs.
-
2. At the command prompt, type a command similar to the following:
**cscript GetBitLockerKeyPackageADDS.vbs -?**
@@ -549,7 +409,6 @@ You can use the following sample script to create a VBScript file to retrieve th
' --------------------------------------------------------------------------------
' Usage
' --------------------------------------------------------------------------------
-
Sub ShowUsage
Wscript.Echo "USAGE: GetBitLockerKeyPackageAD [Path To Saved Key Package] [Optional Computer Name]"
Wscript.Echo "If no computer name is specified, the local computer is assumed."
@@ -557,13 +416,10 @@ Sub ShowUsage
Wscript.Echo "Example: GetBitLockerKeyPackageAD E:\bitlocker-ad-key-package mycomputer"
WScript.Quit
End Sub
-
' --------------------------------------------------------------------------------
' Parse Arguments
' --------------------------------------------------------------------------------
-
Set args = WScript.Arguments
-
Select Case args.Count
Case 1
If args(0) = "/?" Or args(0) = "-?" Then
@@ -584,23 +440,15 @@ Select Case args.Count
End If
Case Else
ShowUsage
-
End Select
-
-
-
' --------------------------------------------------------------------------------
' Get path to Active Directory computer object associated with the computer name
' --------------------------------------------------------------------------------
-
Function GetStrPathToComputer(strComputerName)
-
' Uses the global catalog to find the computer in the forest
' Search also includes deleted computers in the tombstone
-
Set objRootLDAP = GetObject("LDAP://rootDSE")
namingContext = objRootLDAP.Get("defaultNamingContext") ' e.g. string dc=fabrikam,dc=com
-
strBase = ""
Set objConnection = CreateObject("ADODB.Connection")
@@ -608,107 +456,72 @@ Function GetStrPathToComputer(strComputerName)
objConnection.Provider = "ADsDSOOBject"
objConnection.Open "Active Directory Provider"
Set objCommand.ActiveConnection = objConnection
-
strFilter = "(&(objectCategory=Computer)(cn=" & strComputerName & "))"
strQuery = strBase & ";" & strFilter & ";distinguishedName;subtree"
-
objCommand.CommandText = strQuery
objCommand.Properties("Page Size") = 100
objCommand.Properties("Timeout") = 100
objCommand.Properties("Cache Results") = False
-
' Enumerate all objects found.
-
Set objRecordSet = objCommand.Execute
If objRecordSet.EOF Then
WScript.echo "The computer name '" & strComputerName & "' cannot be found."
WScript.Quit 1
End If
-
' Found object matching name
-
Do Until objRecordSet.EOF
dnFound = objRecordSet.Fields("distinguishedName")
GetStrPathToComputer = "LDAP://" & dnFound
objRecordSet.MoveNext
Loop
-
-
' Clean up.
Set objConnection = Nothing
Set objCommand = Nothing
Set objRecordSet = Nothing
-
End Function
-
-
' --------------------------------------------------------------------------------
' Securely access the Active Directory computer object using Kerberos
' --------------------------------------------------------------------------------
-
-
Set objDSO = GetObject("LDAP:")
strPathToComputer = GetStrPathToComputer(strComputerName)
-
WScript.Echo "Accessing object: " + strPathToComputer
-
Const ADS_SECURE_AUTHENTICATION = 1
Const ADS_USE_SEALING = 64 '0x40
Const ADS_USE_SIGNING = 128 '0x80
-
-
' --------------------------------------------------------------------------------
' Get all BitLocker recovery information from the Active Directory computer object
' --------------------------------------------------------------------------------
-
' Get all the recovery information child objects of the computer object
-
Set objFveInfos = objDSO.OpenDSObject(strPathToComputer, vbNullString, vbNullString, _
ADS_SECURE_AUTHENTICATION + ADS_USE_SEALING + ADS_USE_SIGNING)
-
objFveInfos.Filter = Array("msFVE-RecoveryInformation")
-
' Iterate through each recovery information object and saves any existing key packages
-
nCount = 1
strFilePathCurrent = strFilePath & nCount
-
For Each objFveInfo in objFveInfos
-
strName = objFveInfo.Get("name")
-
strRecoveryPassword = objFveInfo.Get("msFVE-RecoveryPassword")
strKeyPackage = objFveInfo.Get("msFVE-KeyPackage")
-
WScript.echo
WScript.echo "Recovery Object Name: " + strName
WScript.echo "Recovery Password: " + strRecoveryPassword
-
' Validate file path
Set fso = CreateObject("Scripting.FileSystemObject")
-
If (fso.FileExists(strFilePathCurrent)) Then
WScript.Echo "The file " & strFilePathCurrent & " already exists. Please use a different path."
WScript.Quit -1
End If
-
' Save binary data to the file
SaveBinaryDataText strFilePathCurrent, strKeyPackage
WScript.echo "Related key package successfully saved to " + strFilePathCurrent
-
-
' Update next file path using base name
nCount = nCount + 1
strFilePathCurrent = strFilePath & nCount
-
Next
-
-
'----------------------------------------------------------------------------------------
' Utility functions to save binary data
'----------------------------------------------------------------------------------------
-
Function SaveBinaryDataText(FileName, ByteArray)
'Create FileSystemObject object
Dim FS: Set FS = CreateObject("Scripting.FileSystemObject")
@@ -720,7 +533,6 @@ Function SaveBinaryDataText(FileName, ByteArray)
'Convert binary data To text And write them To the file
TextStream.Write BinaryToString(ByteArray)
End Function
-
Function BinaryToString(Binary)
Dim I, S
For I = 1 To LenB(Binary)
@@ -728,32 +540,22 @@ Function BinaryToString(Binary)
Next
BinaryToString = S
End Function
-
WScript.Quit
-
The following sample script exports a new key package from an unlocked, encrypted volume.
-
To run this script, start by saving the code into a VBS file (for example, GetBitLockerKeyPackage.vbs). Then, open an administrator command prompt and use “cscript” to run the saved file (for example, type "cscript GetBitLockerKeyPackage.vbs -?").
-
-
-
' --------------------------------------------------------------------------------
' Usage
' --------------------------------------------------------------------------------
-
Sub ShowUsage
Wscript.Echo "USAGE: GetBitLockerKeyPackage [VolumeLetter/DriveLetter:] [Path To Saved Key Package]"
Wscript.Echo
Wscript.Echo "Example: GetBitLockerKeyPackage C: E:\bitlocker-backup-key-package"
WScript.Quit
End Sub
-
' --------------------------------------------------------------------------------
' Parse Arguments
' --------------------------------------------------------------------------------
-
Set args = WScript.Arguments
-
Select Case args.Count
Case 2
If args(0) = "/?" Or args(0) = "-?" Then
@@ -764,28 +566,19 @@ Select Case args.Count
End If
Case Else
ShowUsage
-
End Select
-
' --------------------------------------------------------------------------------
' Other Inputs
' --------------------------------------------------------------------------------
-
' Target computer name
' Use "." to connect to the local computer
strComputerName = "."
-
' Default key protector ID to use. Specify "" to let the script choose.
-
strDefaultKeyProtectorID = ""
-
' strDefaultKeyProtectorID = "{001298E0-870E-4BA0-A2FF-FC74758D5720}" ' sample
-
-
' --------------------------------------------------------------------------------
' Connect to the BitLocker WMI provider class
' --------------------------------------------------------------------------------
-
strConnectionStr = "winmgmts:" _
& "{impersonationLevel=impersonate,authenticationLevel=pktPrivacy}!\\" _
& strComputerName _
@@ -793,93 +586,63 @@ strConnectionStr = "winmgmts:" _
On Error Resume Next 'handle permission errors
-
Set objWMIService = GetObject(strConnectionStr)
-
-
If Err.Number <> 0 Then
WScript.Echo "Failed to connect to the BitLocker interface (Error 0x" & Hex(Err.Number) & ")."
Wscript.Echo "Ensure that you are running with administrative privileges."
WScript.Quit -1
End If
-
On Error GoTo 0
-
strQuery = "Select * from Win32_EncryptableVolume where DriveLetter='" & strDriveLetter & "'"
Set colTargetVolumes = objWMIService.ExecQuery(strQuery)
-
-
If colTargetVolumes.Count = 0 Then
WScript.Echo "FAILURE: Unable to find BitLocker-capable drive " & strDriveLetter & " on computer " & strComputerName & "."
WScript.Quit -1
End If
-
-
' there should only be one volume found
For Each objFoundVolume in colTargetVolumes
set objVolume = objFoundVolume
Next
-
-
' objVolume is now our found BitLocker-capable disk volume
-
-
' --------------------------------------------------------------------------------
' Perform BitLocker WMI provider functionality
' --------------------------------------------------------------------------------
-
-
' Collect all possible valid key protector ID's that can be used to get the package
' ----------------------------------------------------------------------------------
-
nNumericalKeyProtectorType = 3 ' type associated with "Numerical Password" protector
-
nRC = objVolume.GetKeyProtectors(nNumericalKeyProtectorType, aNumericalKeyProtectorIDs)
If nRC <> 0 Then
WScript.Echo "FAILURE: GetKeyProtectors failed with return code 0x" & Hex(nRC)
WScript.Quit -1
End If
-
nExternalKeyProtectorType = 2 ' type associated with "External Key" protector
-
nRC = objVolume.GetKeyProtectors(nExternalKeyProtectorType, aExternalKeyProtectorIDs)
If nRC <> 0 Then
WScript.Echo "FAILURE: GetKeyProtectors failed with return code 0x" & Hex(nRC)
WScript.Quit -1
End If
-
-
' Get first key protector of the type "Numerical Password" or "External Key", if any
' ----------------------------------------------------------------------------------
-
if strDefaultKeyProtectorID = "" Then
-
' Save first numerical password, if exists
If UBound(aNumericalKeyProtectorIDs) <> -1 Then
strDefaultKeyProtectorID = aNumericalKeyProtectorIDs(0)
End If
-
' No numerical passwords exist, save the first external key
If strDefaultKeyProtectorID = "" and UBound(aExternalKeyProtectorIDs) <> -1 Then
strDefaultKeyProtectorID = aExternalKeyProtectorIDs(0)
End If
-
' Fail case: no recovery key protectors exist.
If strDefaultKeyProtectorID = "" Then
WScript.Echo "FAILURE: Cannot create backup key package because no recovery passwords or recovery keys exist. Check that BitLocker protection is on for this drive."
WScript.Echo "For help adding recovery passwords or recovery keys, type ""manage-bde -protectors -add -?""."
WScript.Quit -1
End If
-
End If
-
' Get some information about the chosen key protector ID
' ----------------------------------------------------------------------------------
-
' is the type valid?
-
nRC = objVolume.GetKeyProtectorType(strDefaultKeyProtectorID, nDefaultKeyProtectorType)
-
If Hex(nRC) = "80070057" Then
WScript.Echo "The key protector ID " & strDefaultKeyProtectorID & " is not valid."
WScript.Echo "This ID value may have been provided by the script writer."
@@ -887,79 +650,56 @@ ElseIf nRC <> 0 Then
WScript.Echo "FAILURE: GetKeyProtectorType failed with return code 0x" & Hex(nRC)
WScript.Quit -1
End If
-
' what's a string that can be used to describe it?
-
strDefaultKeyProtectorType = ""
-
Select Case nDefaultKeyProtectorType
-
Case nNumericalKeyProtectorType
strDefaultKeyProtectorType = "recovery password"
-
Case nExternalKeyProtectorType
strDefaultKeyProtectorType = "recovery key"
-
Case Else
WScript.Echo "The key protector ID " & strDefaultKeyProtectorID & " does not refer to a valid recovery password or recovery key."
WScript.Echo "This ID value may have been provided by the script writer."
-
End Select
-
-
' Save the backup key package using the chosen key protector ID
' ----------------------------------------------------------------------------------
-
nRC = objVolume.GetKeyPackage(strDefaultKeyProtectorID, oKeyPackage)
If nRC <> 0 Then
WScript.Echo "FAILURE: GetKeyPackage failed with return code 0x" & Hex(nRC)
WScript.Quit -1
End If
-
' Validate file path
Set fso = CreateObject("Scripting.FileSystemObject")
If (fso.FileExists(strFilePath)) Then
WScript.Echo "The file " & strFilePath & " already exists. Please use a different path."
WScript.Quit -1
End If
-
Dim oKeyPackageByte, bKeyPackage
For Each oKeyPackageByte in oKeyPackage
'WScript.echo "key package byte: " & oKeyPackageByte
bKeyPackage = bKeyPackage & ChrB(oKeyPackageByte)
Next
-
' Save binary data to the file
SaveBinaryDataText strFilePath, bKeyPackage
-
' Display helpful information
' ----------------------------------------------------------------------------------
-
WScript.Echo "The backup key package has been saved to " & strFilePath & "."
-
WScript.Echo "IMPORTANT: To use this key package, the " & strDefaultKeyProtectorType & " must also be saved."
-
' Display the recovery password or a note about saving the recovery key file
-
If nDefaultKeyProtectorType = nNumericalKeyProtectorType Then
-
nRC = objVolume.GetKeyProtectorNumericalPassword(strDefaultKeyProtectorID, sNumericalPassword)
If nRC <> 0 Then
WScript.Echo "FAILURE: GetKeyProtectorNumericalPassword failed with return code 0x" & Hex(nRC)
WScript.Quit -1
End If
WScript.Echo "Save this recovery password: " & sNumericalPassword
-
ElseIf nDefaultKeyProtectorType = nExternalKeyProtectorType Then
WScript.Echo "The saved key file is named " & strDefaultKeyProtectorID & ".BEK"
WScript.Echo "For help re-saving this external key file, type ""manage-bde -protectors -get -?"""
End If
-
-
'----------------------------------------------------------------------------------------
' Utility functions to save binary data
'----------------------------------------------------------------------------------------
-
Function SaveBinaryDataText(FileName, ByteArray)
'Create FileSystemObject object
Dim FS: Set FS = CreateObject("Scripting.FileSystemObject")
@@ -971,7 +711,6 @@ Function SaveBinaryDataText(FileName, ByteArray)
'Convert binary data To text And write them To the file
TextStream.Write BinaryToString(ByteArray)
End Function
-
Function BinaryToString(Binary)
Dim I, S
For I = 1 To LenB(Binary)
@@ -983,14 +722,6 @@ End Function
## See also
-
- [BitLocker overview](bitlocker-overview.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/bitlocker-use-bitlocker-drive-encryption-tools-to-manage-bitlocker.md b/windows/keep-secure/bitlocker-use-bitlocker-drive-encryption-tools-to-manage-bitlocker.md
index 7a8babc248..ab1c7f7bb2 100644
--- a/windows/keep-secure/bitlocker-use-bitlocker-drive-encryption-tools-to-manage-bitlocker.md
+++ b/windows/keep-secure/bitlocker-use-bitlocker-drive-encryption-tools-to-manage-bitlocker.md
@@ -2,133 +2,79 @@
title: BitLocker Use BitLocker Drive Encryption Tools to manage BitLocker (Windows 10)
description: This topic for the IT professional describes how to use tools to manage BitLocker.
ms.assetid: e869db9c-e906-437b-8c70-741dd61b5ea6
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# BitLocker: Use BitLocker Drive Encryption Tools to manage BitLocker
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional describes how to use tools to manage BitLocker.
-
BitLocker Drive Encryption Tools include the command line tools manage-bde and repair-bde and the BitLocker cmdlets for Windows PowerShell.
-
Both manage-bde and the BitLocker cmdlets can be used to perform any task that can be accomplished through the BitLocker control panel and are appropriate to use for automated deployments and other scripting scenarios.
-
Repair-bde is a special circumstance tool that is provided for disaster recovery scenarios in which a BitLocker protected drive cannot be unlocked normally or using the recovery console.
-
1. [Manage-bde](#bkmk-managebde)
-
2. [Repair-bde](#bkmk-repairbde)
-
3. [BitLocker cmdlets for Windows PowerShell](#bkmk-blcmdlets)
-
## Manage-bde
-
-
Manage-bde is a command-line tool that can be used for scripting BitLocker operations. Manage-bde offers additional options not displayed in the BitLocker control panel. For a complete list of the manage-bde options, see the [Manage-bde](https://technet.microsoft.com/library/ff829849.aspx) command-line reference.
-
Manage-bde includes less default settings and requires greater customization for configuring BitLocker. For example, using just the `manage-bde -on` command on a data volume will fully encrypt the volume without any authenticating protectors. A volume encrypted in this manner still requires user interaction to turn on BitLocker protection, even though the command successfully completed because an authentication method needs to be added to the volume for it to be fully protected. The following sections provide examples of common usage scenarios for manage-bde.
-
### Using manage-bde with operating system volumes
-
Listed below are examples of basic valid commands for operating system volumes. In general, using only the `manage-bde -on ` command will encrypt the operating system volume with a TPM-only protector and no recovery key. However, many environments require more secure protectors such as passwords or PIN and expect to be able to recover information with a recovery key. It is recommended that at least one primary protector and a recovery protector be added to an operating system volume.
-
A good practice when using manage-bde is to determine the volume status on the target system. Use the following command to determine volume status:
-
``` syntax
manage-bde -status
```
-
This command returns the volumes on the target, current encryption status and volume type (operating system or data) for each volume.
-
The following example illustrates enabling BitLocker on a computer without a TPM chip. Before beginning the encryption process you must create the startup key needed for BitLocker and save it to the USB drive. When BitLocker is enabled for the operating system volume, the BitLocker will need to access the USB flash drive to obtain the encryption key (in this example, the drive letter E represents the USB drive). You will be prompted to reboot to complete the encryption process.
-
``` syntax
manage-bde –protectors -add C: -startupkey E:
manage-bde -on C:
```
-
**Note**
After the encryption is completed, the USB startup key must be inserted before the operating system can be started.
-
-
An alternative to the startup key protector on non-TPM hardware is to use a password and an **ADaccountorgroup** protector to protect the operating system volume. In this scenario, you would add the protectors first. This is done with the command:
-
``` syntax
manage-bde -protectors -add C: -pw -sid
```
-
This command will require you to enter and then confirm the password protector before adding them to the volume. With the protectors enabled on the volume, you can then turn BitLocker on.
-
On computers with a TPM it is possible to encrypt the operating system volume without any defined protectors using manage-bde. The command to do this is:
-
``` syntax
manage-bde -on C:
```
-
This will encrypt the drive using the TPM as the default protector. If you are not sure if a TPM protector is available, to list the protectors available for a volume, run the following command:
-
``` syntax
manage-bde -protectors -get
```
-
### Using manage-bde with data volumes
-
Data volumes use the same syntax for encryption as operating system volumes but they do not require protectors for the operation to complete. Encrypting data volumes can be done using the base command: `manage-bde -on ` or you can choose to add additional protectors to the volume first. It is recommended that at least one primary protector and a recovery protector be added to a data volume.
-
A common protector for a data volume is the password protector. In the example below, we add a password protector to the volume and turn BitLocker on.
-
``` syntax
manage-bde -protectors -add -pw C:
manage-bde -on C:
```
-
## Repair-bde
-
-
You may experience a problem that damages an area of a hard disk on which BitLocker stores critical information. This kind of problem may be caused by a hard disk failure or if Windows exits unexpectedly.
-
The BitLocker Repair Tool (Repair-bde) can be used to access encrypted data on a severely damaged hard disk if the drive was encrypted by using BitLocker. Repair-bde can reconstruct critical parts of the drive and salvage recoverable data as long as a valid recovery password or recovery key is used to decrypt the data. If the BitLocker metadata data on the drive has become corrupt, you must be able to supply a backup key package in addition to the recovery password or recovery key. This key package is backed up in Active Directory Domain Services (AD DS) if you used the default setting for AD DS backup. With this key package and either the recovery password or recovery key, you can decrypt portions of a BitLocker-protected drive if the disk is corrupted. Each key package will work only for a drive that has the corresponding drive identifier. You can use the BitLocker Recovery Password Viewer to obtain this key package from AD DS.
-
**Tip**
If you are not backing up recovery information to AD DS or if you want to save key packages alternatively, you can use the command `manage-bde -KeyPackage` to generate a key package for a volume.
-
-
The Repair-bde command-line tool is intended for use when the operating system does not start or when you cannot start the BitLocker Recovery Console. You should use Repair-bde if the following conditions are true:
-
1. You have encrypted the drive by using BitLocker Drive Encryption.
-
2. Windows does not start, or you cannot start the BitLocker recovery console.
-
3. You do not have a copy of the data that is contained on the encrypted drive.
-
**Note**
Damage to the drive may not be related to BitLocker. Therefore, we recommend that you try other tools to help diagnose and resolve the problem with the drive before you use the BitLocker Repair Tool. The Windows Recovery Environment (Windows RE) provides additional options to repair computers.
-
-
The following limitations exist for Repair-bde:
-
- The Repair-bde command-line tool cannot repair a drive that failed during the encryption or decryption process.
-
- The Repair-bde command-line tool assumes that if the drive has any encryption, then the drive has been fully encrypted.
-
For more information about using repair-bde see [Repair-bde](http://technet.microsoft.com/library/ff829851.aspx)
-
## BitLocker cmdlets for Windows PowerShell
-
-
Windows PowerShell cmdlets provide a new way for administrators to use when working with BitLocker. Using Windows PowerShell's scripting capabilities, administrators can integrate BitLocker options into existing scripts with ease. The list below displays the available BitLocker cmdlets.
-
@@ -255,130 +201,76 @@ Windows PowerShell cmdlets provide a new way for administrators to use when work
-
-
Similar to manage-bde, the Windows PowerShell cmdlets allow configuration beyond the options offered in the control panel. As with manage-bde, users need to consider the specific needs of the volume they are encrypting prior to running Windows PowerShell cmdlets.
-
A good initial step is to determine the current state of the volume(s) on the computer. You can do this using the `Get-BitLockerVolume` cmdlet.
-
The `Get-BitLockerVolume` cmdlet output gives information on the volume type, protectors, protection status and other details.
-
**Tip**
Occasionally, all protectors may not be shown when using `Get-BitLockerVolume` due to lack of space in the output display. If you do not see all of the protectors for a volume, you can use the Windows PowerShell pipe command (|) to format a full listing of the protectors.
-
`Get-BitLockerVolume C: | fl`
-
-
If you want to remove the existing protectors prior to provisioning BitLocker on the volume, you could use the `Remove-BitLockerKeyProtector` cmdlet. Accomplishing this requires the GUID associated with the protector to be removed.
-
A simple script can pipe the values of each Get-BitLockerVolume return out to another variable as seen below:
-
``` syntax
$vol = Get-BitLockerVolume
$keyprotectors = $vol.KeyProtector
```
-
Using this, you can display the information in the $keyprotectors variable to determine the GUID for each protector.
-
Using this information, you can then remove the key protector for a specific volume using the command:
-
``` syntax
Remove-BitLockerKeyProtector : -KeyProtectorID "{GUID}"
```
-
**Note**
The BitLocker cmdlet requires the key protector GUID enclosed in quotation marks to execute. Ensure the entire GUID, with braces, is included in the command.
-
-
### Using the BitLocker Windows PowerShell cmdlets with operating system volumes
-
Using the BitLocker Windows PowerShell cmdlets is similar to working with the manage-bde tool for encrypting operating system volumes. Windows PowerShell offers users a lot of flexibility. For example, users can add the desired protector as part command for encrypting the volume. Below are examples of common user scenarios and steps to accomplish them in BitLocker Windows PowerShell.
-
The following example shows how to enable BitLocker on an operating system drive using only the TPM protector:
-
``` syntax
Enable-BitLocker C:
```
-
In the example below, adds one additional protector, the StartupKey protector and chooses to skip the BitLocker hardware test. In this example, encryption starts immediately without the need for a reboot.
-
``` syntax
Enable-BitLocker C: -StartupKeyProtector -StartupKeyPath -SkipHardwareTest
```
-
### Using the BitLocker Windows PowerShell cmdlets with data volumes
-
Data volume encryption using Windows PowerShell is the same as for operating system volumes. You should add the desired protectors prior to encrypting the volume. The following example adds a password protector to the E: volume using the variable $pw as the password. The $pw variable is held as a SecureString value to store the user defined password.
-
``` syntax
$pw = Read-Host -AsSecureString
Enable-BitLockerKeyProtector E: -PasswordProtector -Password $pw
```
-
### Using an AD Account or Group protector in Windows PowerShell
-
The **ADAccountOrGroup** protector, introduced in Windows 8 and Windows Server 2012, is an Active Directory SID-based protector. This protector can be added to both operating system and data volumes, although it does not unlock operating system volumes in the pre-boot environment. The protector requires the SID for the domain account or group to link with the protector. BitLocker can protect a cluster-aware disk by adding a SID-based protector for the Cluster Name Object (CNO) that lets the disk properly failover to and be unlocked by any member computer of the cluster.
-
**Warning**
The **ADAccountOrGroup** protector requires the use of an additional protector for use (such as TPM, PIN, or recovery key) when used on operating system volumes
-
-
To add an **ADAccountOrGroup** protector to a volume requires either the actual domain SID or the group name preceded by the domain and a backslash. In the example below, the CONTOSO\\Administrator account is added as a protector to the data volume G.
-
``` syntax
Enable-BitLocker G: -AdAccountOrGroupProtector -AdAccountOrGroup CONTOSO\Administrator
```
-
For users who wish to use the SID for the account or group, the first step is to determine the SID associated with the account. To get the specific SID for a user account in Windows PowerShell, use the following command:
-
**Note**
Use of this command requires the RSAT-AD-PowerShell feature.
-
-
``` syntax
get-aduser -filter {samaccountname -eq "administrator"}
```
-
**Tip**
In addition to the PowerShell command above, information about the locally logged on user and group membership can be found using: WHOAMI /ALL. This does not require the use of additional features.
-
-
The following example adds an **ADAccountOrGroup** protector to the previously encrypted operating system volume using the SID of the account:
-
``` syntax
Add-BitLockerKeyProtector C: -ADAccountOrGroupProtector -ADAccountOrGroup S-1-5-21-3651336348-8937238915-291003330-500
```
-
**Note**
Active Directory-based protectors are normally used to unlock Failover Cluster enabled volumes.
-
-
## More information
-
-
[BitLocker overview](bitlocker-overview.md)
-
[BitLocker frequently asked questions (FAQ)](bitlocker-frequently-asked-questions.md)
-
[Prepare your organization for BitLocker: Planning and policies](prepare-your-organization-for-bitlocker-planning-and-policies.md)
-
[BitLocker: How to enable Network Unlock](bitlocker-how-to-enable-network-unlock.md)
-
[BitLocker: How to deploy on Windows Server 2012](bitlocker-how-to-deploy-on-windows-server.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/bitlocker-use-bitlocker-recovery-password-viewer.md b/windows/keep-secure/bitlocker-use-bitlocker-recovery-password-viewer.md
index b3d3843cf4..de1b0e8a2c 100644
--- a/windows/keep-secure/bitlocker-use-bitlocker-recovery-password-viewer.md
+++ b/windows/keep-secure/bitlocker-use-bitlocker-recovery-password-viewer.md
@@ -2,78 +2,40 @@
title: BitLocker Use BitLocker Recovery Password Viewer (Windows 10)
description: This topic for the IT professional describes how to use the BitLocker Recovery Password Viewer.
ms.assetid: 04c93ac5-5dac-415e-b636-de81435753a2
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# BitLocker: Use BitLocker Recovery Password Viewer
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional describes how to use the BitLocker Recovery Password Viewer.
-
The BitLocker Recovery Password Viewer tool is an optional tool included with the Remote Server Administration Tools (RSAT). It lets you locate and view BitLocker recovery passwords that are stored in Active Directory Domain Services (AD DS). You can use this tool to help recover data that is stored on a drive that has been encrypted by using BitLocker. The BitLocker Active Directory Recovery Password Viewer tool is an extension for the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in. Using this tool, you can examine a computer object's **Properties** dialog box to view the corresponding BitLocker recovery passwords. Additionally, you can right-click a domain container and then search for a BitLocker recovery password across all the domains in the Active Directory forest. You can also search for a password by password identifier (ID).
-
## Before you start
-
-
To complete the procedures in this scenario:
-
- You must have domain administrator credentials.
-
- Your test computers must be joined to the domain.
-
- On the test computers, BitLocker must have been turned on after joining the domain.
-
The following procedures describe the most common tasks performed by using the BitLocker Recovery Password Viewer.
-
**To view the recovery passwords for a computer**
-
1. In **Active Directory Users and Computers**, locate and then click the container in which the computer is located.
-
2. Right-click the computer object, and then click **Properties**.
-
3. In the **Properties** dialog box, click the **BitLocker Recovery** tab to view the BitLocker recovery passwords that are associated with the computer.
-
**To copy the recovery passwords for a computer**
-
1. Follow the steps in the previous procedure to view the BitLocker recovery passwords.
-
2. On the **BitLocker Recovery** tab of the **Properties** dialog box, right-click the BitLocker recovery password that you want to copy, and then click **Copy Details**.
-
3. Press CTRL+V to paste the copied text to a destination location, such as a text file or spreadsheet.
-
**To locate a recovery password by using a password ID**
-
1. In Active Directory Users and Computers, right-click the domain container, and then click **Find BitLocker Recovery Password**.
-
2. In the **Find BitLocker Recovery Password** dialog box, type the first eight characters of the recovery password in the **Password ID (first 8 characters)** box, and then click **Search**.
-
By completing the procedures in this scenario, you have viewed and copied the recovery passwords for a computer and used a password ID to locate a recovery password.
-
## More information
-
-
[BitLocker Overview](bitlocker-overview.md)
-
[BitLocker frequently asked questions (FAQ)](bitlocker-frequently-asked-questions.md)
-
[Prepare your organization for BitLocker: Planning and policies](prepare-your-organization-for-bitlocker-planning-and-policies.md)
-
[BitLocker: How to deploy on Windows Server 2012](bitlocker-how-to-deploy-on-windows-server.md)
-
[BitLocker: Use BitLocker Drive Encryption Tools to manage BitLocker](bitlocker-use-bitlocker-drive-encryption-tools-to-manage-bitlocker.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/bypass-traverse-checking.md b/windows/keep-secure/bypass-traverse-checking.md
index b0d84bfa72..17fb337e5a 100644
--- a/windows/keep-secure/bypass-traverse-checking.md
+++ b/windows/keep-secure/bypass-traverse-checking.md
@@ -2,48 +2,29 @@
title: Bypass traverse checking (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Bypass traverse checking security policy setting.
ms.assetid: 1c828655-68d3-4140-aa0f-caa903a7087e
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Bypass traverse checking
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Bypass traverse checking** security policy setting.
-
## Reference
-
-
This policy setting determines which users (or a process that acts on behalf of the user’s account) have permission to navigate an object path in the NTFS file system or in the registry without being checked for the Traverse Folder special access permission. This user right does not allow the user to list the contents of a folder. It only allows the user to traverse folders to access permitted files or subfolders.
-
Constant: SeChangeNotifyPrivilege
-
### Possible values
-
- User-defined list of accounts
-
- Not Defined
-
### Best practices
-
1. Use access–based enumeration when you want to prevent users from seeing any folder or file to which they do not have access.
-
2. Use the default settings of this policy in most cases. If you change the settings, verify your intent through testing.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -107,59 +88,27 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Policy management
-
-
Permissions to files and folders are controlled though the appropriate configuration of file system access control lists (ACLs).The ability to traverse the folder does not provide any Read or Write permissions to the user.
-
A restart of the computer is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
### Group Policy
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
The default configuration for the **Bypass traverse checking** setting is to allow all users to bypass traverse checking. Permissions to files and folders are controlled though the appropriate configuration of file system access control lists (ACLs) because the ability to traverse the folder does not provide any Read or Write permissions to the user. The only scenario in which the default configuration could lead to a mishap would be if the administrator who configures permissions does not understand how this policy setting works. For example, the administrator might expect that users who are unable to access a folder are unable to access the contents of any child folders. Such a situation is unlikely, and, therefore, this vulnerability presents little risk.
-
### Countermeasure
-
Organizations that are extremely concerned about security may want to remove the Everyone group, and perhaps the Users group, from the list of groups that have the **Bypass traverse checking** user right. Taking explicit control over traversal assignments can be an effective way to limit access to sensitive information. Access–based enumeration can also be used. If you use access–based enumeration, users cannot see any folder or file to which they do not have access. For more info about this feature, see [Access-based Enumeration](http://go.microsoft.com/fwlink/p/?LinkId=100745).
-
### Potential impact
-
The Windows operating systems and many applications were designed with the expectation that anyone who can legitimately access the computer will have this user right. Therefore, we recommend that you thoroughly test any changes to assignments of the **Bypass traverse checking** user right before you make such changes to production systems. In particular, IIS requires this user right to be assigned to the Network Service, Local Service, IIS\_WPG, IUSR\_*<ComputerName>*, and IWAM\_*<ComputerName>* accounts. (It must also be assigned to the ASPNET account through its membership in the Users group.) We recommend that you leave this policy setting at its default configuration.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/change-history-for-keep-windows-10-secure.md b/windows/keep-secure/change-history-for-keep-windows-10-secure.md
index 5d540eb6ae..5f96e1fcb1 100644
--- a/windows/keep-secure/change-history-for-keep-windows-10-secure.md
+++ b/windows/keep-secure/change-history-for-keep-windows-10-secure.md
@@ -18,6 +18,7 @@ This topic lists new and updated topics in the [Keep Windows 10 secure](index.md
| [Microsoft Passport errors during PIN creation](microsoft-passport-errors-during-pin-creation.md) | Added errors 0x80090029 and 0x80070057, and merged entries for error 0x801c03ed. |
| [Microsoft Passport guide](microsoft-passport-guide.md) | Updated Roadmap section content |
| [User Account Control Group Policy and registry key settings](user-account-control-group-policy-and-registry-key-settings.md) | Updated for Windows 10 and Windows Server 2016 Technical Preview |
+|[Protect your enterprise data using enterprise data protection (EDP)](protect-enterprise-data-using-edp.md) |Updated info based on changes to the features and functionality.|
## April 2016
diff --git a/windows/keep-secure/change-the-system-time.md b/windows/keep-secure/change-the-system-time.md
index e654e9d952..f34f347c76 100644
--- a/windows/keep-secure/change-the-system-time.md
+++ b/windows/keep-secure/change-the-system-time.md
@@ -2,48 +2,29 @@
title: Change the system time (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Change the system time security policy setting.
ms.assetid: f2f6637d-acbc-4352-8ca3-ec563f918e65
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Change the system time
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Change the system time** security policy setting.
-
## Reference
-
-
This policy setting determines which users can adjust the time on the device's internal clock. This right allows the computer user to change the date and time associated with records in the event logs, database transactions, and the file system. This right is also required by the process that performs time synchronization. This setting does not impact the user’s ability to change the time zone or other display characteristics of the system time. For info about assigning the right to change the time zone, see [Change the time zone](change-the-time-zone.md).
-
Constant: SeSystemtimePrivilege
-
### Possible values
-
- User-defined list of accounts
-
- Not Defined
-
### Best practices
-
- Restrict the **Change the system time** user right to users with a legitimate need to change the system time.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
By default, members of the Administrators and Local Service groups have this right on workstations and servers. Members of the Administrators, Server Operators, and Local Service groups have this right on domain controllers.
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -89,81 +70,38 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Policy management
-
-
This section describes features, tools and guidance to help you manage this policy.
-
A restart of the device is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
### Group Policy
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Users who can change the time on a computer could cause several problems. For example:
-
- Time stamps on event log entries could be made inaccurate
-
- Time stamps on files and folders that are created or modified could be incorrect
-
- Computers that belong to a domain might not be able to authenticate themselves
-
- Users who try to log on to the domain from devices with inaccurate time might not be able to authenticate.
-
Also, because the Kerberos authentication protocol requires that the requester and authenticator have their clocks synchronized within an administrator-defined skew period, an attacker who changes a device's time may cause that computer to be unable to obtain or grant Kerberos protocol tickets.
-
The risk from these types of events is mitigated on most domain controllers, member servers, and end-user computers because the Windows Time Service automatically synchronizes time with domain controllers in the following ways:
-
- All desktop client devices and member servers use the authenticating domain controller as their inbound time partner.
-
- All domain controllers in a domain nominate the primary domain controller (PDC) emulator operations master as their inbound time partner.
-
- All PDC emulator operations masters follow the hierarchy of domains in the selection of their inbound time partner.
-
- The PDC emulator operations master at the root of the domain is authoritative for the organization. Therefore, we recommend that you configure this computer to synchronize with a reliable external time server.
-
This vulnerability becomes much more serious if an attacker is able to change the system time and then stop the Windows Time Service or reconfigure it to synchronize with a time server that is not accurate.
-
### Countermeasure
-
Restrict the **Change the system time** user right to users with a legitimate need to change the system time, such as members of the IT team.
-
### Potential impact
-
There should be no impact because time synchronization for most organizations should be fully automated for all computers that belong to the domain. Computers that do not belong to the domain should be configured to synchronize with an external source, such as a web service.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/change-the-time-zone.md b/windows/keep-secure/change-the-time-zone.md
index 63a5424dc7..fafb6d6293 100644
--- a/windows/keep-secure/change-the-time-zone.md
+++ b/windows/keep-secure/change-the-time-zone.md
@@ -2,46 +2,28 @@
title: Change the time zone (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Change the time zone security policy setting.
ms.assetid: 3b1afae4-68bb-472f-a43e-49e300d73e50
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Change the time zone
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Change the time zone** security policy setting.
-
## Reference
-
-
This policy setting determines which users can adjust the time zone that is used by the device for displaying the local time, which includes the device's system time plus the time zone offset.
-
Constant: SeTimeZonePrivilege
-
### Possible values
-
- User-defined list of accounts
-
- Not Defined
-
### Best practices
-
None.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
-
@@ -85,57 +67,26 @@ The following table lists the actual and effective default policy values for the
-
-
## Policy management
-
-
A restart of the device is not required for this policy setting to be effective.
-
Any change to the account for this user right assignment becomes effective the next time the account logs on.
-
### Group Policy
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Changing the time zone represents little vulnerability because the system time is not affected. This setting merely enables users to display their preferred time zone while being synchronized with domain controllers in different time zones.
-
### Countermeasure
-
Countermeasures are not required because system time is not affected by this setting.
-
### Potential impact
-
None.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/change-the-tpm-owner-password.md b/windows/keep-secure/change-the-tpm-owner-password.md
index dbbd1ff048..e76c48aac1 100644
--- a/windows/keep-secure/change-the-tpm-owner-password.md
+++ b/windows/keep-secure/change-the-tpm-owner-password.md
@@ -2,96 +2,49 @@
title: Change the TPM owner password (Windows 10)
description: This topic for the IT professional describes how to change the password or PIN for the owner of the Trusted Platform Module (TPM) that is installed on your system.
ms.assetid: e43dcff3-acb4-4a92-8816-d6b64b7f2f45
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Change the TPM owner password
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional describes how to change the password or PIN for the owner of the Trusted Platform Module (TPM) that is installed on your system.
-
## About the TPM owner password
-
-
The owner of the TPM is the user who possesses the owner password and is able to set it and change it. Only one owner password exists per TPM. The owner of the TPM can make full use of TPM capabilities. When an owner is set, no other user or software can claim ownership of the TPM. Only the TPM owner can enable, disable, or clear the TPM without having physical access to the computer, for example, by using the command-line tools remotely. Taking ownership of the TPM can be performed as part of the initialization process. Ownership can change when you share the password or clear your ownership of the TPM so someone else can initialize it.
-
Applications, including BitLocker Drive Encryption, can automatically start the initialization process. If you enable BitLocker without manually initializing the TPM, the TPM owner password is automatically created and saved in the same location as the BitLocker recovery password.
-
The TPM owner password can be saved as a file on a removable storage device, or on another computer. The password can also be printed. The TPM MMC gives the TPM owner the sole ability to choose the appropriate option to type the password or to use the saved password.
-
As with any password, you should change your TPM owner password if you suspect that it has become compromised and is no longer a secret.
-
**Other TPM management options**
-
Instead of changing your owner password, you can also use the following options to manage your TPM:
-
- **Clear the TPM** If you want to invalidate all of the existing keys that have been created since you took ownership of the TPM, you can clear it. For more info, see [Initialize and Configure Ownership of the TPM](initialize-and-configure-ownership-of-the-tpm.md#bkmk-clear1).
-
**Important**
Clearing the TPM can result in the loss of data. To avoid data loss, make sure you have a backup or recovery method for any data protected or encrypted by the TPM.
-
-
- **Turn off the TPM** If you want to keep all existing keys and data intact, and you want to disable the services that are provided by the TPM, you can turn it off. For more info, see [Initialize and Configure Ownership of the TPM](initialize-and-configure-ownership-of-the-tpm.md#bkmk-onoff).
-
## Change the TPM owner password
-
-
The following procedure provides the steps that are necessary to change the TPM owner password.
-
**To change the TPM owner password**
-
1. Open the TPM MMC (tpm.msc). If the **User Account Control** dialog box appears, confirm that the action it displays is what you want, and then click **Yes**.
-
2. In the **Actions** pane, click **Change Owner Password**.
-
3. In the **Manage the TPM security hardware** dialog box, select a method to enter your current TPM owner password.
-
- If you saved your TPM owner password on a removable storage device, insert it, and then click **I have the owner password file**. In the **Select backup file with the TPM owner password** dialog box, use **Browse** to navigate to the .tpm file that is saved on your removable storage device. Click **Open**, and then click **Create New Password**.
-
- If you do not have the removable storage device with your saved password, click **I want to enter the owner password**. In the **Type your TPM owner password** dialog box, enter your password (including hyphens), and click **Create New Password**.
-
4. On the **Create the TPM owner password** page, select a method for creating a new TPM owner password.
-
1. Click **Automatically create the password** to have a new owner password generated for you.
-
2. Click **Manually create the password** if you want to specify a password.
-
**Note**
The TPM owner password must have a minimum of eight characters.
-
-
5. After the new password is created, you can choose **Save the password** to save the password in a password backup file on a removable storage device or **Print the password** to print a copy of the password for later reference.
-
6. Click **Change password** to apply the new owner password to the TPM.
-
## Use the TPM cmdlets
-
-
If you are using Windows PowerShell to manage your computers, you can also manage the TPM by using Windows PowerShell. To install the TPM cmdlets, type the following command:
-
**dism /online /enable-feature /FeatureName:tpm-psh-cmdlets**
-
For details about the individual cmdlets, see [TPM Cmdlets in Windows PowerShell](http://technet.microsoft.com/library/jj603116.aspx).
-
## Additional resources
-
-
For more info about TPM, see [Trusted Platform Module technology overview](trusted-platform-module-overview.md#bkmk-additionalresources).
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/choose-the-right-bitlocker-countermeasure.md b/windows/keep-secure/choose-the-right-bitlocker-countermeasure.md
index c59d12e4db..374b255db6 100644
--- a/windows/keep-secure/choose-the-right-bitlocker-countermeasure.md
+++ b/windows/keep-secure/choose-the-right-bitlocker-countermeasure.md
@@ -2,61 +2,32 @@
title: Choose the right BitLocker countermeasure (Windows 10)
description: This section outlines the best countermeasures you can use to protect your organization from bootkits and rootkits, brute force sign-in, Direct Memory Access (DMA) attacks, Hyberfil.sys attacks, and memory remanence attacks.
ms.assetid: b0b09508-7885-4030-8c61-d91458afdb14
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Choose the right BitLocker countermeasure
-
-
**Applies to**
-
- Windows 10
-
This section outlines the best countermeasures you can use to protect your organization from bootkits and rootkits, brute force sign-in, Direct Memory Access (DMA) attacks, Hyberfil.sys attacks, and memory remanence attacks.
-
You can use BitLocker to protect your Windows 10 PCs. Whichever operating system you’re using, Microsoft and Windows-certified devices provide countermeasures to address attacks and improve your data security. In most cases, this protection can be implemented without the need for pre-boot authentication.
-
Figures 2, 3, and 4 summarize the recommended mitigations for different types of attacks against PCs running recent versions of Windows. The orange blocks indicate that the system requires additional configuration from the default settings.
-
-
**Figure 2.** How to choose the best countermeasures for Windows 7
-
-
**Figure 3.** How to choose the best countermeasures for Windows 8
-
-
**Figure 4.** How to choose the best countermeasures for Windows 8.1
-
The latest InstantGo devices, primarily tablets, are designed to be secure by default against all attacks that might compromise the BitLocker encryption key. Other Windows devices can be, too. DMA port–based attacks, which represent the attack vector of choice, are not possible on InstantGo devices, because these port types are prohibited. The inclusion of DMA ports on even non-InstantGo devices is extremely rare on recent devices, particularly on mobile ones. This could change if Thunderbolt is broadly adopted, so IT should consider this when purchasing new devices. In any case DMA ports can be disabled entirely, which is an increasingly popular option because the use of DMA ports is infrequent in the non-developer space.
-
Memory remanence attacks can be mitigated with proper configuration; in cases where the system memory is fixed and non-removable, they are not possible using published techniques. Even in cases where system memory can be removed and loaded into another device, attackers will find the attack vector extremely unreliable, as has been shown in the DRDC Valcartier group’s analysis (see [An In-depth Analysis of the Cold Boot Attack](http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA545078)).
-
Windows 7 PCs share the same security risks as newer devices but are far more vulnerable to DMA and memory remanence attacks, because Windows 7 devices are more likely to include DMA ports, lack support for UEFI-based Secure Boot, and rarely have fixed memory. To eliminate the need for pre-boot authentication on Windows 7 devices, disable the ability to boot to external media, password-protect the BIOS configuration, and disable the DMA ports. If you believe that your devices may be a target of a memory remanence attack, where the system memory may be removed and put into another computer to gain access to its contents, consider testing your devices to determine whether they are susceptible to this type of attack.
-
In the end, many customers will find that pre-boot authentication improves security only for a shrinking subset of devices within their organization. Microsoft recommends a careful examination of the attack vectors and mitigations outlined in this document along with an evaluation of your devices before choosing to implement pre-boot authentication, which may not enhance the security of your devices and instead will only compromise the user experience and add to support costs.
-
## See also
-
-
- [Types of attacks for volume encryption keys](types-of-attacks-for-volume-encryption-keys.md)
-
- [BitLocker Countermeasures](bitlocker-countermeasures.md)
-
- [Protect BitLocker from pre-boot attacks](protect-bitlocker-from-pre-boot-attacks.md)
-
- [BitLocker overview](bitlocker-overview.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/configure-an-applocker-policy-for-audit-only.md b/windows/keep-secure/configure-an-applocker-policy-for-audit-only.md
index f554bbf9cb..5de6e0fbde 100644
--- a/windows/keep-secure/configure-an-applocker-policy-for-audit-only.md
+++ b/windows/keep-secure/configure-an-applocker-policy-for-audit-only.md
@@ -2,47 +2,26 @@
title: Configure an AppLocker policy for audit only (Windows 10)
description: This topic for IT professionals describes how to set AppLocker policies to Audit only within your IT environment by using AppLocker.
ms.assetid: 10bc87d5-cc7f-4500-b7b3-9006e50afa50
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Configure an AppLocker policy for audit only
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals describes how to set AppLocker policies to **Audit only** within your IT environment by using AppLocker.
-
After AppLocker rules are created within the rule collection, you can configure the enforcement setting to **Enforce rules** or **Audit only**.
-
When AppLocker policy enforcement is set to **Enforce rules**, rules are enforced for the rule collection and all events are audited. When AppLocker policy enforcement is set to **Audit only**, rules are only evaluated but all events generated from that evaluation are written to the AppLocker log.
-
**Note**
There is no audit mode for the DLL rule collection. DLL rules affect specific apps. Therefore, test the impact of these rules first before deploying them to production. To enable the DLL rule collection, see [Enable the DLL rule collection](enable-the-dll-rule-collection.md).
-
-
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group Policy Object (GPO) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or in a security template. For info how to use these MMC snap-ins to administer AppLocker, see [Administer AppLocker](administer-applocker.md#bkmk-using-snapins).
-
**To audit rule collections**
-
1. From the AppLocker console, right-click **AppLocker**, and then click **Properties**.
-
2. On the **Enforcement** tab, select the **Configured** check box for the rule collection that you want to enforce, and then verify that **Audit only** is selected in the list for that rule collection.
-
3. Repeat the above step to configure the enforcement setting to **Audit only** for additional rule collections.
-
4. Click **OK**.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/configure-an-applocker-policy-for-enforce-rules.md b/windows/keep-secure/configure-an-applocker-policy-for-enforce-rules.md
index acea4f15df..cd7c80e04b 100644
--- a/windows/keep-secure/configure-an-applocker-policy-for-enforce-rules.md
+++ b/windows/keep-secure/configure-an-applocker-policy-for-enforce-rules.md
@@ -2,45 +2,25 @@
title: Configure an AppLocker policy for enforce rules (Windows 10)
description: This topic for IT professionals describes the steps to enable the AppLocker policy enforcement setting.
ms.assetid: 5dbbb290-a5ae-4f88-82b3-21e95972e66c
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Configure an AppLocker policy for enforce rules
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals describes the steps to enable the AppLocker policy enforcement setting.
-
**Note**
When AppLocker policy enforcement is set to **Enforce rules**, rules are enforced for the rule collection and all events are audited.
-
-
For info about how AppLocker policies are applied within a GPO structure, see [Understand AppLocker rules and enforcement setting inheritance in Group Policy](understand-applocker-rules-and-enforcement-setting-inheritance-in-group-policy.md).
-
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group Policy Object (GPO) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or in a security template. For info how to use these MMC snap-ins to administer AppLocker, see [Administer AppLocker](administer-applocker.md#bkmk-using-snapins).
-
**To enable the Enforce rules enforcement setting**
-
1. From the AppLocker console, right-click **AppLocker**, and then click **Properties**.
-
2. On the **Enforcement** tab of the **AppLocker Properties** dialog box, select the **Configured** check box for the rule collection that you are editing, and then verify that **Enforce rules** is selected.
-
3. Click **OK**.
-
For info about viewing the events generated from rules enforcement, see [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md).
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/configure-exceptions-for-an-applocker-rule.md b/windows/keep-secure/configure-exceptions-for-an-applocker-rule.md
index 126647dac7..34f5707623 100644
--- a/windows/keep-secure/configure-exceptions-for-an-applocker-rule.md
+++ b/windows/keep-secure/configure-exceptions-for-an-applocker-rule.md
@@ -2,48 +2,26 @@
title: Add exceptions for an AppLocker rule (Windows 10)
description: This topic for IT professionals describes the steps to specify which apps can or cannot run as exceptions to an AppLocker rule.
ms.assetid: d15c9d84-c14b-488d-9f48-bf31ff7ff0c5
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Add exceptions for an AppLocker rule
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals describes the steps to specify which apps can or cannot run as exceptions to an AppLocker rule.
-
Rule exceptions allow you to specify files or folders to exclude from the rule. For more information about exceptions, see [Understanding AppLocker rule exceptions](understanding-applocker-rule-exceptions.md).
-
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group Policy Object (GPO) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or in a security template. For info how to use these MMC snap-ins to administer AppLocker, see [Administer AppLocker](administer-applocker.md#bkmk-using-snapins).
-
**To configure exceptions for a rule**
-
1. Open the AppLocker console.
-
2. Expand the rule collection, right-click the rule that you want to configure exceptions for, and then click **Properties**.
-
3. Click the **Exceptions** tab.
-
4. In the **Add exception** box, select the rule type that you want to create, and then click **Add**.
-
- For a publisher exception, click **Browse**, select the file that contains the publisher to exclude, and then click **OK**.
-
- For a path exception, choose the file or folder path to exclude, and then click **OK**.
-
- For a file hash exception, edit the file hash rule, and click **Remove**.
-
- For a packaged apps exception, click **Add** to create the exceptions based on reference app and rule scope.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/configure-s-mime.md b/windows/keep-secure/configure-s-mime.md
index 205f3823db..0f76c34cac 100644
--- a/windows/keep-secure/configure-s-mime.md
+++ b/windows/keep-secure/configure-s-mime.md
@@ -2,103 +2,55 @@
title: Configure S/MIME for Windows 10 and Windows 10 Mobile (Windows 10)
description: In Windows 10, S/MIME lets users encrypt outgoing messages and attachments so that only intended recipients who have a digital identification (ID), also known as a certificate, can read them.
ms.assetid: 7F9C2A99-42EB-4BCC-BB53-41C04FBBBF05
+ms.pagetype: security
keywords: ["encrypt", "digital signature"]
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: jdeckerMS
---
-
# Configure S/MIME for Windows 10 and Windows 10 Mobile
-
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
-
S/MIME stands for Secure/Multipurpose Internet Mail Extensions, and provides an added layer of security for email sent to and from an Exchange ActiveSync (EAS) account. In Windows 10, S/MIME lets users encrypt outgoing messages and attachments so that only intended recipients who have a digital identification (ID), also known as a certificate, can read them. Users can digitally sign a message, which provides the recipients with a way to verify the identity of the sender and that the message hasn't been tampered with.
-
## About message encryption
-
-
Users can send encrypted message to people in their organization and people outside their organization if they have their encryption certificates. However, users using Windows 10 Mail app can only read encrypted messages if the message is received on their Exchange account and they have corresponding decryption keys.
-
Encrypted messages can be read only by recipients who have a certificate. If you try to send an encrypted message to recipient(s) whose encryption certificate are not available, the app will prompt you to remove these recipients before sending the email.
-
## About digital signatures
-
-
A digitally signed message reassures the recipient that the message hasn't been tampered with and verifies the identity of the sender. Recipients can only verify the digital signature if they’re using an email client that supports S/MIME.
-
## Prerequisites
-
-
- [S/MIME is enabled for Exchange accounts](http://go.microsoft.com/fwlink/p/?LinkId=718217) (on-premises and Office 365). Users can’t use S/MIME signing and encryption with a personal account such as Outlook.com.
- Valid Personal Information Exchange (PFX) certificates are installed on the device.
-
- [How to Create PFX Certificate Profiles in Configuration Manager](http://go.microsoft.com/fwlink/p/?LinkID=718215)
- [Enable access to company resources using certificate profiles with Microsoft Intune](http://go.microsoft.com/fwlink/p/?LinkId=718216)
- [Install digital certificates on Windows 10 Mobile](installing-digital-certificates-on-windows-10-mobile.md)
-
## Choose S/MIME settings
-
-
On the device, perform the following steps: (add select certificate)
-
1. Open the Mail app. (In Windows 10 Mobile, the app is Outlook Mail.)
2. Open **Settings** by tapping the gear icon on a PC, or the ellipsis (...) and then the gear icon on a phone.
-
-
3. Tap **Email security**.
-
-
4. In **Select an account**, select the account for which you want to configure S/MIME options.
5. Make a certificate selection for digital signature and encryption.
-
- Select **Automatically** to let the app choose the certificate.
- Select **Manually** to specify the certificate yourself from the list of valid certificates on the device.
-
6. (Optional) Select **Always sign with S/MIME**, **Always encrypt with S/MIME**, or both, to automatically digitally sign or encrypt all outgoing messages.
**Note** The option to sign or encrypt can be changed for individual messages, unless EAS policies prevent it.
-
-
7. Tap the back arrow.
-
## Encrypt or sign individual messages
-
-
1. While composing a message, choose **Options** from the ribbon. On phone, **Options** can be accessed by tapping the the ellipsis (...).
2. Use **Sign** and **Encrypt** icons to turn on digital signature and encryption for this message.
-
-
## Read signed or encrypted messages
-
-
When you receive an encrypted message, the mail app will check whether there is a certificate available on your computer. If there is a certificate available, the message will be decrypted when you open it. If your certificate is stored on a smartcard, you will be prompted to insert the smartcard to read the message. Your smartcard may also require a PIN to access the certificate.
-
## Install certificates from a received message
-
-
When you receive a signed email, the app provide feature to install corresponding encryption certificate on your device if the certificate is available. This certificate can then be used to send encrypted email to this person.
-
1. Open a signed email.
-
2. Tap or click the digital signature icon in the reading pane.
-
3. Tap **Install.**
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/configure-the-appLocker-reference-device.md b/windows/keep-secure/configure-the-appLocker-reference-device.md
index 3d1f849430..d3dd0de7e5 100644
--- a/windows/keep-secure/configure-the-appLocker-reference-device.md
+++ b/windows/keep-secure/configure-the-appLocker-reference-device.md
@@ -2,66 +2,36 @@
title: Configure the AppLocker reference device (Windows 10)
description: This topic for the IT professional describes the steps to create an AppLocker policy platform structure on a reference computer.
ms.assetid: 034bd367-146d-4956-873c-e1e09e6fefee
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Configure the AppLocker reference device
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional describes the steps to create an AppLocker policy platform structure on a reference computer.
-
An AppLocker reference device that is used for the development and deployment of AppLocker policies should mimic the directory structure and corresponding applications in the organizational unit (OU) or business group for the production environment. On a reference device, you can:
-
- Maintain an application list for each business group.
-
- Develop AppLocker policies by creating individual rules or by creating a policy by automatically generating rules.
-
- Create the default rules to allow the Windows system files to run properly.
-
- Run tests and analyze the event logs to determine the affect of the policies that you intend to deploy.
-
The reference device does not need to be joined to a domain, but it must be able to import and export AppLocker policies in XML format. The reference computer must be running one of the supported editions of Windows as listed in [Requirements to use AppLocker](requirements-to-use-applocker.md).
-
**Warning**
Do not use operating system snapshots when creating AppLocker rules. If you take a snapshot of the operating system, install an app, create AppLocker rules, and then revert to a clean snapshot and repeat the process for another app, there is a chance that duplicate rule GUIDs can be created. If duplicate GUIDs are present, AppLocker policies will not work as expected.
-
-
**To configure a reference device**
-
1. If the operating system is not already installed, install one of the supported editions of Windows on the device.
-
**Note**
If you have the Group Policy Management Console (GPMC) installed on another device to test your implementation of AppLocker policies, you can export the policies to that device
-
-
2. Configure the administrator account.
-
To update local policies, you must be a member of the local Administrators group. To update domain policies, you must be a member of the Domain Admins group or have been delegated privileges to use Group Policy to update a Group Policy Object (GPO).
-
3. Install all apps that run in the targeted business group or OU by using the same directory structure.
-
The reference device should be configured to mimic the structure of your production environment. It depends on having the same apps in the same directories to accurately create the rules.
-
### See also
-
- After you configure the reference computer, you can create the AppLocker rule collections. You can build, import, or automatically generate the rules. For procedures to do this, see [Working with AppLocker rules](working-with-applocker-rules.md).
-
- [Use a reference device to create and maintain AppLocker policies](use-a-reference-computer-to-create-and-maintain-applocker-policies.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/configure-the-application-identity-service.md b/windows/keep-secure/configure-the-application-identity-service.md
index 2642394fff..2f0505366e 100644
--- a/windows/keep-secure/configure-the-application-identity-service.md
+++ b/windows/keep-secure/configure-the-application-identity-service.md
@@ -2,6 +2,7 @@
title: Configure the Application Identity service (Windows 10)
description: This topic for IT professionals shows how to configure the Application Identity service to start automatically or manually.
ms.assetid: dc469599-37fd-448b-b23e-5b8e4f17e561
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
@@ -10,40 +11,27 @@ author: brianlic-msft
# Configure the Application Identity service
-
**Applies to**
-
- Windows 10
This topic for IT professionals shows how to configure the Application Identity service to start automatically or manually.
-
The Application Identity service determines and verifies the identity of an app. Stopping this service will prevent AppLocker policies from being enforced.
**Important**
When using Group Policy, you must configure it to start automatically in at least one Group Policy Object (GPO) that applies AppLocker rules. This is because AppLocker uses this service to verify the attributes of a file.
-
-
**To start the Application Identity service automatically using Group Policy**
-
1. On the **Start** screen, type **gpmc.msc** to open the Group Policy Management Console (GPMC).
-
2. Locate the GPO to edit, right-click the GPO, and then click **Edit**.
-
3. In the console tree under **Computer Configuration\\Windows Settings\\Security Settings**, click **System Services**.
-
4. In the details pane, double-click **Application Identity**.
-
5. In **Application Identity Properties**, configure the service to start automatically.
Membership in the local **Administrators** group, or equivalent, is the minimum required to complete this procedure.
**To start the Application Identity service manually**
-
1. Right-click the taskbar, and click **Task Manager**.
-
2. Click the **Services** tab, right-click **AppIDSvc**, and then click **Start Service**.
-
3. Verify that the status for the Application Identity service is **Running**.
-Starting with Windows 10, the Application Identity service is now a protected process. Because of this, you can no longer manually set the service **Startup type** to **Automatic**.
\ No newline at end of file
+Starting with Windows 10, the Application Identity service is now a protected process. Because of this, you can no longer manually set the service **Startup type** to **Automatic**.
diff --git a/windows/keep-secure/configure-windows-defender-in-windows-10.md b/windows/keep-secure/configure-windows-defender-in-windows-10.md
index 73036c2430..b4f9e3572b 100644
--- a/windows/keep-secure/configure-windows-defender-in-windows-10.md
+++ b/windows/keep-secure/configure-windows-defender-in-windows-10.md
@@ -2,54 +2,34 @@
title: Configure Windows Defender in Windows 10 (Windows 10)
description: IT professionals can configure definition updates and cloud-based protection in Windows Defender in Windows 10 through Microsoft Active Directory and Windows Server Update Services (WSUS).
ms.assetid: 22649663-AC7A-40D8-B1F7-5CAD9E49653D
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: manage
ms.sitesec: library
author: jasesso
---
-
# Configure Windows Defender in Windows 10
-
-
**Applies to**
-
- Windows 10
-
IT professionals can configure definition updates and cloud-based protection in Windows Defender in Windows 10 through Microsoft Active Directory and Windows Server Update Services (WSUS).
-
## Configure definition updates
-
-
It is important to update definitions regularly to ensure that your endpoints are protected. Definition updates can be configured to suit the requirements of your organization.
-
Windows Defender supports the same updating options (such as using multiple definition sources) as other Microsoft endpoint protection products; for more information, see [Configuring Definition Updates](https://technet.microsoft.com/library/gg412502.aspx).
-
When you configure multiple definition sources in Windows Defender, you can configure the fallback order using the following values through *Group Policy* settings:
-
- InternalDefinitionUpdateServer - WSUS
- MicrosoftUpdateServer - Microsoft Update
- MMPC - [Microsoft Malware Protection Center definitions page](http://www.microsoft.com/security/portal/definitions/adl.aspx)
- FileShares - file share
-
Read about deploying administrative template files for Windows Defender in the article [Description of the Windows Defender Group Policy administrative template settings](https://support.microsoft.com/kb/927367).
-
You can also manage your Windows Defender update configuration settings through System Center Configuration Manager. See [How to Configure Definition Updates for Endpoint Protection in Configuration Manager](https://technet.microsoft.com/library/jj822983.aspx) for details.
-
## Definition update logic
-
-
You can update Windows Defender definitions in four ways depending on your business requirements:
-
- WSUS, the managed server. You can manage the distribution of updates that are released through Microsoft Update to computers in your enterprise environment; read more on the [Windows Server Update Services](https://technet.microsoft.com/windowsserver/bb332157.aspx) website.
- Microsoft Update, the unmanaged server. You can use this method to get regular updates from Microsoft Update.
- The [Microsoft Malware Protection Center definitions page](http://www.microsoft.com/security/portal/definitions/adl.aspx), as an alternate download location. You can use this method if you want to download the latest definitions.
- File share, where the definition package is downloaded. You can retrieve definition updates from a file share. The file share must be provisioned on a regular basis with the update files.
-
## Update Windows Defender definitions through Active Directory and WSUS
-
-
This section details how to update Windows Defender definitions for Windows 10 endpoints through Active Directory and WSUS.
-
@@ -127,99 +107,52 @@ This section details how to update Windows Defender definitions for Windows 10
-
-
## Manage cloud-based protection
-
-
Windows Defender offers improved cloud-based protection and threat intelligence for endpoint protection clients using the Microsoft Active Protection Service. Read more about the Microsoft Active Protection Service community in [Join the Microsoft Active Protection Service community](http://windows.microsoft.com/windows-8/join-maps-community).
-
You can enable or disable the Microsoft Active Protection Service using *Group Policy* settings and administrative template files.
-
More information on deploying administrative template files for Windows Defender is available in the article [Description of the Windows Defender Group Policy administrative template settings](https://support.microsoft.com/kb/927367).
-
The Microsoft Active Protection Service can be configured with the following *Group Policy* settings:
-
1. Open the **Group Policy Editor**.
2. In the **Local Computer Policy** tree, expand **Computer Configuration**, then **Administrative Templates**, then **Windows Components**, then **Windows Defender**.
3. Click on **MAPS**.
4. Double-click on **Join Microsoft MAPS**.
5. Select your configuration option from the **Join Microsoft MAPS** list.
**Note** Any settings modified on an endpoint will be overridden by the administrator's policy setting.
-
-
Use the Windowsdefender.adm *Group Policy* template file to control the policy settings for Windows Defender in Windows 10:
-
Policy setting: **Configure Microsoft SpyNet Reporting**
-
Registry key name: **HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\SpyNet\\SpyNetReporting**
-
Policy description: **Adjusts membership in Microsoft Active Protection Service**
-
You can also configure preferences using the following PowerShell parameters:
-
- Turn Microsoft Active Protection Service off: *Set-MpPreference -MAPSReporting 0*
- Turn Microsoft Active Protection Service on: *Set-MpPreference -MAPSReporting 2*
-
Read more about this in:
-
- [Scripting with Windows PowerShell](https://technet.microsoft.com/library/bb978526.aspx)
- [Defender Cmdlets](https://technet.microsoft.com/library/dn433280.aspx)
-
**Note** Any information that Windows Defender collects is encrypted in transit to our servers, and then stored in secure facilities. Microsoft takes several steps to avoid collecting any information that directly identifies you, such as your name, email address, or account ID.
-
-
Read more about how to manage your privacy settings in [Setting your preferences for Windows 10 services](http://windows.microsoft.com/windows-10/services-setting-preferences).
-
## Opt-in to Microsoft Update
-
-
You can use Microsoft Update to keep definitions on mobile computers running Windows Defender in Windows 10 up to date when they are not connected to the corporate network. If the mobile computer doesn't have a [Windows Server Update Service](https://technet.microsoft.com/windowsserver/bb332157.aspx) (WSUS) connection, the signatures will still come from Microsoft Update. This means that signatures can be pushed down (via Microsoft Update) even if WSUS overrides Windows Update.
-
You need to opt-in to Microsoft Update on the mobile computer before it can retrieve the definition updates from Microsoft Update.
-
There are two ways you can opt-in to Microsoft Update in Windows Defender for Windows 10:
-
1. Use a VBScript to create a script, then run it on each computer in your network.
2. Manually opt-in every computer on your network through the **Settings** menu.
-
You can create a VBScript and run it on each computer on your network; this is an efficient way to opt-in to Microsoft Update.
-
**Use a VBScript to opt in to Microsoft Update**
-
1. Use the instructions in the MSDN article [Opt-In to Microsoft Update](https://msdn.microsoft.com/library/windows/desktop/aa826676.aspx) to create the VBScript.
2. Run the VBScript you created on each computer in your network.
-
You can manually opt-in each individual computer on your network to receive Microsoft Update.
-
**Manually opt-in to Microsoft Update**
-
1. Open **Windows Update** in **Update & security** settings on the computer you want to opt-in.
2. Click **Advanced** options.
3. Select the checkbox for **Give me updates for other Microsoft products when I update Windows**.
-
## Schedule updates for Microsoft Update
-
-
Opting-in to Microsoft Update means that your system administrator can schedule updates to your mobile computer, so that it keeps up-to-date with the latest software versions and security definitions, even when you’re on the road.
-
For more information on scheduling updates, see [Configure definition updates](https://technet.microsoft.com/library/mt622088.aspx#configure-definition-updates).
-
## Related topics
-
-
[Update and manage Windows Defender in Windows 10](get-started-with-windows-defender-for-windows-10.md)
-
[Troubleshoot Windows Defender in Windows 10](troubleshoot-windows-defender-in-windows-10.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/create-a-basic-audit-policy-settings-for-an-event-category.md b/windows/keep-secure/create-a-basic-audit-policy-settings-for-an-event-category.md
index bf422552a0..08b1dfb88d 100644
--- a/windows/keep-secure/create-a-basic-audit-policy-settings-for-an-event-category.md
+++ b/windows/keep-secure/create-a-basic-audit-policy-settings-for-an-event-category.md
@@ -2,36 +2,26 @@
title: Create a basic audit policy for an event category (Windows 10)
description: By defining auditing settings for specific event categories, you can create an auditing policy that suits the security needs of your organization.
ms.assetid: C9F52751-B40D-482E-BE9D-2C61098249D3
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Create a basic audit policy for an event category
-
-
**Applies to**
-
- Windows 10
-
By defining auditing settings for specific event categories, you can create an auditing policy that suits the security needs of your organization. On devices that are joined to a domain, auditing settings for the event categories are undefined by default. On domain controllers, auditing is turned on by default.
-
To complete this procedure, you must be logged on as a member of the built-in Administrators group.
-
**To define or modify auditing policy settings for an event category for your local computer**
-
1. Open the Local Security Policy snap-in (secpol.msc), and then click **Local Policies**.
2. Click **Audit Policy**.
3. In the results pane, double-click an event category that you want to change the auditing policy settings for.
4. Do one or both of the following, and then click **OK.**
- To audit successful attempts, select the **Success** check box.
- To audit unsuccessful attempts, select the **Failure** check box.
-
To complete this procedure, you must be logged on as a member of the Domain Admins group.
-
**To define or modify auditing policy settings for an event category for a domain or organizational unit, when you are on a member server or on a workstation that is joined to a domain**
-
1. Open the Group Policy Management Console (GPMC).
2. In the console tree, double-click **Group Policy objects** in the forest and domain containing the **Default Domain Policy** Group Policy object (GPO) that you want to edit.
3. Right-click the **Default Domain Policy** GPO, and then click **Edit**.
@@ -41,19 +31,9 @@ To complete this procedure, you must be logged on as a member of the Domain Admi
7. Do one or both of the following, and then click **OK.**
- To audit successful attempts, select the **Success** check box.
- To audit unsuccessful attempts, select the **Failure** check box.
-
## Additional considerations
-
-
- To audit object access, enable auditing of the object access event category by following the steps above. Then, enable auditing on the specific object.
- After your audit policy is configured, events will be recorded in the Security log. Open the Security log to view these events.
- The default auditing policy setting for domain controllers is **No Auditing**. This means that even if auditing is enabled in the domain, the domain controllers do not inherit auditing policy locally. If you want domain auditing policy to apply to domain controllers, you must modify this policy setting.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/create-a-pagefile.md b/windows/keep-secure/create-a-pagefile.md
index ffa275db74..31839c324f 100644
--- a/windows/keep-secure/create-a-pagefile.md
+++ b/windows/keep-secure/create-a-pagefile.md
@@ -2,50 +2,30 @@
title: Create a pagefile (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Create a pagefile security policy setting.
ms.assetid: dc087897-459d-414b-abe0-cd86c8dccdea
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Create a pagefile
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Create a pagefile** security policy setting.
-
## Reference
-
-
Windows designates a section of the hard drive as virtual memory known as the page file, or more specifically, as pagefile.sys. It is used to supplement the computer’s Random Access Memory (RAM) to improve performance for programs and data that are used frequently. Although the file is hidden from browsing, you can manage it using the system settings.
-
This policy setting determines which users can create and change the size of a page file. It determines whether users can specify a page file size for a particular drive in the **Performance Options** box located on the **Advanced** tab of the **System Properties** dialog box or through using internal application interfaces (APIs).
-
Constant: SeCreatePagefilePrivilege
-
### Possible values
-
- User-defined list of accounts
-
- Administrators
-
### Best practices
-
- Restrict the **Create a pagefile** user right to Administrators, which is the default.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
By default, members of the Administrators group have this right.
-
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
-
@@ -84,57 +64,26 @@ The following table lists the actual and effective default policy values for the
-
-
## Policy management
-
-
A restart of the device is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
### Group Policy
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Users who can change the page file size could make it extremely small or move the file to a highly fragmented storage volume, which could cause reduced device performance.
-
### Countermeasure
-
Restrict the **Create a pagefile** user right to members of the Administrators group.
-
### Potential impact
-
None. Restricting this right to members of the Administrators group is the default configuration.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/create-a-rule-for-packaged-apps.md b/windows/keep-secure/create-a-rule-for-packaged-apps.md
index f16c4fcee9..2474296f59 100644
--- a/windows/keep-secure/create-a-rule-for-packaged-apps.md
+++ b/windows/keep-secure/create-a-rule-for-packaged-apps.md
@@ -2,47 +2,29 @@
title: Create a rule for packaged apps (Windows 10)
description: This topic for IT professionals shows how to create an AppLocker rule for packaged apps with a publisher condition.
ms.assetid: e4ffd400-7860-47b3-9118-0e6853c3dfa0
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Create a rule for packaged apps
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals shows how to create an AppLocker rule for packaged apps with a publisher condition.
-
Packaged apps, also known as Universal Windows apps, are based on an app model that ensures that all the files within an app package share the same identity. Therefore, it is possible to control the entire app using a single AppLocker rule as opposed to the non-packaged apps where each file within the app could have a unique identity. Windows does not support unsigned packaged apps which implies all packaged apps must be signed. AppLocker supports only publisher rules for packaged apps. A publisher rule for a packaged app is based on the following information:
-
- Publisher of the package
-
- Package name
-
- Package version
-
All the files within a package as well as the package installer share these attributes. Therefore, an AppLocker rule for a packaged app controls both the installation as well as the running of the app. Otherwise, the publisher rules for packaged apps are no different than the rest of the rule collections; they support exceptions, can be increased or decreased in scope, and can be assigned to users and groups.
-
For info about the publisher condition, see [Understanding the publisher rule condition in AppLocker](understanding-the-publisher-rule-condition-in-applocker.md).
-
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group Policy Object (GPO) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or in a security template. For info how to use these MMC snap-ins to administer AppLocker, see [Administer AppLocker](administer-applocker.md#bkmk-using-snapins).
-
**To create a packaged app rule**
-
1. Open the AppLocker console.
-
2. On the **Action** menu, or by right-clicking on **Packaged app Rules**, click **Create New Rule**.
-
3. On the **Before You Begin** page, click **Next**.
-
4. On the **Permissions** page, select the action (allow or deny) and the user or group that the rule should apply to, and then click **Next**.
-
5. On the **Publisher** page, you can select a specific reference for the packaged app rule and set the scope for the rule. The following table describes the reference options.
-
@@ -69,11 +51,8 @@ You can perform this task by using the Group Policy Management Console for an Ap
-
-
The following table describes setting the scope for the packaged app rule.
-
@@ -116,20 +95,9 @@ You can perform this task by using the Group Policy Management Console for an Ap
-
-
6. Click **Next**.
-
7. (Optional) On the **Exceptions** page, specify conditions by which to exclude files from being affected by the rule. This allows you to add exceptions based on the same rule reference and rule scope as you set before. Click **Next**.
-
8. On the **Name** page, either accept the automatically generated rule name or type a new rule name, and then click **Create**.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/create-a-rule-that-uses-a-file-hash-condition.md b/windows/keep-secure/create-a-rule-that-uses-a-file-hash-condition.md
index 19f8350862..f5a2a1ed28 100644
--- a/windows/keep-secure/create-a-rule-that-uses-a-file-hash-condition.md
+++ b/windows/keep-secure/create-a-rule-that-uses-a-file-hash-condition.md
@@ -2,55 +2,30 @@
title: Create a rule that uses a file hash condition (Windows 10)
description: This topic for IT professionals shows how to create an AppLocker rule with a file hash condition.
ms.assetid: eb3b3524-1b3b-4979-ba5a-0a0b1280c5c7
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Create a rule that uses a file hash condition
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals shows how to create an AppLocker rule with a file hash condition.
-
File hash rules use a system-computed cryptographic hash of the identified file.
-
For info about the file hash condition, see [Understanding the File Hash Rule Condition in AppLocker](understanding-the-file-hash-rule-condition-in-applocker.md).
-
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group Policy Object (GPO) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or in a security template. For info how to use these MMC snap-ins to administer AppLocker, see [Administer AppLocker](administer-applocker.md#bkmk-using-snapins).
-
**To create a new rule with a file hash condition**
-
1. Open the AppLocker console, and then click the rule collection that you want to create the rule for.
-
2. On the **Action** menu, click **Create New Rule**.
-
3. On the **Before You Begin** page, click **Next**.
-
4. On the **Permissions** page, select the action (allow or deny) and the user or group that the rule should apply to, and then click **Next**.
-
5. On the **Conditions** page, select the **File hash** rule condition, and then click **Next**.
-
6. **Browse Files** to locate the targeted application file.
-
**Note**
You can also click **Browse Folders** which calculates the hash for all the appropriate files relative to the rule collection. To remove hashes individually, click the **Remove** button.
-
-
7. Click **Next**.
-
8. On the **Name** page, either accept the automatically generated rule name or type a new rule name, and then click **Create**.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/create-a-rule-that-uses-a-path-condition.md b/windows/keep-secure/create-a-rule-that-uses-a-path-condition.md
index 59f864fa6e..3130eeb9a7 100644
--- a/windows/keep-secure/create-a-rule-that-uses-a-path-condition.md
+++ b/windows/keep-secure/create-a-rule-that-uses-a-path-condition.md
@@ -2,62 +2,34 @@
title: Create a rule that uses a path condition (Windows 10)
description: This topic for IT professionals shows how to create an AppLocker rule with a path condition.
ms.assetid: 9b2093f5-5976-45fa-90c3-da1e0e845d95
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Create a rule that uses a path condition
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals shows how to create an AppLocker rule with a path condition.
-
The path condition identifies an app by its location in the file system of the computer or on the network.
-
**Important**
When creating a rule that uses a deny action, path conditions are less secure for preventing access to a file because a user could easily copy the file to a different location than what is specified in the rule. Because path rules correspond to locations within the file system, you should ensure that there are no subdirectories that are writable by non-administrators. For example, if you create a path rule for C:\\ with the allow action, any file within C:\\ will be allowed to run, including users' profiles.
-
-
For info about the path condition, see [Understanding the path rule condition in AppLocker](understanding-the-path-rule-condition-in-applocker.md).
-
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group Policy Object (GPO) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or in a security template. For information how to use these MMC snap-ins to administer AppLocker, see [Administer AppLocker](administer-applocker.md#bkmk-using-snapins).
-
**To create a new rule with a path condition**
-
1. Open the AppLocker console, and then click the rule collection that you want to create the rule for.
-
2. On the **Action** menu, click **Create New Rule**.
-
3. On the **Before You Begin** page, click **Next**.
-
4. On the **Permissions** page, select the action (allow or deny) and the user or group that the rule should apply to, and then click **Next**.
-
5. On the **Conditions** page, select the **Path** rule condition, and then click **Next**.
-
6. Click **Browse Files** to locate the targeted folder for the app.
-
**Note**
When you browse to a file or folder location, the wizard automatically converts absolute file paths to use AppLocker path variables. You may edit the path after browsing to specify an absolute path, or you may type the path directly into the **Path** box. To learn more about AppLocker path variables, see [Understanding the path rule condition in AppLocker](understanding-the-path-rule-condition-in-applocker.md).
-
-
7. Click **Next**.
-
8. (Optional) On the **Exceptions** page, specify conditions by which to exclude files from being affected by the rule. Click **Next**.
-
9. On the **Name** page, either accept the automatically generated rule name or type a new rule name, and then click **Create**.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/create-a-rule-that-uses-a-publisher-condition.md b/windows/keep-secure/create-a-rule-that-uses-a-publisher-condition.md
index cbbec57db2..11baddf574 100644
--- a/windows/keep-secure/create-a-rule-that-uses-a-publisher-condition.md
+++ b/windows/keep-secure/create-a-rule-that-uses-a-publisher-condition.md
@@ -2,54 +2,29 @@
title: Create a rule that uses a publisher condition (Windows 10)
description: This topic for IT professionals shows how to create an AppLocker rule with a publisher condition.
ms.assetid: 345ad45f-2bc1-4c4c-946f-17804e29f55b
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Create a rule that uses a publisher condition
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals shows how to create an AppLocker rule with a publisher condition.
-
You can use publisher conditions only for files that are digitally signed; the publisher condition identifies an app based on its digital signature and extended attributes. The digital signature contains information about the company that created the app (the publisher). The extended attributes, which are obtained from the binary resource, contain the name of the product that the file is part of and the version number of the application. The publisher may be a software development company, such as Microsoft, or the information technology department of your organization.
-
Packaged app rules are by definition rules that use publisher conditions. For info about creating a packaged app rule, see [Create a rule for packaged apps](create-a-rule-for-packaged-apps.md).
-
For info about the publisher condition, see [Understanding the publisher rule condition in AppLocker](understanding-the-publisher-rule-condition-in-applocker.md).
-
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group Policy Object (GPO) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or in a security template. For info how to use these MMC snap-ins to administer AppLocker, see [Administer AppLocker](administer-applocker.md#bkmk-using-snapins).
-
**To create a new rule with a publisher condition**
-
1. Open the AppLocker console, and then click the rule collection that you want to create the rule for.
-
2. On the **Action** menu, click **Create New Rule**.
-
3. On the **Before You Begin** page, click **Next**.
-
4. On the **Permissions** page, select the action (allow or deny) and the user or group that the rule should apply to, and then click **Next**.
-
5. On the **Conditions** page, select the **Publisher** rule condition, and then click **Next**.
-
6. On the **Publisher** page, click **Browse** to select a signed file, and then use the slider to specify the scope of the rule. To use custom values in any of the fields or to specify a specific file version, select the **Use custom values** check box. For example, you can use the asterisk (\*) wildcard character within a publisher rule to specify that any value should be matched.
-
7. Click **Next**.
-
8. (Optional) On the **Exceptions** page, specify conditions by which to exclude files from being affected by the rule. Click **Next**.
-
9. On the **Name** page, either accept the automatically generated rule name or type a new rule name, and then click **Create**.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/create-a-token-object.md b/windows/keep-secure/create-a-token-object.md
index f5be6bd569..1c972b491b 100644
--- a/windows/keep-secure/create-a-token-object.md
+++ b/windows/keep-secure/create-a-token-object.md
@@ -2,50 +2,30 @@
title: Create a token object (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Create a token object security policy setting.
ms.assetid: bfbf52fc-6ba4-442a-9df7-bd277e55729c
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Create a token object
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Create a token object** security policy setting.
-
## Reference
-
-
This policy setting determines which accounts a process can use to create a token, and which accounts it can then use to gain access to local resources when the process uses NtCreateToken() or other token-creation APIs.
-
When a user logs on to the local device or connects to a remote device through a network, Windows builds the user’s access token. Then the system examines the token to determine the level of the user's privileges. When you revoke a privilege, the change is immediately recorded, but the change is not reflected in the user's access token until the next time the user logs on or connects.
-
Constant: SeCreateTokenPrivilege
-
### Possible values
-
- User-defined list of accounts
-
- Not Defined
-
### Best practices
-
- This user right is used internally by the operating system. Unless it is necessary, do not assign this user right to a user, group, or process other than Local System.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
This user right is used internally by the operating system. By default, it is not assigned to any user groups.
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -84,62 +64,29 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Policy management
-
-
A restart of the device is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
### Group Policy
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
**Caution**
A user account that is given this user right has complete control over the system, and it can lead to the system being compromised. We highly recommend that you do not assign this right to any user accounts.
-
-
Windows examines a user's access token to determine the level of the user's privileges. Access tokens are built when users log on to the local device or connect to a remote device over a network. When you revoke a privilege, the change is immediately recorded, but the change is not reflected in the user's access token until the next time the user logs on or connects. Users with the ability to create or modify tokens can change the level of access for any account on a computer if they are currently logged on. They could escalate their privileges or create a DoS condition.
-
### Countermeasure
-
Do not assign the **Create a token object** user right to any users. Processes that require this user right should use the Local System account, which already includes it, instead of a separate user account that has this user right assigned.
-
### Potential impact
-
None. Not Defined is the default configuration.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/create-applocker-default-rules.md b/windows/keep-secure/create-applocker-default-rules.md
index d701502116..15c82719f5 100644
--- a/windows/keep-secure/create-applocker-default-rules.md
+++ b/windows/keep-secure/create-applocker-default-rules.md
@@ -2,43 +2,24 @@
title: Create AppLocker default rules (Windows 10)
description: This topic for IT professionals describes the steps to create a standard set of AppLocker rules that will allow Windows system files to run.
ms.assetid: 21e9dc68-a6f4-4ebe-ac28-4c66a7ab6e18
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Create AppLocker default rules
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals describes the steps to create a standard set of AppLocker rules that will allow Windows system files to run.
-
AppLocker includes default rules for each rule collection. These rules are intended to help ensure that the files that are required for Windows to operate properly are allowed to run.
-
**Important**
You can use the default rules as a template when creating your own rules to allow files within the Windows folders to run. However, these rules are only meant to function as a starter policy when you are first testing AppLocker rules. The default rules can be modified in the same way as other AppLocker rule types.
-
-
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group Policy Object (GPO) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or in a security template. For information how to use these MMC snap-ins to administer AppLocker, see [Administer AppLocker](administer-applocker.md#bkmk-using-snapins).
-
**To create default rules**
-
1. Open the AppLocker console.
-
2. Right-click the appropriate rule type for which you want to automatically generate default rules. You can automatically generate rules for executable, Windows Installer, script rules and Packaged app rules.
-
3. Click **Create Default Rules**.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/create-edp-policy-using-intune.md b/windows/keep-secure/create-edp-policy-using-intune.md
index 71d19b6949..e2dab16028 100644
--- a/windows/keep-secure/create-edp-policy-using-intune.md
+++ b/windows/keep-secure/create-edp-policy-using-intune.md
@@ -18,21 +18,6 @@ author: eross-msft
Microsoft Intune helps you create and deploy your enterprise data protection (EDP) policy, including letting you choose your protected apps, your EDP-protection level, and how to find enterprise data on the network.
-## In this topic:
-- [Add an EDP policy](#add-an-edp-policy)
-
-- [Add individual apps to your Protected App list](#add-individual-apps-to-your-protected-app-list)
-
-- [Exempt apps from EDP restrictions](#exempt-apps-from-EDP-restrictions)
-
-- [Manage the EDP protection level for your enterprise data](#manage-the-edp-protection-level-for-your-enterprise-data)
-
-- [Define your enterprise-managed identity domains](#define-your-enterprise-managed-identity-domains)
-
-- [Choose where apps can access enterprise data](#choose-where-apps-can-access-enterprise-data)
-
-- [Choose your optional EDP-related settings](#choose-your-optional-EDP-related-settings)
-
## Add an EDP policy
After you’ve installed and set up Intune for your organization, you must create an EDP-specific policy.
diff --git a/windows/keep-secure/create-global-objects.md b/windows/keep-secure/create-global-objects.md
index dd10fb6763..7e51c7a813 100644
--- a/windows/keep-secure/create-global-objects.md
+++ b/windows/keep-secure/create-global-objects.md
@@ -2,50 +2,30 @@
title: Create global objects (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Create global objects security policy setting.
ms.assetid: 9cb6247b-44fc-4815-86f2-cb59b6f0221e
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Create global objects
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Create global objects** security policy setting.
-
## Reference
-
-
This policy setting determines which users can create global objects that are available to all sessions. Users can still create objects that are specific to their own session if they do not have this user right.
-
A global object is an object that is created to be used by any number of processes or threads, even those not started within the user’s session. Remote Desktop Services uses global objects in its processes to facilitate connections and access.
-
Constant: SeCreateGlobalPrivilege
-
### Possible values
-
- User-defined list of accounts
-
- Default accounts listed below
-
### Best practices
-
- Do not assign any user accounts this right.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
By default, members of the Administrators group have this right, as do Local Service and Network Service accounts on the supported versions of Windows. Service is included for backwards compatibility with earlier versions of Windows.
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -99,62 +79,29 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Policy management
-
-
A restart of the device is not required for this policy setting to take effect.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
### Group Policy
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
**Caution**
A user account that is given this user right has complete control over the system, and it can lead to the system being compromised. We highly recommend that you do not assign this right to any user accounts.
-
-
Windows examines a user's access token to determine the level of the user's privileges. Access tokens are built when users log on to the local device or connect to a remote device over a network. When you revoke a privilege, the change is immediately recorded, but the change is not reflected in the user's access token until the next time the user logs on or connects. Users with the ability to create or modify tokens can change the level of access for any currently logged on account. They could escalate their privileges or create a denial-of-service (DoS) condition.
-
### Countermeasure
-
Do not assign the **Create a token object** user right to any users. Processes that require this user right should use the Local System account, which already includes it, instead of a separate user account with this user right assigned.
-
### Potential impact
-
None. Not Defined is the default domain policy configuration.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/create-list-of-applications-deployed-to-each-business-group.md b/windows/keep-secure/create-list-of-applications-deployed-to-each-business-group.md
index 64fb148309..6afbbb8eb8 100644
--- a/windows/keep-secure/create-list-of-applications-deployed-to-each-business-group.md
+++ b/windows/keep-secure/create-list-of-applications-deployed-to-each-business-group.md
@@ -2,91 +2,47 @@
title: Create a list of apps deployed to each business group (Windows 10)
description: This topic describes the process of gathering app usage requirements from each business group in order to implement application control policies by using AppLocker.
ms.assetid: d713aa07-d732-4bdc-8656-ba616d779321
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Create a list of apps deployed to each business group
-
-
**Applies to**
-
- Windows 10
-
This topic describes the process of gathering app usage requirements from each business group in order to implement application control policies by using AppLocker.
-
## Determining app usage
-
-
For each business group, determine the following:
-
- The complete list of apps used, including different versions of an app
-
- The full installation path of the app
-
- The publisher and signed status of each app
-
- The type of requirement the business groups set for each app, such as business critical, business productivity, optional, or personal. It might also be helpful during this effort to identify which apps are supported or unsupported by your IT department, or supported by others outside your control.
-
- A list of files or apps that require administrative credentials to install or run. If the file requires administrative credentials to install or run, users who cannot provide administrative credentials will be prevented from running the file even if the file is explicitly allowed by an AppLocker policy. Even with AppLocker policies enforced, only members of the Administrators group can install or run files that require administrative credentials.
-
### How to perform the app usage assessment
-
Although you might already have a method in place to understand app usage for each business group, you will need to use this information to help create your AppLocker rule collection. AppLocker includes the Automatically Generate Rules wizard and the **Audit only** enforcement configuration to assist you with planning and creating your rule collection.
-
**Application inventory methods**
-
Using the Automatically Generate Rules wizard quickly creates rules for the applications you specify. The wizard is designed specifically to build a rule collection. You can use the Local Security Policy snap-in to view and edit the rules. This method is very useful when creating rules from a reference computer, and when creating and evaluating AppLocker policies in a testing environment. However, it does require that the files be accessible on the reference computer or through a network drive. This might mean additional work in setting up the reference computer and determining a maintenance policy for that computer.
-
Using the **Audit only** enforcement method permits you to view the logs because it collects information about every process on the computers receiving the Group Policy Object (GPO). Therefore, you can see what the enforcement will be on the computers in a business group. AppLocker includes Windows PowerShell cmdlets that you can use to analyze the events from the event log and cmdlets to create rules. However, when you use Group Policy to deploy to several computers, a means to collect events in a central location is very important for manageability. Because AppLocker logs information about files that users or other processes start on a computer, you could miss creating some rules initially. Therefore, you should continue your evaluation until you can verify that all required applications that are allowed to run are accessed successfully.
-
**Tip**
If you run Application Verifier against a custom application with any AppLocker policies enabled, it might prevent the application from running. You should either disable Application Verifier or AppLocker.
-
You can create an inventory of Universal Windows apps on a device by using two methods: the **Get-AppxPackage** Windows PowerShell cmdlet or the AppLocker console.
-
-
The following topics in the [AppLocker Step-by-Step Guide](http://go.microsoft.com/fwlink/p/?LinkId=160261) describe how to perform each method:
-
- [Automatically generating executable rules from a reference computer](http://go.microsoft.com/fwlink/p/?LinkId=160264)
-
- [Using auditing to track which apps are used](http://go.microsoft.com/fwlink/p/?LinkId=160281)
-
### Prerequisites to completing the inventory
-
Identify the business group and each organizational unit (OU) within that group to which you will apply application control policies. In addition, you should have identified whether or not AppLocker is the most appropriate solution for these policies. For info about these steps, see the following topics:
-
- [Understand AppLocker policy design decisions](understand-applocker-policy-design-decisions.md)
-
- [Determine your application control objectives](determine-your-application-control-objectives.md)
-
## Next steps
-
-
Identify and develop the list of apps. Record the name of the app, whether it is signed or not as indicated by the publisher's name, and whether or not it is a mission critical, business productivity, optional, or personal application. Record the installation path of the apps. For info about how to do this, see [Document your app list](document-your-application-list.md).
-
After you have created the list of apps, the next step is to identify the rule collections, which will become the policies. This information can be added to the table under columns labeled:
-
- Use default rule or define new rule condition
-
- Allow or deny
-
- GPO name
-
To do this, see the following topics:
-
- [Select the types of rules to create](select-types-of-rules-to-create.md)
-
- [Determine the Group Policy structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/create-permanent-shared-objects.md b/windows/keep-secure/create-permanent-shared-objects.md
index 79fc9f07f7..ee6979dbe5 100644
--- a/windows/keep-secure/create-permanent-shared-objects.md
+++ b/windows/keep-secure/create-permanent-shared-objects.md
@@ -2,48 +2,29 @@
title: Create permanent shared objects (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Create permanent shared objects security policy setting.
ms.assetid: 6a58438d-65ca-4c4a-a584-450eed976649
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Create permanent shared objects
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Create permanent shared objects** security policy setting.
-
## Reference
-
-
This user right determines which accounts can be used by processes to create a directory object by using the object manager. Directory objects include Active Directory objects, files and folders, printers, registry keys, processes, and threads. Users who have this capability can create permanent shared objects, including devices, semaphores, and mutexes. This user right is useful to kernel-mode components that extend the object namespace. Because components that are running in kernel-mode inherently have this user right assigned to them, it is not necessary to specifically assign it.
-
Constant: SeCreatePermanentPrivilege
-
### Possible values
-
- User-defined list of accounts
-
- Not Defined
-
### Best practices
-
- Users who have the **Create permanent shared objects** user right could create new shared objects and expose sensitive data to the network. Therefore, do not assign this right to any users.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
By default, **LocalSystem** is the only account that has this right.
-
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
-
@@ -82,59 +63,27 @@ The following table lists the actual and effective default policy values for the
-
-
## Policy management
-
-
This section describes different features and tools available to help you manage this policy.
-
A restart of the device is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
### Group Policy
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Users who have the **Create permanent shared objects** user right could create new shared objects and expose sensitive data to the network.
-
### Countermeasure
-
Do not assign the **Create permanent shared objects** user right to any users. Processes that require this user right should use the System account, which already includes this user right, instead of a separate user account.
-
### Potential impact
-
None. Not Defined is the default configuration.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/create-symbolic-links.md b/windows/keep-secure/create-symbolic-links.md
index 38de1ae084..618cd6c90a 100644
--- a/windows/keep-secure/create-symbolic-links.md
+++ b/windows/keep-secure/create-symbolic-links.md
@@ -2,52 +2,31 @@
title: Create symbolic links (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Create symbolic links security policy setting.
ms.assetid: 882922b9-0ff8-4ee9-8afc-4475515ee3fd
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Create symbolic links
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Create symbolic links** security policy setting.
-
## Reference
-
-
This user right determines if users can create a symbolic link from the device they are logged on to.
-
A symbolic link is a file-system object that points to another file-system object. The object that is pointed to is called the target. Symbolic links are transparent to users. The links appear as normal files or directories, and they can be acted upon by the user or application in exactly the same manner. Symbolic links are designed to aid in migration and application compatibility with UNIX operating systems. Microsoft has implemented symbolic links to function just like UNIX links.
-
**Warning** This privilege should only be given to trusted users. Symbolic links can expose security vulnerabilities in applications that aren't designed to handle them.
-
Constant: SeCreateSymbolicLinkPrivilege
-
### Possible values
-
- User-defined list of accounts
-
- Not Defined
-
### Best practices
-
- This user right should only be given to trusted users. Symbolic links can expose security vulnerabilities in applications that are not designed to handle them.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
By default, members of the Administrators group have this right.
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -86,63 +65,29 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Policy management
-
-
This section describes different features and tools available to help you manage this policy.
-
A restart of the device is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
### Group Policy
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
### Command-line tools
-
This setting can be used in conjunction with a symbolic link file system setting that can be manipulated with the command-line tool to control the kinds of symlinks that are allowed on the device. For more info, type **fsutil behavior set symlinkevalution /?** at the command prompt.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Users who have the **Create symbolic links** user right could inadvertently or maliciously expose your system to symbolic link attacks. Symbolic link attacks can be used to change the permissions on a file, to corrupt data, to destroy data, or as a DoS attack.
-
### Countermeasure
-
Do not assign the **Create symbolic links** user right to standard users. Restrict this right to trusted administrators. You can use the **fsutil** command to establish a symbolic link file system setting that controls the kind of symbolic links that can be created on a computer.
-
### Potential impact
-
None. Not defined is the default configuration.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/create-your-applocker-planning-document.md b/windows/keep-secure/create-your-applocker-planning-document.md
index c05e7740c9..990887b439 100644
--- a/windows/keep-secure/create-your-applocker-planning-document.md
+++ b/windows/keep-secure/create-your-applocker-planning-document.md
@@ -2,64 +2,37 @@
title: Create your AppLocker planning document (Windows 10)
description: This planning topic for the IT professional summarizes the information you need to research and include in your AppLocker planning document.
ms.assetid: 41e49644-baf4-4514-b089-88adae2d624e
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Create your AppLocker planning document
-
-
**Applies to**
-
- Windows 10
-
This planning topic for the IT professional summarizes the information you need to research and include in your AppLocker planning document.
-
## The AppLocker deployment design
-
-
The design process and the planning document help you investigate application usage in your organization and record your findings so you can effectively deploy and maintain application control policies by using AppLocker.
-
You should have completed these steps in the design and planning process:
-
1. [Determine your application control objectives](determine-your-application-control-objectives.md)
-
2. [Create a list of apps deployed to each business group](create-list-of-applications-deployed-to-each-business-group.md)
-
3. [Select types of rules to create](select-types-of-rules-to-create.md)
-
4. [Determine Group Policy structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md)
-
5. [Plan for AppLocker policy management](plan-for-applocker-policy-management.md)
-
### AppLocker planning document contents
-
Your planning document should contain:
-
- A list of business groups that will participate in the application control policy project, their requirements, a description of their business processes, and contact information.
-
- Application control policy project target dates, both for planning and deployment.
-
- A complete list of apps used by each business group (or organizational unit), including version information and installation paths.
-
- What condition to apply to rules governing each application (or whether to use the default set provided by AppLocker).
-
- A strategy for using Group Policy to deploy the AppLocker policies.
-
- A strategy in processing the application usage events generated by AppLocker.
-
- A strategy to maintain and manage AppLocker polices after deployment.
-
### Sample template for an AppLocker planning document
-
You can use the following form to construct your own AppLocker planning document.
-
**Business group**:
-
**Operating system environment**: (Windows and non-Windows)
-
@@ -94,11 +67,8 @@ You can use the following form to construct your own AppLocker planning document
-
-
**Rules**
-
@@ -138,11 +108,8 @@ You can use the following form to construct your own AppLocker planning document
-
-
**Event processing**
-
@@ -170,11 +137,8 @@ You can use the following form to construct your own AppLocker planning document
-
-
**Policy maintenance**
-
@@ -203,13 +167,9 @@ You can use the following form to construct your own AppLocker planning document
-
-
### Example of an AppLocker planning document
-
**Rules**
-
@@ -306,11 +266,8 @@ You can use the following form to construct your own AppLocker planning document
-
-
**Event processing**
-
@@ -345,11 +302,8 @@ You can use the following form to construct your own AppLocker planning document
-
-
**Policy maintenance**
-
@@ -392,20 +346,9 @@ You can use the following form to construct your own AppLocker planning document
-
-
### Additional resources
-
- The AppLocker Policies Design Guide is the predecessor to the AppLocker Policies Deployment Guide. When planning is complete, see the [AppLocker policies deployment guide](applocker-policies-deployment-guide.md).
-
- For more general info, see [AppLocker](applocker-overview.md).
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/create-your-applocker-policies.md b/windows/keep-secure/create-your-applocker-policies.md
index d08dbfd31a..cc275dc563 100644
--- a/windows/keep-secure/create-your-applocker-policies.md
+++ b/windows/keep-secure/create-your-applocker-policies.md
@@ -2,96 +2,45 @@
title: Create Your AppLocker policies (Windows 10)
description: This overview topic for the IT professional describes the steps to create an AppLocker policy and prepare it for deployment.
ms.assetid: d339dee2-4da2-4d4a-b46e-f1dfb7cb4bf0
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Create Your AppLocker policies
-
-
**Applies to**
-
- Windows 10
-
This overview topic for the IT professional describes the steps to create an AppLocker policy and prepare it for deployment.
-
Creating effective application control policies with AppLocker starts by creating the rules for each app. Rules are grouped into one of five rule collections. The rule collection can be configured to be enforced or to run in **Audit only** mode. An AppLocker policy includes the rules in the five rule collections and the enforcement settings for each rule collection.
-
## Step 1: Use your plan
-
-
You can develop an application control policy plan to guide you in making successful deployment decisions. For more info about how to do this and what you should consider, see the [AppLocker Design Guide](applocker-policies-design-guide.md). This guide is intended for security architects, security administrators, and system administrators. It contains the following topics to help you create an AppLocker policy deployment plan for your organization that will address your specific application control requirements by department, organizational unit, or business group:
-
1. [Understand the AppLocker policy deployment process](understand-the-applocker-policy-deployment-process.md)
-
2. [Understand AppLocker policy design decisions](understand-applocker-policy-design-decisions.md)
-
3. [Determine your application control objectives](determine-your-application-control-objectives.md)
-
4. [Create a list of apps deployed to each business group](create-list-of-applications-deployed-to-each-business-group.md)
-
5. [Select the types of rules to create](select-types-of-rules-to-create.md)
-
6. [Determine the Group Policy structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md)
-
7. [Plan for AppLocker policy management](plan-for-applocker-policy-management.md)
-
8. [Create your AppLocker planning document](create-your-applocker-planning-document.md)
-
## Step 2: Create your rules and rule collections
-
-
Each rule applies to one or more apps, and it imposes a specific rule condition on them. Rules can be created individually or they can be generated by the Automatically Generate Rules Wizard. For the steps to create the rules, see [Create Your AppLocker rules](create-your-applocker-rules.md).
-
## Step 3: Configure the enforcement setting
-
-
An AppLocker policy is a set of rule collections that are configured with a rule enforcement setting. The enforcement setting can be **Enforce rules**, **Audit only**, or **Not configured**. If an AppLocker policy has at least one rule, and it is set to **Not configured**, all the rules in that policy will be enforced. For info about configuring the rule enforcement setting, see [Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md) and [Configure an AppLocker policy for enforce rules](configure-an-applocker-policy-for-enforce-rules.md).
-
## Step 4: Update the GPO
-
-
AppLocker policies can be defined locally on a device or applied through Group Policy. To use Group Policy to apply AppLocker policies, you must create a new Group Policy Object (GPO) or you must update an existing GPO. You can create or modify AppLocker policies by using the Group Policy Management Console (GPMC), or you can import an AppLocker policy into a GPO. For the procedure to do this, see [Import an AppLocker policy into a GPO](import-an-applocker-policy-into-a-gpo.md).
-
## Step 5: Test the effect of the policy
-
-
In a test environment or with the enforcement setting set at **Audit only**, verify that the results of the policy are what you intended. For info about testing a policy, see [Test and update an AppLocker policy](test-and-update-an-applocker-policy.md).
-
## Step 6: Implement the policy
-
-
Depending on your deployment method, import the AppLocker policy to the GPO in your production environment, or if the policy is already deployed, change the enforcement setting to your production environment value—**Enforce rules** or **Audit only**.
-
## Step 7: Test the effect of the policy and adjust
-
-
Validate the effect of the policy by analyzing the AppLocker logs for application usage, and then modify the policy as necessary. To do this, see [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md).
-
## Next steps
-
-
Follow the steps described in the following topics to continue the deployment process:
-
1. [Create Your AppLocker rules](create-your-applocker-rules.md)
-
2. [Test and update an AppLocker policy](test-and-update-an-applocker-policy.md)
-
3. [Deploy the AppLocker policy into production](deploy-the-applocker-policy-into-production.md)
-
## See also
-
-
[AppLocker deployment guide](applocker-policies-deployment-guide.md)
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/create-your-applocker-rules.md b/windows/keep-secure/create-your-applocker-rules.md
index f1aa18a539..15de4246f0 100644
--- a/windows/keep-secure/create-your-applocker-rules.md
+++ b/windows/keep-secure/create-your-applocker-rules.md
@@ -2,107 +2,54 @@
title: Create Your AppLocker rules (Windows 10)
description: This topic for the IT professional describes what you need to know about AppLocker rules and the methods that you can to create rules.
ms.assetid: b684a3a5-929c-4f70-8742-04088022f232
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Create Your AppLocker rules
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional describes what you need to know about AppLocker rules and the methods that you can to create rules.
-
## Creating AppLocker rules
-
-
AppLocker rules apply to the targeted app, and they are the components that make up the AppLocker policy. Depending on your IT environment and the business group that requires application control policies, setting these access rules for each application can be time-consuming and prone to error. With AppLocker, you can generate rules automatically or create rules individually. Creating rules that are derived from your planning document can help you avoid unintended results. For info about this planning document and other planning activities, see [AppLocker Design Guide](applocker-policies-design-guide.md).
-
### Automatically generate your rules
-
You can use a reference device to automatically create a set of default rules for each of the installed apps, test and modify each rule as necessary, and deploy the policies. Creating most of the rules for all the installed apps gives you a starting point to build and test your policies. For info about performing this task, see the following topics:
-
- [Configure the AppLocker reference device](configure-the-appLocker-reference-device.md)
-
- [Run the Automatically Generate Rules wizard](run-the-automatically-generate-rules-wizard.md)
-
- [Create AppLocker default rules](create-applocker-default-rules.md)
-
- [Edit AppLocker rules](edit-applocker-rules.md)
-
- [Add exceptions for an AppLocker rule](configure-exceptions-for-an-applocker-rule.md)
-
### Create your rules individually
-
You can create rules and set the mode to **Audit only** for each installed app, test and update each rule as necessary, and then deploy the policies. Creating rules individually might be best when you are targeting a small number of applications within a business group.
-
**Note**
AppLocker includes default rules for each rule collection. These rules are intended to help ensure that the files that are required for Windows to operate properly are allowed in an AppLocker rule collection. You can also edit the default rules. For information about creating the default rules for the Windows operating system, see [Create AppLocker default rules](create-applocker-default-rules.md).
-
-
For information about performing this task, see:
-
1. [Create a rule that uses a publisher condition](create-a-rule-that-uses-a-publisher-condition.md)
-
2. [Create a rule that uses a path condition](create-a-rule-that-uses-a-path-condition.md)
-
3. [Create a rule that uses a file hash condition](create-a-rule-that-uses-a-file-hash-condition.md)
-
4. [Edit AppLocker rules](edit-applocker-rules.md)
-
5. [Enforce AppLocker rules](enforce-applocker-rules.md)
-
6. [Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md)
-
## About selecting rules
-
-
AppLocker policies are composed of distinct rules for specific apps. These rules are grouped by collection, and they are implemented through an AppLocker policy definition. AppLocker policies are managed by using Group Policy or by using the Local Security Policy snap-in for a single computer.
-
When you determine what types of rules to create for each of your business groups or organizational units (OUs), you should also determine what enforcement setting to use for each group. Certain rule types are more applicable for some apps, depending on how the apps are deployed in a specific business group.
-
For info about how to determine and document your AppLocker rules, see [AppLocker Design Guide](applocker-policies-design-guide.md).
-
For info about AppLocker rules and AppLocker policies, see the following topics:
-
- [Understanding AppLocker rule behavior](understanding-applocker-rule-behavior.md)
-
- [Understanding AppLocker rule exceptions](understanding-applocker-rule-exceptions.md)
-
- [Understanding AppLocker rule collections](understanding-applocker-rule-collections.md)
-
- [Understanding AppLocker allow and deny actions on rules](understanding-applocker-allow-and-deny-actions-on-rules.md)
-
- [Understanding AppLocker rule condition types](understanding-applocker-rule-condition-types.md)
-
- [Understanding AppLocker default rules](understanding-applocker-default-rules.md)
-
## Next steps
-
-
1. [Import an AppLocker policy into a GPO](import-an-applocker-policy-into-a-gpo.md)
-
2. [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md)
-
3. [Test and update an AppLocker policy](test-and-update-an-applocker-policy.md)
-
4. [Deploy the AppLocker policy into production](deploy-the-applocker-policy-into-production.md)
-
## Related topics
-
-
[Create Your AppLocker policies](create-your-applocker-policies.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/creating-a-device-guard-policy-for-signed-apps.md b/windows/keep-secure/creating-a-device-guard-policy-for-signed-apps.md
index b0079da964..ee2f72275b 100644
--- a/windows/keep-secure/creating-a-device-guard-policy-for-signed-apps.md
+++ b/windows/keep-secure/creating-a-device-guard-policy-for-signed-apps.md
@@ -5,47 +5,35 @@ ms.assetid: 6C94B14E-E2CE-4F6C-8939-4B375406E825
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Create a Device Guard code integrity policy based on a reference device
-
-
**Applies to**
-
- Windows 10
To implement Device Guard app protection, you will need to create a code integrity policy. Code integrity policies determine what apps are considered trustworthy and are allowed to run on a protected device.
## Create a Device Guard code integrity policy based on a reference device
-
To create a code integrity policy, you'll first need to create a reference image that includes the signed applications you want to run on your protected devices. For information on how to sign applications, see [Getting apps to run on Device Guard-protected devices](getting-apps-to-run-on-device-guard-protected-devices.md).
-
-**Note** Before creating a code integrity policy, make sure your reference device is clean of viruses and malware.
-
+> **Note:** Before creating a code integrity policy, make sure your reference device is clean of viruses and malware.
-
**To create a code integrity policy based on a reference device**
1. On your reference device, start PowerShell as an administrator.
-
2. In PowerShell, initialize variables by typing:
-
``` syntax
$CIPolicyPath=$env:userprofile+"\Desktop\"
$InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"
$CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"
```
-
3. Scan your device for installed applications and create a new code integrity policy by typing:
-
``` syntax
New-CIPolicy -Level -FilePath $InitialCIPolicy -UserPEs -Fallback Hash 3> Warningslog.txt
```
-
Where *<RuleLevel>* can be set to any of the following options:
-
@@ -110,31 +98,15 @@ To create a code integrity policy, you'll first need to create a reference image
-
-
4. Type the following to convert the code integrity policy to a binary format:
-
``` syntax
ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin
```
-
Once you have completed these steps, the Device Guard policy binary file (DeviceGuardPolicy.bin) and original xml file (InitialScan.xml) will be available on your desktop.
-
-**Note** We recommend that you keep a copy of InitialScan.xml to use if you need to merge this code integrity policy with another policy, or update policy rule options.
-
+>**Note:** We recommend that you keep a copy of InitialScan.xml to use if you need to merge this code integrity policy with another policy, or update policy rule options.
-
## Related topics
-
-
[Getting apps to run on Device Guard-protected devices](getting-apps-to-run-on-device-guard-protected-devices.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/credential-guard.md b/windows/keep-secure/credential-guard.md
index 387655a9a5..cd7d9d5707 100644
--- a/windows/keep-secure/credential-guard.md
+++ b/windows/keep-secure/credential-guard.md
@@ -5,14 +5,12 @@ ms.assetid: 4F1FE390-A166-4A24-8530-EA3369FEB4B1
ms.prod: W10
ms.mktglfcycl: explore
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
-
# Protect derived domain credentials with Credential Guard
-
**Applies to**
-
- Windows 10
- Windows Server 2016 Technical Preview
@@ -21,34 +19,27 @@ Introduced in Windows 10 Enterprise, Credential Guard uses virtualization-based
Credential Guard offers the following features and solutions:
- **Hardware security** Credential Guard increases the security of derived domain credentials by taking advantage of platform security features including, Secure Boot and virtualization.
-
- **Virtualization-based security** Windows services that manage derived domain credentials and other secrets run in a protected environment that is isolated from the running operating system.
-
- **Better protection against advanced persistent threats** Securing derived domain credentials using the virtualization-based security blocks the credential theft attack techniques and tools used in many targeted attacks. Malware running in the operating system with administrative privileges cannot extract secrets that are protected by virtualization-based security. While Credential Guard is a powerful mitigation, persistent threat attacks will likely shift to new attack techniques and you should also incorporate Device Guard and other security strategies and architectures.
-
- **Manageability** You can manage Credential Guard by using Group Policy, WMI, from a command prompt, and Windows PowerShell.
## How it works
-
-Credential Guard isolates secrets that previous versions of Windows stored in the Local Security Authority (LSA) by using virtualization-based security. Prior to Windows 10, the LSA stored secrets used by the operating system in its process memory. With Credential Guard, the LSA process in the operating system talks to a new component called the isolated LSA process that stores and protects those secrets. Data stored by the isolated LSA process is protected using virtualization-based security and is not accessible to the rest of the operating system. LSA uses remote procedure calls to communicate with the isolated LSA process
+Credential Guard isolates secrets that previous versions of Windows stored in the Local Security Authority (LSA) by using virtualization-based security. Prior to Windows 10, the LSA stored secrets used by the operating system in its process memory. With Credential Guard, the LSA process in the operating system talks to a new component called the isolated LSA process that stores and protects those secrets. Data stored by the isolated LSA process is protected using virtualization-based security and is not accessible to the rest of the operating system. LSA uses remote procedure calls to communicate with the isolated LSA process.
For security reasons, the isolated LSA process doesn't host any device drivers. Instead, it only hosts a small subset of operating system binaries that are needed for security and nothing else. All of these binaries are signed with a certificate that is trusted by virtualization-based security and these signatures are validated before launching the file in the protected environment.
Credential Guard also does not allow older variants of NTLM, unconstrained Kerberos delegation, and Kerberos authentication protocols and cipher suites when using default derived credentials, including NTLMv1, MS-CHAPv2, and weaker Kerberos encryption types, such as DES.
-
Here's a high-level overview on how the LSA is isolated by using virtualization-based security:
-
+
## New and changed functionality
-
To see what was added or changed in Credential Guard, see [What's new in Credential Guard?](../whats-new/credential-guard.md).
## Hardware and software requirements
-
The PC must meet the following hardware and software requirements to use Credential Guard:
@@ -105,13 +96,11 @@ The PC must meet the following hardware and software requirements to use Credent
Note If you don't have a TPM installed, Credential Guard will still be enabled, but the keys used to encrypt Credential Guard will not be protected by the TPM.
-
-
-
+
Secure firmware update process |
-To verify that the firmware complies with the secure firmware update process, you can validate it against the [System.Fundamentals.Firmware.UEFISecureBoot](http://msdn.microsoft.com/library/windows/hardware/dn932805.aspx#system-fundamentals-firmware-uefisecureboot) Windows Hardware Compatibility Program requirement. |
+To verify that the firmware complies with the secure firmware update process, you can validate it against the [System.Fundamentals.Firmware.UEFISecureBoot](http://msdn.microsoft.com/library/windows/hardware/dn932805.aspx#system-fundamentals-firmware-uefisecureboot) Windows Hardware Compatibility Program requirement. Credential Guard relies on the security of the underlying hardware and firmware. It is critical to keep the firmware updated with the latest security fixes. |
The firmware is updated for [Secure MOR implementation](http://msdn.microsoft.com/library/windows/hardware/mt270973.aspx) |
@@ -123,30 +112,23 @@ The PC must meet the following hardware and software requirements to use Credent
-
-
¹ If you choose the **Secure Boot and DMA protection** option in the Group Policy setting, an IOMMU is required. The **Secure Boot** Group Policy option enables Credential Guard on devices without an IOMMU.
## Manage Credential Guard
-
Credential Guard uses virtualization-based security features that must be enabled on each PC before you can use it.
### Turn on Credential Guard by using Group Policy
You can use Group Policy to enable Credential Guard because it will add the virtualization-based security features for you.
-
1. From the Group Policy Management Console, go to **Computer Configuration** -> **Administrative Templates** -> **System** -> **Device Guard**.
-
2. Double-click **Turn On Virtualization Based Security**, and then click the **Enabled** option.
-
3. **Select Platform Security Level** box, choose **Secure Boot** or **Secure Boot and DMA Protection**.
-
4. In the **Credential Guard Configuration** box, click **Enabled with UEFI lock**, and then click **OK**. If you want to be able to turn off Credential Guard remotely, choose **Enabled without lock**.
- 
-
+ 
+
5. Close the Group Policy Management Console.
### Add Credential Guard to an image
@@ -156,44 +138,27 @@ If you would like to add Credential Guard to an image, you can do this by adding
### Add the virtualization-based security features
First, you must add the virtualization-based security features. You can do this by using either the Control Panel or the Deployment Image Servicing and Management tool (DISM).
-
-**Note** If you enable Credential Guard by using Group Policy, these steps are not required. Group Policy will install the features for you.
-
+> **Note:** If you enable Credential Guard by using Group Policy, these steps are not required. Group Policy will install the features for you.
-
**Add the virtualization-based security features by using Programs and Features**
-
1. Open the Programs and Features control panel.
-
2. Click **Turn Windows feature on or off**.
-
3. Select the **Isolated User Mode** check box.
-
4. Go to **Hyper-V** -> **Hyper-V Platform**, and then select the **Hyper-V Hypervisor** check box.
-
5. Click **OK**.
**Add the virtualization-based security features to an offline image by using DISM**
-
1. Open an elevated command prompt.
-
2. Add the Hyper-V Hypervisor by running the following command:
-
``` syntax
dism /image: /Enable-Feature /FeatureName:Microsoft-Hyper-V-Hypervisor /all
```
-
3. Add Isolated User Mode by running the following command:
-
``` syntax
dism /image: /Enable-Feature /FeatureName:IsolatedUserMode
```
-
-**Note**
-You can also add these features to an online image by using either DISM or Configuration Manager.
-
+> **Note:** You can also add these features to an online image by using either DISM or Configuration Manager.
-
### Turn on Credential Guard
If you don't use Group Policy, you can enable Credential Guard by using the registry.
@@ -201,42 +166,28 @@ If you don't use Group Policy, you can enable Credential Guard by using the regi
**Turn on Credential Guard by using the registry**
1. Open Registry Editor.
-
2. Enable virtualization-based security:
-
- Go to HKEY\_LOCAL\_MACHINE\\System\\CurrentControlSet\\Control\\DeviceGuard.
-
- Add a new DWORD value named **EnableVirtualizationBasedSecurity**. Set the value of this registry setting to 1 to enable virtualization-based security and set it to 0 to disable it.
-
- Add a new DWORD value named **RequirePlatformSecurityFeatures**. Set the value of this registry setting to 1 to use **Secure Boot** only or set it to 2 to use **Secure Boot and DMA protection**.
-
3. Enable Credential Guard:
-
- Go to HKEY\_LOCAL\_MACHINE\\System\\CurrentControlSet\\Control\\LSA.
-
- Add a new DWORD value named **LsaCfgFlags**. Set the value of this registry setting to 1 to enable Credential Guard with UEFI lock, set it to 2 to enable Credential Guard without lock, and set it to 0 to disable it.
-
4. Close Registry Editor.
-**Note**
-You can also turn on Credential Guard by setting the registry entries in the [FirstLogonCommands](http://msdn.microsoft.com/library/windows/hardware/dn922797.aspx) unattend setting.
-
+> **Note:** You can also turn on Credential Guard by setting the registry entries in the [FirstLogonCommands](http://msdn.microsoft.com/library/windows/hardware/dn922797.aspx) unattend setting.
-
### Remove Credential Guard
If you have to remove Credential Guard on a PC, you need to do the following:
1. If you used Group Policy, disable the Group Policy setting that you used to enable Credential Guard (**Computer Configuration** -> **Administrative Templates** -> **System** -> **Device Guard** -> **Turn on Virtualization Based Security**).
-
2. Delete the following registry setting: HKEY\_LOCAL\_MACHINE\\Software\\Policies\\Microsoft\\Windows\\DeviceGuard\\LsaCfgFlags
-
3. Delete the Credential Guard EFI variables by using bcdedit.
**Delete the Credential Guard EFI variables**
1. From an elevated command prompt, type the following commands:
-
``` syntax
mountvol X: /s
copy %WINDIR%\System32\SecConfig.efi X:\EFI\Microsoft\Boot\SecConfig.efi /Y
@@ -247,97 +198,61 @@ If you have to remove Credential Guard on a PC, you need to do the following:
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} device partition=X:
mountvol X: /d
```
-
2. Restart the PC.
-
3. Accept the prompt to disable Credential Guard.
-
4. Alternatively, you can disable the virtualization-based security features to turn off Credential Guard.
-**Note**
-The PC must have one-time access to a domain controller to decrypt content, such as files that were encrypted with EFS.
-
-If you want to turn off both Credential Guard and virtualization-based security, run the following bcdedit command after turning off all virtualization-based security Group Policy and registry settings:
-
-**bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO,DISABLE-VBS**
+> **Note: ** The PC must have one-time access to a domain controller to decrypt content, such as files that were encrypted with EFS. If you want to turn off both Credential Guard and virtualization-based security, run the following bcdedit command after turning off all virtualization-based security Group Policy and registry settings: bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO,DISABLE-VBS
For more info on virtualization-based security and Device Guard, see [Device Guard deployment guide](device-guard-deployment-guide.md).
-
-
### Check that Credential Guard is running
You can use System Information to ensure that Credential Guard is running on a PC.
1. Click **Start**, type **msinfo32.exe**, and then click **System Information**.
-
2. Click **System Summary**.
-
3. Confirm that **Credential Guard** is shown next to **Device Guard Security Services Running**.
Here's an example:
-
- 
-
+
+ 
+
## Considerations when using Credential Guard
-
- If Credential Guard is enabled on a device after it's joined to a domain, the user and device secrets may already be compromised. We recommend that Credential Guard is enabled before the PC is joined to a domain.
-
- You should perform regular reviews of the PCs that have Credential Guard enabled. This can be done with security audit policies or WMI queries. Here's a list of WinInit event IDs to look for:
-
- **Event ID 13** Credential Guard (LsaIso.exe) was started and will protect LSA credentials.
-
- **Event ID 14** Credential Guard (LsaIso.exe) configuration: 0x1, 0
-
- The first variable: 0x1 means Credential Guard is configured to run. 0x0 means it’s not configured to run.
- The second variable: 0 means it’s configured to run in protect mode. 1 means it's configured to run in test mode. This variable should always be 0.
- **Event ID 15** Credential Guard (LsaIso.exe) is configured but the secure kernel is not running; continuing without Credential Guard.
-
- **Event ID 16** Credential Guard (LsaIso.exe) failed to launch: \[error code\]
-
- **Event ID 17** Error reading Credential Guard (LsaIso.exe) UEFI configuration: \[error code\]
-
You can also verify that TPM is being used for key protection by checking the following event in the **Microsoft** -> **Windows** -> **Kernel-Boot** event source. If you are running with a TPM, the TPM PCR mask value will be something other than 0.
-
- **Event ID 51** VSM Master Encryption Key Provisioning. Using cached copy status: 0x0. Unsealing cached copy status: 0x1. New key generation status: 0x1. Sealing status: 0x1. TPM PCR mask: 0x0.
-
- Passwords are still weak so we recommend that your organization deploy Credential Guard and move away from passwords and to other authentication methods, such as physical smart cards, virtual smart cards, Microsoft Passport, or Microsoft Passport for Work.
-
- Some 3rd party Security Support Providers (SSPs and APs) might not be compatible with Credential Guard. Credential Guard does not allow 3rd party SSPs to ask for password hashes from LSA. However, SSPs and APs still get notified of the password when a user logs on and/or changes their password. Any use of undocumented APIs within custom SSPs and APs are not supported. We recommend that custom implementations of SSPs/APs are tested against Credential Guard to ensure that the SSPs and APs do not depend on any undocumented or unsupported behaviors. For example, using the KerbQuerySupplementalCredentialsMessage API is not supported. You should not replace the NTLM or Kerberos SSPs with custom SSPs and APs. For more info, see [Restrictions around Registering and Installing a Security Package](http://msdn.microsoft.com/library/windows/desktop/dn865014.aspx) on MSDN.
-
- As the depth and breadth of protections provided by Credential Guard are increased, subsequent releases of Windows 10 with Credential Guard running may impact scenarios that were working in the past. For example, Credential Guard may block the use of a particular type of credential or a particular component to prevent malware from taking advantage of vulnerabilities. Therefore, we recommend that scenarios required for operations in an organization are tested before upgrading a device that has Credential Guard running.
-
- If you are using Wi-Fi and VPN end points that are based on MS-CHAPv2, they are subject to similar attacks as NTLMv1. We recommend that organizations use certificated-based authentication for Wi-Fi and VPN connections.
-
- Starting with Windows 10, version 1511, domain credentials that are stored with Credential Manager are protected with Credential Guard. Credential Manager allows you to store credentials, such as user names and passwords that you use to log on to websites or other computers on a network. The following considerations apply to the Credential Guard protections for Credential Manager:
-
- Credentials saved by Remote Desktop Services cannot be used to remotely connect to another machine without supplying the password.
-
- Applications that extract derived domain credentials from Credential Manager will no longer be able to use those credentials.
-
- You cannot restore credentials using the Credential Manager control panel if the credentials were backed up from a PC that has Credential Guard turned on. If you need to back up your credentials, you must do this before you enable Credential Guard. Otherwise, you won't be able to restore those credentials.
-
+
## Scenarios not protected by Credential Guard
-
Some ways to store credentials are not protected by Credential Guard, including:
- Software that manages credentials outside of Windows feature protection
-
- Local accounts and Microsoft Accounts
-
- Credential Guard does not protect the Active Directory database running on Windows Server 2016 Technical Preview domain controllers. It also does not protect credential input pipelines, such as Windows Server 2016 Technical Preview servers running Remote Desktop Gateway. If you're using a Windows Server 2016 Technical Preview server as a client PC, it will get the same protection as it would be running Windows 10 Enterprise.
-
- Key loggers
-
- Physical attacks
-
- Does not prevent an attacker with malware on the PC from using the privileges associated with any credential. We recommend using dedicated PCs for high value accounts, such as IT Pros and users with access high value assets in your organization.
## Additional mitigations
-
Credential Guard can provide mitigations against attacks on derived credentials and prevent the use of stolen credentials elsewhere. However, PCs can still be vulnerable to certain attacks, even if the derived credentials are protected by Credential Guard. These attacks can include abusing privileges and use of derived credentials directly from a compromised device, reusing previously stolen credentials prior to Device Guard, and abuse of management tools and weak application configurations. Because of this, additional mitigations also need to be deployed to make the domain environment more robust.
Credential theft attacks allow the attacker to steal secrets from one device and use them from another device. By deploying authentication policies with compound authentication in Windows Server 2012 R2 or later domains, users can be restricted to only sign on from specific domain-joined devices. However, since devices also use shared secrets for authentication, attackers can steal those secrets as well. By deploying device certificates with Credential Guard, authentication policies can require that the device authenticates with its private key. This prevents shared secrets on stolen devices to be used with stolen user passwords or Kerberos secret keys to sign on as the user.
@@ -345,9 +260,7 @@ Credential theft attacks allow the attacker to steal secrets from one device and
Device certificate authentication has the following requirements:
- Device domains are Windows Server 2012 or higher and all domain controllers have certificates, which satisfy strict KDC validation (KDC EKU present and the DNS domain name matches the DNSName field of the SubjectAltName (SAN) extension).
-
- Windows 10 devices have the CA issuing the domain controller certificates in the enterprise store.
-
- A process is established to ensure the identity and trustworthiness of the device in a similar manner as you would establish the identity and trustworthiness of a user before issuing them a smartcard.
### Additional Group Policy settings
@@ -355,80 +268,53 @@ Device certificate authentication has the following requirements:
There are a few Group Policy settings that you can enable that provide more protection against credential attacks:
- On the domain controllers, configure the KDC support for claims, compound authentication, and Kerberos armoring system by using Group Policy. Set the **KDC support for claims, compound authentication, and Kerberos armoring** Group Policy setting to either **Supported** or **Always provide claims**.
-
- On devices running Windows 10, you can turn it on by using Group Policy as well. To do this, enable the **Kerberos client support for claims, compound authentication and Kerberos armoring** & **Always send compound authentication first system** Group Policy settings under **Computer Configuration** -> **Administrative Templates** -> **System** -> **Kerberos**.
### Compound authentication
Compound authentication adds the device identity to the user’s during authentication to the domain and resources. Without compound authentication, only the user’s secrets are validated. With compound authentication, the Kerberos client has to have both the user’s and device’s secrets.
-
Enabling compound authentication also enables Kerberos armoring, which provides two additional benefits:
- User authentication on domain-joined devices will be armored. This means that network captures will contain encrypted Kerberos initial authentication. Without the appropriate device key, Kerberos AS-REQs are protected against offline dictionary attacks.
-
- KDC errors are signed, which provides protection against error spoofing attacks.
### Deploying machine certificates
If the domain controllers in your organization are running Windows Server 2016 Technical Preview, devices running Windows 10 will automatically enroll a machine certificate when Credential Guard is enabled and the PC is joined to the domain.
-
If the domain controllers are running Windows Server 2012 R2, the machine certificates must be provisioned manually on each device. You can do this by creating a certificate template on the domain controller or certificate authority and deploying the machine certificates to each device.
-
The same security procedures used for issuing smart cards to users should be applied to machine certificates.
1. From the Certificate Manager console, right-click **Certificate Templates**, and then click **Manage.**
-
2. Right-click **Workstation Authentication**, and then click **Duplicate Template**.
-
3. Right-click the new template, and then click **Properties**.
-
4. On the **Extensions** tab, click **Application Policies**, and then click **Edit**.
-
5. Click **Client Authentication**, and then click **Remove**.
-
6. Add the ID-PKInit-KPClientAuth EKU. Click **Add**, click **New**, and then specify the following values:
-
- Name: Kerberos Client Auth
-
- Object Identifier: 1.3.6.1.5.2.3.4
-
7. On the **Extensions** tab, click **Issuance Policies**, and then click **Edit**.
-
8. Under **Issuance Policies**, click**High Assurance**.
-
9. On the **Subject name** tab, clear the **DNS name** check box, and then select the **User Principal Name (UPN)** check box.
On devices that are running Credential Guard, enroll the devices using the machine authentication certificate by running the following command:
-
``` syntax
CertReq -EnrollCredGuardCert MachineAuthentication
```
-
-**Note**
-You must restart the device after enrolling the machine authentication certificate.
-
+> **Note:** You must restart the device after enrolling the machine authentication certificate.
-
### Link the issuance policies to a group
By using an authentication policy, you can ensure that users only sign into devices that are running Credential Guard. Before you deploy the authentication policy though, you must first run a couple of scripts that set up your environment.
-
- The [get-IssuancePolicy.ps1](#bkmk-getscript) shows all of the issuance policies that are available on the certificate authority.
-
From a Windows PowerShell command prompt, run the following command:
-
``` syntax
.\get-IssuancePolicy.ps1 –LinkedToGroup:All
```
-
- The [set-IssuancePolicyToGroupLink.ps1](#bkmk-setscript) creates a Universal security group, creates an organizational unit, and links the issuance policy to that Universal security group.
-
From a Windows PowerShell command prompt, run the following command:
-
``` syntax
.\set-IssuancePolicyToGroupLink.ps1 –IssuancePolicyName:”” –groupOU:”” –groupName:””
```
-
### Deploy the authentication policy
Before setting up the authentication policy, you should log any failed attempt to apply an authentication policy on the KDC. To do this in Event Viewer, navigate to **Applications and Services Logs\\Microsoft\\Windows\\Authentication, right-click AuthenticationPolicyFailures-DomainController**, and then click **Enable Log**.
@@ -438,45 +324,28 @@ Now you can set up an authentication policy to use Credential Guard.
**To add an authentication policy for Credential Guard**
1. Ensure that your domain controllers are running at least the Windows Server 2012 R2 domain functional level.
-
2. Create a security group that will be used to identify the PCs that will have this authentication policy applied to them.
-
3. Add the computer account to this security group.
-
4. Open Active Directory Administrative Center.
-
5. Click **Authentication**, click **New**, and then click **Authentication Policy**.
-
6. In the **Display name** box, enter a name for this authentication policy.
-
7. Under the **Accounts** heading, click **Add**.
-
8. In the **Select Users, Computers, or Service Accounts** dialog box, type the name of the user account, and then click **OK**.
-
9. Under the **User** heading, click the **Edit** button that applies to user account.
-
10. Click **Add a condition**.
-
11. In the **Edit Access Control Conditions** box, ensure that it reads **User** > **Group** > **Member of each** > **Value**, and then click **Add items**.
-
12. In the **Select Users, Computers, or Service Accounts** dialog box, type the name of the security group that you created with the set-IssuancePolicyToGroupLink script, and then click **OK**.
-
13. Click **OK** to close the **Edit Access Control Conditions** box.
-
14. Click **OK** to create the authentication policy.
-
15. Close Active Directory Administrative Center.
-**Note**
-When authentication policies in enforcement mode are deployed with Credential Guard, users will not be able to sign in using devices that do not have the machine authentication certificate provisioned. This applies to both local and remote sign in scenarios.
-
+> **Note:** When authentication policies in enforcement mode are deployed with Credential Guard, users will not be able to sign in using devices that do not have the machine authentication certificate provisioned. This applies to both local and remote sign in scenarios.
-
### Appendix: Scripts
Here is a list of scripts that are mentioned in this topic.
-### Get the available issuance policies on the certificate authority
+#### Get the available issuance policies on the certificate authority
Save this script file as get-IssuancePolicy.ps1.
@@ -485,12 +354,10 @@ Save this script file as get-IssuancePolicy.ps1.
## Parameters to be defined ##
## by the user ##
#######################################
-
Param (
$Identity,
$LinkedToGroup
)
-
#######################################
## Strings definitions ##
#######################################
@@ -521,19 +388,12 @@ dn = distinguishedName : {0}
NonLinkedIPs = The following Issuance Policies are NOT linked to groups:
'@
}
-
##Import-LocalizedData getIP_strings
-
-
import-module ActiveDirectory
-
-
#######################################
## Help ##
#######################################
-
function Display-Help {
-
""
$getIP_strings.help1
""
@@ -557,34 +417,25 @@ $getIP_strings.help11
" " + '$' + "myIP = .\get-IssuancePolicy.ps1 -Identity:""Medium Assurance"""
""
}
-
-
$root = get-adrootdse
$domain = get-addomain -current loggedonuser
$configNCDN = [String]$root.configurationNamingContext
-
-
if ( !($Identity) -and !($LinkedToGroup) ) {
display-Help
break
}
-
if ($Identity) {
$OIDs = get-adobject -Filter {(objectclass -eq "msPKI-Enterprise-Oid") -and ((name -eq $Identity) -or (displayname -eq $Identity) -or (distinguishedName -like $Identity)) } -searchBase $configNCDN -properties *
-
if ($OIDs -eq $null) {
$errormsg = $getIP_strings.ErrorIPNotFound -f $Identity
write-host $errormsg -ForegroundColor Red
}
-
foreach ($OID in $OIDs) {
-
if ($OID."msDS-OIDToGroupLink") {
# In case the Issuance Policy is linked to a group, it is good to check whether there is any problem with the mapping.
$groupDN = $OID."msDS-OIDToGroupLink"
$group = get-adgroup -Identity $groupDN
$groupName = $group.Name
-
# Analyze the group
if ($group.groupCategory -ne "Security") {
$errormsg = $getIP_strings.ErrorNotSecurity -f $Identity, $groupName
@@ -603,16 +454,13 @@ write-host $errormsg -ForegroundColor Red
}
}
}
-
}
return $OIDs
break
}
-
if (($LinkedToGroup -eq "yes") -or ($LinkedToGroup -eq "all")) {
$LDAPFilter = "(&(objectClass=msPKI-Enterprise-Oid)(msDS-OIDToGroupLink=*)(flags=2))"
$LinkedOIDs = get-adobject -searchBase $configNCDN -LDAPFilter $LDAPFilter -properties *
-
write-host ""
write-host "*****************************************************"
write-host $getIP_strings.LinkedIPs
@@ -620,20 +468,16 @@ if (($LinkedToGroup -eq "yes") -or ($LinkedToGroup -eq "all")) {
write-host ""
if ($LinkedOIDs -ne $null){
foreach ($OID in $LinkedOIDs) {
-
# Display basic information about the Issuance Policies
""
$getIP_strings.displayName -f $OID.displayName
$getIP_strings.Name -f $OID.Name
$getIP_strings.dn -f $OID.distinguishedName
-
-
# Get the linked group.
$groupDN = $OID."msDS-OIDToGroupLink"
$group = get-adgroup -Identity $groupDN
$getIP_strings.InfoName -f $group.Name
$getIP_strings.InfoDN -f $groupDN
-
# Analyze the group
$OIDName = $OID.displayName
$groupName = $group.Name
@@ -663,11 +507,9 @@ write-host "There are no issuance policies that are mapped to a group"
break
}
}
-
if (($LinkedToGroup -eq "no") -or ($LinkedToGroup -eq "all")) {
$LDAPFilter = "(&(objectClass=msPKI-Enterprise-Oid)(!(msDS-OIDToGroupLink=*))(flags=2))"
$NonLinkedOIDs = get-adobject -searchBase $configNCDN -LDAPFilter $LDAPFilter -properties *
-
write-host ""
write-host "*********************************************************"
write-host $getIP_strings.NonLinkedIPs
@@ -675,7 +517,6 @@ if (($LinkedToGroup -eq "no") -or ($LinkedToGroup -eq "all")) {
write-host ""
if ($NonLinkedOIDs -ne $null) {
foreach ($OID in $NonLinkedOIDs) {
-
# Display basic information about the Issuance Policies
write-host ""
$getIP_strings.displayName -f $OID.displayName
@@ -692,13 +533,9 @@ write-host "There are no issuance policies which are not mapped to groups"
}
}
```
-
-**Note**
-If you're having trouble running this script, try replacing the single quote after the ConvertFrom-StringData parameter.
-
+> **Note:** If you're having trouble running this script, try replacing the single quote after the ConvertFrom-StringData parameter.
-
-### Link an issuance policy to a group
+#### Link an issuance policy to a group
Save the script file as set-IssuancePolicyToGroupLink.ps1.
@@ -707,17 +544,14 @@ Save the script file as set-IssuancePolicyToGroupLink.ps1.
## Parameters to be defined ##
## by the user ##
#######################################
-
Param (
$IssuancePolicyName,
$groupOU,
$groupName
)
-
#######################################
## Strings definitions ##
#######################################
-
Data ErrorMsg {
# culture="en-US"
ConvertFrom-StringData -stringdata @'
@@ -758,9 +592,7 @@ LinkError = The certificate issuance policy could not be linked to the specified
ExitNoLinkReplacement = Exiting without setting the new link.
'@
}
-
# import-localizeddata ErrorMsg
-
function Display-Help {
""
write-host $ErrorMsg.help1
@@ -784,30 +616,22 @@ write-host $ErrorMsg.help10
'.\Set-IssuancePolicyToGroupMapping.ps1 -IssuancePolicyName "402.164959C40F4A5C12C6302E31D5476062" -groupName $null '
""
}
-
-
-
# Assumption: The group to which the Issuance Policy is going
# to be linked is (or is going to be created) in
# the domain the user running this script is a member of.
import-module ActiveDirectory
$root = get-adrootdse
$domain = get-addomain -current loggedonuser
-
-
if ( !($IssuancePolicyName) ) {
display-Help
break
}
-
#######################################
## Find the OID object ##
## (aka Issuance Policy) ##
#######################################
-
$searchBase = [String]$root.configurationnamingcontext
$OID = get-adobject -searchBase $searchBase -Filter { ((displayname -eq $IssuancePolicyName) -or (name -eq $IssuancePolicyName)) -and (objectClass -eq "msPKI-Enterprise-Oid")} -properties *
-
if ($OID -eq $null) {
$tmp = $ErrorMsg.NoIP -f $IssuancePolicyName, $searchBase
write-host $tmp -ForeGroundColor Red
@@ -822,13 +646,9 @@ else {
$tmp = $ErrorMsg.IPFound -f $IssuancePolicyName, $OID.distinguishedName
write-host $tmp -ForeGroundColor Green
}
-
-
-
#######################################
## Find the container of the group ##
#######################################
-
if ($groupOU -eq $null) {
# default to the Users container
$groupContainer = $domain.UsersContainer
@@ -867,11 +687,9 @@ $tmp = $ErrorMsg.OUFoundSuccess -f $groupContainer.name
write-host $tmp -ForegroundColor Green
}
}
-
#######################################
## Find the group ##
#######################################
-
if (($groupName -ne $null) -and ($groupName -ne "")){
##$searchBase = [String]$groupContainer.DistinguishedName
$searchBase = $groupContainer
@@ -936,14 +754,11 @@ write-host $tmp -ForeGroundColor Yellow
}
break;
}
-
-
#######################################
## Verify that the group is ##
## Universal, Security, and ##
## has no members ##
#######################################
-
if ($group.GroupScope -ne "Universal") {
$tmp = $ErrorMsg.ErrorNotUniversal -f $IssuancePolicyName, $groupName
write-host $tmp -ForeGroundColor Red
@@ -961,14 +776,11 @@ write-host $tmp -ForeGroundColor Red
foreach ($member in $members) {write-host " $member.name" -ForeGroundColor Red}
break;
}
-
-
#######################################
## We have verified everything. We ##
## can create the link from the ##
## Issuance Policy to the group. ##
#######################################
-
if ($OID."msDS-OIDToGroupLink" -ne $null) {
$tmp = $ErrorMsg.ConfirmLinkReplacement -f $IssuancePolicyName, $OID."msDS-OIDToGroupLink", $group.distinguishedName
write-host $tmp "( (y)es / (n)o )" -ForegroundColor Yellow -nonewline
@@ -1002,30 +814,17 @@ write-host $tmp -Foreground Red
}
```
-**Note**
-If you're having trouble running this script, try replacing the single quote after the ConvertFrom-StringData parameter.
-
+> **Note:** If you're having trouble running this script, try replacing the single quote after the ConvertFrom-StringData parameter.
-
## Related topics
-
-[Isolated User Mode in Windows 10 with Dave Probert (Channel 9)](https://channel9.msdn.com/Blogs/Seth-Juarez/Isolated-User-Mode-in-Windows-10-with-Dave-Probert)
-
-[Isolated User Mode Processes and Features in Windows 10 with Logan Gabriel (Channel 9)](http://channel9.msdn.com/Blogs/Seth-Juarez/Isolated-User-Mode-Processes-and-Features-in-Windows-10-with-Logan-Gabriel)
-
-[More on Processes and Features in Windows 10 Isolated User Mode with Dave Probert (Channel 9)](https://channel9.msdn.com/Blogs/Seth-Juarez/More-on-Processes-and-Features-in-Windows-10-Isolated-User-Mode-with-Dave-Probert)
-
-[Mitigating Credential Theft using the Windows 10 Isolated User Mode (Channel 9)](https://channel9.msdn.com/Blogs/Seth-Juarez/Mitigating-Credential-Theft-using-the-Windows-10-Isolated-User-Mode)
-
-[Enabling Strict KDC Validation in Windows Kerberos](http://www.microsoft.com/download/details.aspx?id=6382)
-
-[What's New in Kerberos Authentication for Windows Server 2012](http://technet.microsoft.com/library/hh831747.aspx)
-
-[Authentication Mechanism Assurance for AD DS in Windows Server 2008 R2 Step-by-Step Guide](http://technet.microsoft.com/library/dd378897.aspx)
-
-[Trusted Platform Module](trusted-platform-module-overview.md)
-
+- [Isolated User Mode in Windows 10 with Dave Probert (Channel 9)](https://channel9.msdn.com/Blogs/Seth-Juarez/Isolated-User-Mode-in-Windows-10-with-Dave-Probert)
+- [Isolated User Mode Processes and Features in Windows 10 with Logan Gabriel (Channel 9)](http://channel9.msdn.com/Blogs/Seth-Juarez/Isolated-User-Mode-Processes-and-Features-in-Windows-10-with-Logan-Gabriel)
+- [More on Processes and Features in Windows 10 Isolated User Mode with Dave Probert (Channel 9)](https://channel9.msdn.com/Blogs/Seth-Juarez/More-on-Processes-and-Features-in-Windows-10-Isolated-User-Mode-with-Dave-Probert)
+- [Mitigating Credential Theft using the Windows 10 Isolated User Mode (Channel 9)](https://channel9.msdn.com/Blogs/Seth-Juarez/Mitigating-Credential-Theft-using-the-Windows-10-Isolated-User-Mode)
+- [Enabling Strict KDC Validation in Windows Kerberos](http://www.microsoft.com/download/details.aspx?id=6382)
+- [What's New in Kerberos Authentication for Windows Server 2012](http://technet.microsoft.com/library/hh831747.aspx)
+- [Authentication Mechanism Assurance for AD DS in Windows Server 2008 R2 Step-by-Step Guide](http://technet.microsoft.com/library/dd378897.aspx)
+- [Trusted Platform Module](trusted-platform-module-overview.md)
-
diff --git a/windows/keep-secure/dcom-machine-access-restrictions-in-security-descriptor-definition-language-sddl-syntax.md b/windows/keep-secure/dcom-machine-access-restrictions-in-security-descriptor-definition-language-sddl-syntax.md
index 33a9de5798..5d4da312b6 100644
--- a/windows/keep-secure/dcom-machine-access-restrictions-in-security-descriptor-definition-language-sddl-syntax.md
+++ b/windows/keep-secure/dcom-machine-access-restrictions-in-security-descriptor-definition-language-sddl-syntax.md
@@ -2,50 +2,30 @@
title: DCOM Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax (Windows 10)
description: Describes the best practices, location, values, and security considerations for the DCOM Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax policy setting.
ms.assetid: 0fe3521a-5252-44df-8a47-8d92cf936e7c
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax** policy setting.
-
## Reference
-
-
This policy setting allows you to define additional computer-wide controls that govern access to all Distributed Component Object Model (DCOM)–based applications on a device. These controls restrict call, activation, or launch requests on the device. A simple way to think about these access controls is as an additional access check that is performed against a device-wide access control list (ACL) on each call, activation, or launch of any COM-based server. If the access check fails, the call, activation, or launch request is denied. (This check is in addition to any access check that is run against the server-specific ACLs.) In effect, it provides a minimum authorization standard that must be passed to access any COM-based server. This policy setting controls access permissions to cover call rights.
-
These device-wide ACLs provide a way to override weak security settings that are specified by an application through the CoInitializeSecurity function or application-specific security settings. They provide a minimum security standard that must be passed, regardless of the settings of the specific server.
-
These ACLs also provide a centralized location for an administrator to set a general authorization policy that applies to all COM-based servers on the device.
-
This policy setting allows you to specify an ACL in two different ways. You can type the security descriptor in SDDL, or you can grant or deny Local Access and Remote Access permissions to users and groups. We recommend that you use the built-in user interface to specify the ACL contents that you want to apply with this setting. The default ACL settings vary, depending on the version of Windows you are running.
-
### Possible values
-
- *User-defined input* of the SDDL representation of the groups and privileges
-
When you specify the users or groups that are to be given permissions, the security descriptor field is populated with the Security Descriptor Definition Language representation of those groups and privileges. Users and groups can be given explicit Allow or Deny privileges for local access and remote access.
-
- Blank
-
This represents how the local security policy deletes the policy enforcement key. This value deletes the policy and then sets it as Not defined. The Blank value is set by using the ACL editor to empty the list, and then pressing OK.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -84,53 +64,24 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a computer restart when they are saved locally or distributed through Group Policy.
-
### Group Policy
-
The registry settings that are created as a result of enabling the **DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax** policy setting take precedence over the previous registry settings when this policy setting was configured. The Remote Procedure Call (RPC) service checks the new registry keys in the Policies section for the computer restrictions, and these registry entries take precedence over the existing registry keys under OLE. This means that previously existing registry settings are no longer effective, and if you make changes to the existing settings, device access permissions for users are not changed. Use care in configuring the list of users and groups.
-
If the administrator is denied permission to access DCOM applications due to the changes made to DCOM in the Windows operating system, the administrator can use the **DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax** policy setting to manage DCOM access to the computer. The administrator can use this setting to specify which users and groups can access the DCOM application on the computer locally and remotely. This will restore control of the DCOM application to the administrator and users. To do this, open the **DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax** setting, and click **Edit Security**. Specify the users or groups you want to include and the computer access permissions for those users or groups. This defines the setting and sets the appropriate SDDL value.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Many COM applications include some security-specific code (for example, to call CoInitializeSecurity), but they use weak settings that allow unauthenticated access to the process. Administrators cannot override these settings to force stronger security in earlier versions of Windows without modifying the application. An attacker could attempt to exploit weak security in an individual application by attacking it through COM calls.
-
Also, the COM infrastructure includes the Remote Procedure Call Services (RPCSS), a system service that runs during and after computer startup. This service manages activation of COM objects and the running object table and provides helper services to DCOM remoting. It exposes RPC interfaces that can be called remotely. Because some COM-based servers allow unauthenticated remote access, these interfaces can be called by anyone, including unauthenticated users. As a result, RPCSS can be attacked by malicious users who use remote, unauthenticated computers.
-
### Countermeasure
-
To protect individual COM-based applications or services, set the **DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax** setting to an appropriate device-wide ACL.
-
### Potential impact
-
Windows implements default COM ACLs when they are installed. Modifying these ACLs from the default may cause some applications or components that communicate by using DCOM to fail. If you implement a COM-based server and you override the default security settings, confirm that the application-specific call permissions that ACL assigns are the correct permissions for appropriate users. If it does not, you must change your application-specific permission ACL to provide appropriate users with activation rights so that applications and Windows components that use DCOM do not fail.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/dcom-machine-launch-restrictions-in-security-descriptor-definition-language-sddl-syntax.md b/windows/keep-secure/dcom-machine-launch-restrictions-in-security-descriptor-definition-language-sddl-syntax.md
index 3ec93358be..ec95e60bb9 100644
--- a/windows/keep-secure/dcom-machine-launch-restrictions-in-security-descriptor-definition-language-sddl-syntax.md
+++ b/windows/keep-secure/dcom-machine-launch-restrictions-in-security-descriptor-definition-language-sddl-syntax.md
@@ -2,48 +2,29 @@
title: DCOM Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax (Windows 10)
description: Describes the best practices, location, values, and security considerations for the DCOM Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax security policy setting.
ms.assetid: 4b95d45f-dd62-4c34-ba32-43954528dabe
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax** security policy setting.
-
## Reference
-
-
This policy setting is similar to the [DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax](dcom-machine-access-restrictions-in-security-descriptor-definition-language-sddl-syntax.md) setting in that it allows you to define additional computer-wide controls that govern access to all DCOM–based applications on a device. However, the ACLs that are specified in this policy setting control local and remote COM launch requests (not access requests) on the device. A simple way to think about this access control is as an additional access check that is performed against a device-wide ACL on each launch of any COM-based server. If the access check fails, the call, activation, or launch request is denied. (This check is in addition to any access check that is run against the server-specific ACLs.) In effect, it provides a minimum authorization standard that must be passed to launch any COM-based server. The DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax policy setting differs in that it provides a minimum access check that is applied to attempts to access an already launched COM-based server.
-
These device-wide ACLs provide a way to override weak security settings that are specified by an application through CoInitializeSecurity or application-specific security settings. They provide a minimum security standard that must be passed, regardless of the settings of the specific COM-based server. These ACLs provide a centralized location for an administrator to set a general authorization policy that applies to all COM-based servers.
-
The **DCOM: Machine Launch Restrictions in the Security Descriptor Definition Language (SDDL) syntax** setting allows you to specify an ACL in two ways. You can type the security descriptor in SDDL, or you can grant or deny Local Access and Remote Access permissions to users and groups. We recommend that you use the built-in user interface to specify the ACL contents that you want to apply with this setting. The default ACL settings vary, depending on the version of Windows you are running.
-
### Possible values
-
- Blank
-
This represents how the local security policy deletes the policy enforcement key. This value deletes the policy and then sets it to Not defined. The Blank value is set by using the ACL editor to empty the list, and then pressing OK.
-
- *User-defined input* of the SDDL representation of the groups and privileges
-
When you specify the users or groups that are to be given permission, the security descriptor field is populated with the Security Descriptor Definition Language representation of those groups and privileges. Users and groups can be given explicit Allow or Deny privileges on both local access and remote access.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -82,55 +63,25 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a computer restart when they are saved locally or distributed through Group Policy.
-
### Group Policy
-
The registry settings that are created as a result of this policy take precedence over the previous registry settings in this area. The Remote Procedure Call (RPC) service (RpcSs) checks the new registry keys in the Policies section for the computer restrictions; these entries take precedence over the existing registry keys under OLE.
-
If you are denied access to activate and launch DCOM applications due to the changes made to DCOM in the Windows operating system, this policy setting can be used to control the DCOM activation and launch to the device.
-
You can specify which users and groups can launch and activate DCOM applications on the device locally and remotely by using the **DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax** policy setting. This restores control of the DCOM application to the administrator and specified users. To do this, open the **DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax** setting, and click **Edit Security**. Specify the groups that you want to include and the device launch permissions for those groups. This defines the setting and sets the appropriate SDDL value.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Many COM applications include some security-specific code (for example, to call CoInitializeSecurity), but they use weak settings that allow unauthenticated access to the process. You cannot override these settings to force stronger security in earlier versions of Windows without modifying the application. An attacker could attempt to exploit weak security in an individual application by attacking it through COM calls.
-
Also, the COM infrastructure includes the Remote Procedure Call Service (RPCSS), a system service that runs during computer startup and always runs after that. This service manages activation of COM objects and the running object table and provides helper services to DCOM remoting. It exposes RPC interfaces that can be called remotely. Because some COM-based servers allow unauthenticated remote component activation, these interfaces can be called by anyone, including unauthenticated users. As a result, RPCSS can be attacked by malicious users using remote, unauthenticated computers.
-
### Countermeasure
-
To protect individual COM-based applications or services, set this policy setting to an appropriate computer-wide ACL.
-
### Potential impact
-
Windows implements default COM ACLs when they are installed. Modifying these ACLs from the default may cause some applications or components that communicate by using DCOM to fail. If you implement a COM-based server and you override the default security settings, confirm that the application-specific launch permissions ACL assigns include activation permissions to appropriate users. If it does not, you must change your application-specific launch permission ACL to provide appropriate users with activation rights so that applications and Windows components that use DCOM do not fail.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/debug-programs.md b/windows/keep-secure/debug-programs.md
index 2950e96f89..cfcafef2b9 100644
--- a/windows/keep-secure/debug-programs.md
+++ b/windows/keep-secure/debug-programs.md
@@ -2,48 +2,29 @@
title: Debug programs (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Debug programs security policy setting.
ms.assetid: 594d9f2c-8ffc-444b-9522-75615ec87786
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Debug programs
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Debug programs** security policy setting.
-
## Reference
-
-
This policy setting determines which users can attach to or open any process, even those they do not own. Developers who are debugging their own applications do not need to be assigned this user right. Developers who are debugging new system components need this user right. This user right provides access to sensitive and critical operating-system components.
-
Constant: SeDebugPrivilege
-
### Possible values
-
- User-defined list of accounts
-
- Not defined
-
### Best practices
-
- Assign this user right only to trusted users to reduce security vulnerabilities.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
By default, members of the Administrators group have this right.
-
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
-
@@ -82,59 +63,27 @@ The following table lists the actual and effective default policy values for the
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
A restart of the device is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
### Group Policy
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
The **Debug programs** user right can be exploited to capture sensitive device information from system memory or to access and modify kernel or application structures. Some attack tools exploit this user right to extract hashed passwords and other private security information or to insert malware. By default, the **Debug programs** user right is assigned only to administrators, which helps mitigate risk from this vulnerability.
-
### Countermeasure
-
Remove the accounts of all users and groups that do not require the **Debug programs** user right.
-
### Potential impact
-
If you revoke this user right, no one can debug programs. However, typical circumstances rarely require this capability on production devices. If an issue arises that requires an application to be debugged on a production server, you can move the server to a different organizational unit (OU) temporarily and assign the **Debug programs** user right to a separate Group Policy for that OU.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/delete-an-applocker-rule.md b/windows/keep-secure/delete-an-applocker-rule.md
index bed27aa9de..7b34477fad 100644
--- a/windows/keep-secure/delete-an-applocker-rule.md
+++ b/windows/keep-secure/delete-an-applocker-rule.md
@@ -2,47 +2,26 @@
title: Delete an AppLocker rule (Windows 10)
description: This topic for IT professionals describes the steps to delete an AppLocker rule.
ms.assetid: 382b4be3-0df9-4308-89b2-dcf9df351eb5
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Delete an AppLocker rule
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals describes the steps to delete an AppLocker rule.
-
As older apps are retired and new apps are deployed in your organization, it will be necessary to modify the application control policies. If an app becomes unsupported by the IT department or is no longer allowed due to the organization's security policy, then deleting the rule or rules associated with that app will prevent the app from running.
-
For info about testing an AppLocker policy to see what rules affect which files or applications, see [Test an AppLocker policy by Using Test-AppLockerPolicy](test-an-applocker-policy-by-using-test-applockerpolicy.md).
-
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group Policy Object (GPO) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or in a security template. For info how to use these MMC snap-ins to administer AppLocker, see [Administer AppLocker](administer-applocker.md#bkmk-using-snapins).
-
**To delete a rule in an AppLocker policy**
-
1. Open the AppLocker console.
-
2. Click the appropriate rule collection for which you want to delete the rule.
-
3. In the details pane, right-click the rule to delete, click **Delete**, and then click **Yes**.
-
**Note**
When using Group Policy, for the rule deletion to take effect on computers within the domain, the GPO must be distributed or refreshed.
-
When this procedure is performed on the local device, the AppLocker policy takes effect immediately.
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/deny-access-to-this-computer-from-the-network.md b/windows/keep-secure/deny-access-to-this-computer-from-the-network.md
index e4e6d176a7..07247e4be1 100644
--- a/windows/keep-secure/deny-access-to-this-computer-from-the-network.md
+++ b/windows/keep-secure/deny-access-to-this-computer-from-the-network.md
@@ -2,48 +2,29 @@
title: Deny access to this computer from the network (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Deny access to this computer from the network security policy setting.
ms.assetid: 935e9f89-951b-4163-b186-fc325682bb0b
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Deny access to this computer from the network
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Deny access to this computer from the network** security policy setting.
-
## Reference
-
-
This security setting determines which users are prevented from accessing a device over the network.
-
Constant: SeDenyNetworkLogonRight
-
### Possible values
-
- User-defined list of accounts
-
- Guest
-
### Best practices
-
- Because all Active Directory Domain Services programs use a network logon for access, use caution when you assign this user right on domain controllers.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
By default, this setting is Guest on domain controllers and on stand-alone servers.
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -82,71 +63,33 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Policy management
-
-
This section describes features and tools available to help you manage this policy.
-
A restart of the device is not required for this policy setting to be effective.
-
This policy setting supersedes the **Access this computer from the network** policy setting if a user account is subject to both policies.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
### Group Policy
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Users who can log on to the device over the network can enumerate lists of account names, group names, and shared resources. Users with permission to access shared folders and files can connect over the network and possibly view or modify data.
-
### Countermeasure
-
Assign the **Deny access to this computer from the network** user right to the following accounts:
-
- Anonymous logon
-
- Built-in local Administrator account
-
- Local Guest account
-
- All service accounts
-
An important exception to this list is any service accounts that are used to start services that must connect to the device over the network. For example, let’s say you have configured a shared folder for web servers to access, and you present content within that folder through a website. You may need to allow the account that runs IIS to log on to the server with the shared folder from the network. This user right is particularly effective when you must configure servers and workstations on which sensitive information is handled because of regulatory compliance concerns.
-
### Potential impact
-
If you configure the **Deny access to this computer from the network** user right for other accounts, you could limit the abilities of users who are assigned to specific administrative roles in your environment. You should verify that delegated tasks are not negatively affected.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/deny-log-on-as-a-batch-job.md b/windows/keep-secure/deny-log-on-as-a-batch-job.md
index c7a4c65273..11dbb9313f 100644
--- a/windows/keep-secure/deny-log-on-as-a-batch-job.md
+++ b/windows/keep-secure/deny-log-on-as-a-batch-job.md
@@ -2,50 +2,30 @@
title: Deny log on as a batch job (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Deny log on as a batch job security policy setting.
ms.assetid: 0ac36ebd-5e28-4b6a-9b4e-8924c6ecf44b
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Deny log on as a batch job
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Deny log on as a batch job** security policy setting.
-
## Reference
-
-
This policy setting determines which accounts are prevented from logging on by using a batch-queue tool to schedule and start jobs automatically in the future. The ability to log on by using a batch-queue tool is needed for any account that is used to start scheduled jobs by means of the Task Scheduler.
-
Constant: SeDenyBatchLogonRight
-
### Possible values
-
- User-defined list of accounts
-
- Not defined
-
### Best practices
-
1. When you assign this user right, thoroughly test that the effect is what you intended.
-
2. Within a domain, modify this setting on the applicable Group Policy Object (GPO).
-
3. **Deny log on as a batch job** prevents administrators or operators from using their personal accounts to schedule tasks, which helps with business continuity when that person transitions to other positions or responsibilities.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
-
@@ -84,65 +64,30 @@ The following table lists the actual and effective default policy values for the
-
-
## Policy management
-
-
This section describes features and tools available to help you manage this policy.
-
A restart of the device is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
This policy setting might conflict with and negate the **Log on as a batch job** setting.
-
### Group Policy
-
On a domain-joined device, including the domain controller, this policy can be overwritten by a domain policy, which will prevent you from modifying the local policy setting.
-
For example, if you are trying to configure Task Scheduler on your domain controller, check the Settings tab of your two domain controller policy and domain policy GPOs in the Group Policy Management Console (GPMC). Verify the targeted account is not present in the **Deny log on as a batch job** User Rights Assignment and also correctly configured in the **Log on as a batch job** setting.
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Accounts that have the **Deny log on as a batch job** user right could be used to schedule jobs that could consume excessive computer resources and cause a denial-of-service condition.
-
### Countermeasure
-
Assign the **Deny log on as a batch job** user right to the local Guest account.
-
### Potential impact
-
If you assign the **Deny log on as a batch job** user right to other accounts, you could deny the ability to perform required job activities to users who are assigned specific administrative roles. You should confirm that delegated tasks are not affected adversely.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/deny-log-on-as-a-service.md b/windows/keep-secure/deny-log-on-as-a-service.md
index 005a760cfe..af4556d1b8 100644
--- a/windows/keep-secure/deny-log-on-as-a-service.md
+++ b/windows/keep-secure/deny-log-on-as-a-service.md
@@ -2,50 +2,30 @@
title: Deny log on as a service (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Deny log on as a service security policy setting.
ms.assetid: f1114964-df86-4278-9b11-e35c66949794
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Deny log on as a service
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Deny log on as a service** security policy setting.
-
## Reference
-
-
This policy setting determines which users are prevented from logging on to the service applications on a device.
-
A service is an application type that runs in the system background without a user interface. It provides core operating system features, such as web serving, event logging, file serving, printing, cryptography, and error reporting.
-
Constant: SeDenyServiceLogonRight
-
### Possible values
-
- User-defined list of accounts
-
- Not defined
-
### Best practices
-
1. When you assign this user right, thoroughly test that the effect is what you intended.
-
2. Within a domain, modify this setting on the applicable Group Policy Object (GPO).
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
-
@@ -84,63 +64,29 @@ The following table lists the actual and effective default policy values for the
-
-
## Policy management
-
-
This section describes features and tools available to help you manage this policy.
-
A restart of the computer is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
### Group Policy
-
On a domain-joined device, including the domain controller, this policy can be overwritten by a domain policy, which will prevent you from modifying the local policy setting.
-
This policy setting might conflict with and negate the **Log on as a service** setting.
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Accounts that can log on to a service application could be used to configure and start new unauthorized services, such as a keylogger or other malware. The benefit of the specified countermeasure is somewhat reduced by the fact that only users with administrative rights can install and configure services, and an attacker who has already attained that level of access could configure the service to run by using the System account.
-
### Countermeasure
-
We recommend that you not assign the **Deny log on as a service** user right to any accounts. This is the default configuration. Organizations that are extremely concerned about security might assign this user right to groups and accounts when they are certain that they will never need to log on to a service application.
-
### Potential impact
-
If you assign the **Deny log on as a service** user right to specific accounts, services may not start and a denial-of-service condition could result.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/deny-log-on-locally.md b/windows/keep-secure/deny-log-on-locally.md
index 82391e79b2..e8bc095116 100644
--- a/windows/keep-secure/deny-log-on-locally.md
+++ b/windows/keep-secure/deny-log-on-locally.md
@@ -2,48 +2,29 @@
title: Deny log on locally (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Deny log on locally security policy setting.
ms.assetid: 00150e88-ec9c-43e1-a70d-33bfe10434db
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Deny log on locally
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Deny log on locally** security policy setting.
-
## Reference
-
-
This policy setting determines which users are prevented from logging on directly at the device's console.
-
Constant: SeDenyInteractiveLogonRight
-
### Possible values
-
- User-defined list of accounts
-
- Not defined
-
### Best practices
-
1. Assign the **Deny log on locally** user right to the local guest account to restrict access by potentially unauthorized users.
-
2. Test your modifications to this policy setting in conjunction with the **Allow log on locally** policy setting to determine if the user account is subject to both policies.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
-
@@ -82,63 +63,29 @@ The following table lists the actual and effective default policy values for the
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
A restart of the device is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
If you apply this policy setting to the Everyone group, no one will be able to log on locally.
-
### Group Policy
-
This policy setting supersedes the **Allow log on locally** policy setting if a user account is subject to both policies.
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Any account with the ability to log on locally could be used to log on at the console of the device. If this user right is not restricted to legitimate users who must log on to the console of the device, unauthorized users might download and run malicious software that elevates their user rights.
-
### Countermeasure
-
Assign the **Deny log on locally** user right to the local Guest account. If you have installed optional components such as ASP.NET, you may want to assign this user right to additional accounts that are required by those components.
-
### Potential impact
-
If you assign the **Deny log on locally** user right to additional accounts, you could limit the abilities of users who are assigned to specific roles in your environment. However, this user right should explicitly be assigned to the ASPNET account on device that are configured with the Web Server role. You should confirm that delegated activities are not adversely affected.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/deny-log-on-through-remote-desktop-services.md b/windows/keep-secure/deny-log-on-through-remote-desktop-services.md
index 952c471dfd..85f6651839 100644
--- a/windows/keep-secure/deny-log-on-through-remote-desktop-services.md
+++ b/windows/keep-secure/deny-log-on-through-remote-desktop-services.md
@@ -2,46 +2,28 @@
title: Deny log on through Remote Desktop Services (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Deny log on through Remote Desktop Services security policy setting.
ms.assetid: 84bbb807-287c-4acc-a094-cf0ffdcbca67
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Deny log on through Remote Desktop Services
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Deny log on through Remote Desktop Services** security policy setting.
-
## Reference
-
-
This policy setting determines which users are prevented from logging on to the device through a Remote Desktop connection through Remote Desktop Services. It is possible for a user to establish a Remote Desktop connection to a particular server, but not be able to log on to the console of that server.
-
Constant: SeDenyRemoteInteractiveLogonRight
-
### Possible values
-
- User-defined list of accounts
-
- Not defined
-
### Best practices
-
- To control who can open a Remote Desktop connection and log on to the device, add the user account to or remove user accounts from the Remote Desktop Users group.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
-
@@ -80,63 +62,29 @@ The following table lists the actual and effective default policy values for the
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
A restart of the computer is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
The **Remote System** property controls settings for Remote Desktop Services (**Allow or prevent remote connections to the computer**) and for Remote Assistance (**Allow Remote Assistance connections to this computer**).
-
### Group Policy
-
This policy setting supersedes the [Allow log on through Remote Desktop Services](allow-log-on-through-remote-desktop-services.md) policy setting if a user account is subject to both policies.
-
Group Policy settings are applied in the following order. They overwrite settings on the local device at the next Group Policy update.
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. Organizational unit policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Any account with the right to log on through Remote Desktop Services could be used to log on to the remote console of the device. If this user right is not restricted to legitimate users who need to log on to the console of the computer, malicious users might download and run software that elevates their user rights.
-
### Countermeasure
-
Assign the **Deny log on through Remote Desktop Services** user right to the built-in local guest account and all service accounts. If you have installed optional components, such as ASP.NET, you may want to assign this user right to additional accounts that are required by those components.
-
### Potential impact
-
If you assign the **Deny log on through Remote Desktop Services** user right to other groups, you could limit the abilities of users who are assigned to specific administrative roles in your environment. Accounts that have this user right cannot connect to the device through Remote Desktop Services or Remote Assistance. You should confirm that delegated tasks are not negatively affected.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/deploy-applocker-policies-by-using-the-enforce-rules-setting.md b/windows/keep-secure/deploy-applocker-policies-by-using-the-enforce-rules-setting.md
index dee2747b62..cfd595104f 100644
--- a/windows/keep-secure/deploy-applocker-policies-by-using-the-enforce-rules-setting.md
+++ b/windows/keep-secure/deploy-applocker-policies-by-using-the-enforce-rules-setting.md
@@ -2,69 +2,34 @@
title: Deploy AppLocker policies by using the enforce rules setting (Windows 10)
description: This topic for IT professionals describes the steps to deploy AppLocker policies by using the enforcement setting method.
ms.assetid: fd3a3d25-ff3b-4060-8390-6262a90749ba
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Deploy AppLocker policies by using the enforce rules setting
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals describes the steps to deploy AppLocker policies by using the enforcement setting method.
-
## Background and prerequisites
-
-
These procedures assume that you have already deployed AppLocker policies with the enforcement set to **Audit only**, and you have been collecting data through the AppLocker event logs and other channels to determine what effect these policies have on your environment and the policy's adherence to your application control design.
-
For info about the AppLocker policy enforcement setting, see [Understand AppLocker enforcement settings](understand-applocker-enforcement-settings.md).
-
For info about how to plan an AppLocker policy deployment, see [AppLocker Design Guide](applocker-policies-design-guide.md).
-
## Step 1: Retrieve the AppLocker policy
-
-
Updating an AppLocker policy that is currently enforced in your production environment can have unintended results. Using Group Policy, you can export the policy from the Group Policy Object (GPO) and then update the rule or rules by using AppLocker on your AppLocker reference or test PC. For the procedure to do this, see [Export an AppLocker policy from a GPO](export-an-applocker-policy-from-a-gpo.md) and [Import an AppLocker policy into a GPO](import-an-applocker-policy-into-a-gpo.md). For local AppLocker policies, you can update the rule or rules by using the Local Security policy snap-in (secpol.msc) on your AppLocker reference or test PC. For the procedures to do this, see [Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md) and [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md).
-
## Step 2: Alter the enforcement setting
-
-
Rule enforcement is applied only to a collection of rules, not to individual rules. AppLocker divides the rules into collections: executable files, Windows Installer files, packaged apps, scripts, and DLL files. By default, if enforcement is not configured and rules are present in a rule collection, those rules are enforced. For information about the enforcement setting, see [Understand AppLocker Enforcement Settings](understand-applocker-enforcement-settings.md). For the procedure to alter the enforcement setting, see [Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md).
-
## Step 3: Update the policy
-
-
You can edit an AppLocker policy by adding, changing, or removing rules. However, you cannot specify a version for the AppLocker policy by importing additional rules. To ensure version control when modifying an AppLocker policy, use Group Policy management software that allows you to create versions of GPOs. An example of this type of software is the [Advanced Group Policy Management](http://go.microsoft.com/fwlink/p/?LinkId=145013) feature from the Microsoft Desktop Optimization Pack.
-
**Caution**
You should not edit an AppLocker rule collection while it is being enforced in Group Policy. Because AppLocker controls what files are allowed to run, making changes to a live policy can create unexpected behavior.
-
-
For the procedure to update the GPO, see [Import an AppLocker policy into a GPO](import-an-applocker-policy-into-a-gpo.md).
-
For the procedures to distribute policies for local PCs by using the Local Security Policy snap-in (secpol.msc), see [Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md) and [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md).
-
## Step 4: Monitor the effect of the policy
-
-
When a policy is deployed, it is important to monitor the actual implementation of that policy. You can do this by monitoring your support organization's app access request activity and reviewing the AppLocker event logs. To monitor the effect of the policy, see [Monitor Application Usage with AppLocker](monitor-application-usage-with-applocker.md).
-
## Additional resources
-
-
- For steps to perform other AppLocker policy tasks, see [Administer AppLocker](administer-applocker.md).
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/deploy-the-applocker-policy-into-production.md b/windows/keep-secure/deploy-the-applocker-policy-into-production.md
index da107fefad..1fbb0a2cc3 100644
--- a/windows/keep-secure/deploy-the-applocker-policy-into-production.md
+++ b/windows/keep-secure/deploy-the-applocker-policy-into-production.md
@@ -2,60 +2,31 @@
title: Deploy the AppLocker policy into production (Windows 10)
description: This topic for the IT professional describes the tasks that should be completed before you deploy AppLocker application control settings.
ms.assetid: ebbb1907-92dc-499e-8cee-8e637483c9ae
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Deploy the AppLocker policy into production
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional describes the tasks that should be completed before you deploy AppLocker application control settings.
-
After successfully testing and modifying the AppLocker policy for each Group Policy Object (GPO), you are ready to deploy the enforcement settings into production. For most organizations, this means switching the AppLocker enforcement setting from **Audit only** to **Enforce rules**. However, it is important to follow the deployment plan that you created earlier. For more info, see the [AppLocker Design Guide](applocker-policies-design-guide.md). Depending on the needs of different business groups in your organization, you might deploy different enforcement settings for linked GPOs.
-
### Understand your design decisions
-
Before you deploy an AppLocker policy, you should determine:
-
- For each business group, which applications will be controlled and in what manner. For more info, see [Create a list of apps deployed to each business group](create-list-of-applications-deployed-to-each-business-group.md).
-
- How to handle requests for application access. For info about what to consider when developing your support policies, see [Plan for AppLocker policy management](plan-for-applocker-policy-management.md).
-
- How to manage events, including forwarding events. For info about event management in AppLocker, see [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md).
-
- Your GPO structure, including how to include policies generated by Software Restriction Policies and AppLocker policies. For more info, see [Determine the Group Policy structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md).
-
For info about how AppLocker deployment is dependent on design decisions, see [Understand AppLocker policy design decisions](understand-applocker-policy-design-decisions.md).
-
### AppLocker deployment methods
-
If you have configured a reference device, you can create and update your AppLocker policies on this device, test the policies, and then export the policies to the appropriate GPO for distribution. Another method is to create the policies and set the enforcement setting on **Audit only**, then observe the events that are generated.
-
- [Use a reference device to create and maintain AppLocker policies](use-a-reference-computer-to-create-and-maintain-applocker-policies.md)
-
This topic describes the steps to use an AppLocker reference computer to prepare application control policies for deployment by using Group Policy or other means.
-
- [Deploy AppLocker policies by using the enforce rules setting](deploy-applocker-policies-by-using-the-enforce-rules-setting.md)
-
This topic describes the steps to deploy the AppLocker policy by changing the enforcement setting to **Audit only** or to **Enforce rules**.
-
## See also
-
-
[AppLocker deployment guide](applocker-policies-deployment-guide.md)
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/determine-group-policy-structure-and-rule-enforcement.md b/windows/keep-secure/determine-group-policy-structure-and-rule-enforcement.md
index 8fc14ddac0..68200b376d 100644
--- a/windows/keep-secure/determine-group-policy-structure-and-rule-enforcement.md
+++ b/windows/keep-secure/determine-group-policy-structure-and-rule-enforcement.md
@@ -2,24 +2,17 @@
title: Determine the Group Policy structure and rule enforcement (Windows 10)
description: This overview topic describes the process to follow when you are planning to deploy AppLocker rules.
ms.assetid: f435fcbe-c7ac-4ef0-9702-729aab64163f
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Determine the Group Policy structure and rule enforcement
-
-
**Applies to**
-
- Windows 10
-
This overview topic describes the process to follow when you are planning to deploy AppLocker rules.
-
## In this section
-
-
@@ -46,29 +39,14 @@ This overview topic describes the process to follow when you are planning to dep
-
-
When you are determining how many Group Policy Objects (GPOs) to create when you apply an AppLocker policy in your organization, you should consider the following:
-
- Whether you are creating new GPOs or using existing GPOs
-
- Whether you are implementing Software Restriction Policies (SRP) policies and AppLocker policies in the same GPO
-
- GPO naming conventions
-
- GPO size limits
-
**Note**
There is no default limit on the number of AppLocker rules that you can create. However, in Windows Server 2008 R2, GPOs have a 2 MB size limit for performance. In subsequent versions, that limit is raised to 100 MB.
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/determine-which-applications-are-digitally-signed-on-a-reference-computer.md b/windows/keep-secure/determine-which-applications-are-digitally-signed-on-a-reference-computer.md
index b909f207d6..ad2925ee0a 100644
--- a/windows/keep-secure/determine-which-applications-are-digitally-signed-on-a-reference-computer.md
+++ b/windows/keep-secure/determine-which-applications-are-digitally-signed-on-a-reference-computer.md
@@ -2,45 +2,24 @@
title: Determine which apps are digitally signed on a reference device (Windows 10)
description: This topic for the IT professional describes how to use AppLocker logs and tools to determine which applications are digitally signed.
ms.assetid: 24609a6b-fdcb-4083-b234-73e23ff8bcb8
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Determine which apps are digitally signed on a reference device
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional describes how to use AppLocker logs and tools to determine which applications are digitally signed.
-
The Windows PowerShell cmdlet **Get-AppLockerFileInformation** can be used to determine which apps installed on your reference devices are digitally signed. Perform the following steps on each reference computer that you used to define the AppLocker policy. The device does not need to be joined to the domain.
-
Membership in the local **Administrators** group, or equivalent, is the minimum required to complete this procedure.
-
**To determine which apps are digitally signed on a reference device**
-
1. Run **Get-AppLockerFileInformation** with the appropriate parameters.
-
The **Get-AppLockerFileInformation** cmdlet retrieves the AppLocker file information from a list of files or from an event log. File information that is retrieved can include publisher information, file hash information, and file path information. File information from an event log may not contain all of these fields. Files that are not signed do not have any publisher information.
-
2. Analyze the publisher's name and digital signature status from the output of the command.
-
For command parameters, syntax, and examples, see [Get-AppLockerFileInformation](http://technet.microsoft.com/library/ee460961.aspx).
-
## Related topics
-
-
[Use a reference device to create and maintain AppLocker policies](use-a-reference-computer-to-create-and-maintain-applocker-policies.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/determine-your-application-control-objectives.md b/windows/keep-secure/determine-your-application-control-objectives.md
index 653b1b4585..55e77bdb3b 100644
--- a/windows/keep-secure/determine-your-application-control-objectives.md
+++ b/windows/keep-secure/determine-your-application-control-objectives.md
@@ -2,27 +2,19 @@
title: Determine your application control objectives (Windows 10)
description: This topic helps you with the decisions you need to make to determine what applications to control and how to control them by comparing Software Restriction Policies (SRP) and AppLocker.
ms.assetid: 0e84003e-6095-46fb-8c4e-2065869bb53b
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Determine your application control objectives
-
-
**Applies to**
-
- Windows 10
-
This topic helps you with the decisions you need to make to determine what applications to control and how to control them by comparing Software Restriction Policies (SRP) and AppLocker.
-
AppLocker is very effective for organizations with app restriction requirements whose environments have a simple topography and the application control policy goals are straightforward. For example, AppLocker can benefit an environment where non-employees have access to computers connected to the organizational network, such as a school or library. Large organizations also benefit from AppLocker policy deployment when the goal is to achieve a detailed level of control on the PCs that they manage for a relatively small number of apps.
-
There are management and maintenance costs associated with a list of allowed apps. In addition, the purpose of application control policies is to allow or prevent employees from using apps that might actually be productivity tools. Keeping employees or users productive while implementing the policies can cost time and effort. Lastly, creating user support processes and network support processes to keep the organization productive are also concerns.
-
Use the following table to develop your own objectives and determine which application control feature best addresses those objectives.
-
@@ -155,16 +147,7 @@ Use the following table to develop your own objectives and determine which appli
-
-
For more general info, see [AppLocker](applocker-overview.md).
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/device-guard-certification-and-compliance.md b/windows/keep-secure/device-guard-certification-and-compliance.md
index 4fba3a5dc4..9edecd273d 100644
--- a/windows/keep-secure/device-guard-certification-and-compliance.md
+++ b/windows/keep-secure/device-guard-certification-and-compliance.md
@@ -2,70 +2,45 @@
title: Device Guard certification and compliance (Windows 10)
description: Device Guard is a combination of hardware and software security features that, when configured together, will lock a device down so that it can only run trusted applications.
ms.assetid: 94167ECA-AB08-431D-95E5-7A363F42C7E3
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Device Guard certification and compliance
-
-
**Applies to**
-
- Windows 10
Device Guard is a combination of hardware and software security features that, when configured together, will lock a device down so that it can only run trusted applications. If the app isn’t trusted it can’t run, period. It also means that even if an attacker manages to get control of the Windows kernel, he or she will be much less likely to be able to run malicious executable code after the computer restarts because of how decisions are made about what can run and when.
-
Device Guard uses the new virtualization-based security in Windows 10 to isolate the Code Integrity service from the Windows kernel itself, letting the service use signatures defined by your enterprise-controlled policy to help determine what is trustworthy. In effect, the Code Integrity service runs alongside the kernel in a Windows hypervisor-protected container.
-
For details on how to implement Device Guard, see [Device Guard deployment guide](device-guard-deployment-guide.md).
-
## Why use Device Guard
-
-
With thousands of new malicious files created every day, using traditional methods like signature-based detection to fight against malware provides an inadequate defense against new attacks. Device Guard on Windows 10 changes from a mode where apps are trusted unless blocked by an antivirus or other security solutions, to a mode where the operating system trusts only apps authorized by your enterprise.
-
Device Guard also helps protect against [zero day attacks](http://go.microsoft.com/fwlink/p/?linkid=534209) and works to combat the challenges of [polymorphic viruses](http://go.microsoft.com/fwlink/p/?LinkId=534210).
### Advantages to using Device Guard
You can take advantage of the benefits of Device Guard, based on what you turn on and use:
-
- Helps provide strong malware protection with enterprise manageability
- Helps provide the most advanced malware protection ever offered on the Windows platform
- Offers improved tamper resistance
## How Device Guard works
-
Device Guard restricts the Windows 10 operating system to only running code that’s signed by trusted signers, as defined by your Code Integrity policy through specific hardware and security configurations, including:
-
- User Mode Code Integrity (UMCI)
-
- New kernel code integrity rules (including the new Windows Hardware Quality Labs (WHQL) signing constraints)
-
- Secure Boot with database (db/dbx) restrictions
-
- Virtualization-based security to help protect system memory and kernel mode apps and drivers from possible tampering.
-
- Optional: Trusted Platform Module (TPM) 1.2 or 2.0
-
Device Guard works with your image-building process, so you can turn the virtualization-based security feature on for capable devices, configure your Code Integrity policy, and set any other operating system settings you require for Windows 10. After that, Device Guard works to help protect your devices:
-
1. Your device starts up using Universal Extensible Firmware Interface (UEFI) Secure Boot, so that boot kits can’t run and so that Windows 10 starts before anything else.
-
2. After securely starting up the Windows boot components, Windows 10 can start the Hyper-V virtualization-based security services, including Kernel Mode Code Integrity. These services help protect the system core (kernel), privileged drivers, and system defenses, like anti-malware solutions, by preventing malware from running early in the boot process, or in kernel after startup.
-
3. Device Guard uses UMCI to make sure that anything that runs in User mode, such as a service, a Universal Windows Platform (UWP) app, or a Classic Windows application is trusted, allowing only trusted binaries to run.
-
4. At the same time that Windows 10 starts up, so too does the trusted platform module (TPM). TPM provides an isolated hardware component that helps protect sensitive information, such as user credentials and certificates.
-
## Required hardware and software
-
-
The following table shows the hardware and software you need to install and configure to implement Device Guard.
-
@@ -102,7 +77,7 @@ The following table shows the hardware and software you need to install and conf
Firmware lock |
The firmware setup should be locked to prevent other operating systems from starting and to prevent changes to the UEFI settings. • Work with your hardware manufacturer to ensure that the devices are Device Guard ready Work with your hardware manufacturer to ensure that the devices are Device Guard ready You should require a firmware password or higher authentication to change firmware settings. |
@@ -116,7 +91,7 @@ The following table shows the hardware and software you need to install and conf
Secure firmware update process |
-To verify that the firmware complies with the secure firmware update process, you can validate it against the [System.Fundamentals.Firmware.UEFISecureBoot](http://msdn.microsoft.com/library/windows/hardware/dn932805.aspx#system-fundamentals-firmware-uefisecureboot) Windows Hardware Compatibility Program requirement. |
+To verify that the firmware complies with the secure firmware update process, you can validate it against the [System.Fundamentals.Firmware.UEFISecureBoot](http://msdn.microsoft.com/library/windows/hardware/dn932805.aspx#system-fundamentals-firmware-uefisecureboot) Windows Hardware Compatibility Program requirement. Device Guard relies on the security of the underlying hardware and firmware. It is critical to keep the firmware updated with the latest security fixes. |
Signed processor microcode updates |
@@ -124,21 +99,9 @@ The following table shows the hardware and software you need to install and conf
-
-
## Related topics
-
-
[Get apps to run on Device Guard-protected devices](getting-apps-to-run-on-device-guard-protected-devices.md)
-
[Create a Device Guard code integrity policy based on a reference device](creating-a-device-guard-policy-for-signed-apps.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/device-guard-deployment-guide.md b/windows/keep-secure/device-guard-deployment-guide.md
index 5bace9eb68..3d9a53be0e 100644
--- a/windows/keep-secure/device-guard-deployment-guide.md
+++ b/windows/keep-secure/device-guard-deployment-guide.md
@@ -5,13 +5,13 @@ ms.assetid: 4BA52AA9-64D3-41F3-94B2-B87EC2717486
keywords: virtualization, security, malware
ms.prod: W10
ms.mktglfcycl: deploy
+ms.pagetype: devices
author: challum
---
# Device Guard deployment guide
**Applies to**
-
- Windows 10
Microsoft Device Guard is a feature set that consists of both hardware and software system integrity hardening features that revolutionize the Windows operating system’s security. Windows 10 employs Device Guard as well as code integrity and advanced hardware features such as CPU virtualization extensions, Trusted Platform Module, and second-level address translation to offer comprehensive modern security to its users. This guide explores the individual features in Device Guard as well as how to plan for, configure, and deploy them.
@@ -29,7 +29,6 @@ Device Guard breaks the current model of detection first-block later, and allows
Device Guard's features revolutionize the Windows operating system’s security by taking advantage of new virtualization-based security (VBS) options and the trust-nothing mobile device operating system model, which makes its defenses much more difficult for malware to penetrate. By using configurable code integrity policies, organizations are able to choose exactly which applications are allowed to run in their environment. Configurable code integrity is not limited to Windows Store applications and can be used with existing unsigned or signed Win32 applications, without the requirement that the application be repackaged. In addition, configurable code integrity can be deployed as an individual feature if organizations don’t possess the required hardware for Device Guard. Along with code integrity, Windows 10 leverages advanced hardware features such as CPU virtualization extensions, input/output memory management units (IOMMUs), Trusted Platform Module (TPM), and second-level address translation (SLAT) to offer comprehensive modern security to its users. Device Guard deployed with configurable code integrity and Credential Guard will be among the most impactful client-side security deployments an organization can implement today. In this guide, you learn about the individual features found within Device Guard as well as how to plan for, configure, and deploy them. Device Guard with configurable code integrity is intended for deployment alongside additional threat-mitigating Windows features such as Credential Guard and AppLocker.
## Device Guard overview
-
Device Guard is a feature set that consists of both hardware and software system integrity hardening features. These features revolutionize the Windows operating system’s security by taking advantage of new virtualization-based security options and the trust-nothing mobile device operating system model. A key feature in this model is called *configurable code integrity*, which allows your organization to choose exactly which software or trusted software publishers are allowed to run code on your client machines—exactly what has made mobile phone security so successful. In addition, Device Guard offers organizations a way to sign existing line-of-business (LOB) applications so that they can trust their own code, without the requirement that the application be repackaged. Also, this same method of signing provides organizations with a way to trust individual third-party applications. Device Guard—with configurable code integrity, Credential Guard, and AppLocker—is the most complete security defense that any Microsoft product has ever been able to offer a Windows client.
Advanced hardware features such as CPU virtualization extensions, IOMMUs, and SLAT, drive these new client security offerings. By integrating these hardware features further into the core operating system, Windows 10 leverages them in new ways. For example, the same type 1 hypervisor technology that is used to run virtual machines in Microsoft Hyper-V is used to isolate core Windows services into a virtualization-based, protected container. This is just one example of how Windows 10 integrates advanced hardware features deeper into the operating system to offer comprehensive modern security to its users. These hardware features are now available in consumer and enterprise PC markets and are discussed in detail in the [Hardware considerations](#hardware-considerations) section.
@@ -47,15 +46,13 @@ Historically, most malware has been unsigned. By simply deploying code integrity
**Hardware security features and virtualization-based security**
The Device Guard core functionality and protection start at the hardware level. Devices that have processors equipped with SLAT technologies and virtualization extensions, such as Intel Virtualization Technology (VT-x) and AMD-V, will be able to take advantage of virtualization-based security (VBS) features that enhance Windows security. Device Guard leverages VBS to isolate core Windows services that are critical to the security and integrity of the operating system. This isolation removes the vulnerability of these services from both the user and kernel modes and acts as an impenetrable barrier for most malware used today. One of these isolated services, called the Windows Code Integrity service, drives the Device Guard kernel mode configurable code integrity feature. This prevents code that has penetrated the kernel mode operations from compromising the code integrity service.
-
Another Windows 10 feature that employs VBS is Credential Guard. Credential Guard provides additional protection to Active Directory domain users by storing domain credentials within the virtualization container that hosts the Windows security services, such as code integrity. By isolating these domain credentials from the active user mode and kernel mode, they have a much lower risk of being stolen. For more information about how Credential Guard complements Device Guard, see the [Device Guard with Credential Guard](#device-guard-with-credential-guard) section. For information about how to enable Credential Guard, see the [Enable Credential Guard](#enable-credential-guard) section.
**Device Guard with AppLocker**
Although AppLocker is not considered a new Device Guard feature, it complements Device Guard functionality when enforced code integrity cannot be fully implemented or its functionality does not cover every desired scenario. There are many scenarios in which code integrity policies would be used alongside AppLocker rules. As a best practice, you should enforce code integrity policies at the most restrictive level possible for your organization, and then you can use AppLocker to fine-tune the restrictions to an even lower level.
-**Note** One example in which Device Guard functionality needs AppLocker supplementation is when your organization would like to limit universal applications. Universal applications have already been validated by Microsoft to be trustworthy to run, but an organization may not want to allow specific universal applications to run in their environment. You can accomplish this enforcement by using an AppLocker rule.
-
+>**Note:** One example in which Device Guard functionality needs AppLocker supplementation is when your organization would like to limit universal applications. Universal applications have already been validated by Microsoft to be trustworthy to run, but an organization may not want to allow specific universal applications to run in their environment. You can accomplish this enforcement by using an AppLocker rule.
AppLocker and Device Guard should run side-by-side in your organization, which offers the best of both security features at the same time and provides the most comprehensive security to as many devices as possible. In addition to these features, Microsoft recommends that you continue to maintain an enterprise antivirus solution for a well-rounded enterprise security portfolio.
**Device Guard with Credential Guard**
@@ -67,11 +64,8 @@ Although Credential Guard is not a feature within Device Guard, many organizatio
You can easily manage Device Guard features by using the familiar enterprise and client-management tools that IT pros use every day. Use the following management tools to enable and manage Device Guard:
- **Group Policy**. Windows 10 provides an administrative template to configure and deploy the configurable code integrity policies for your organization. This template also allows you to specify which hardware-based security features you would like to enable and deploy. You can manage these settings along with your existing Group Policy Objects (GPOs), which makes it simple to implement Device Guard features. In addition to these code integrity and hardware-based security features, you can use Group Policy to help you manage your catalog files. For more information about catalog files, see the [Catalog files](#catalog-files) section.
-
- **Microsoft System Center Configuration Manager**. You can use System Center Configuration Manager to simplify deployment and management of catalog files, code integrity policies, and hardware-based security features, as well as provide version control. For more information about how to deploy catalog files by using System Center Configuration Manager, see the [Deploy catalog files with System Center Configuration Manager](#deploy-cat-sccm) section.
-
- **Microsoft Intune**. In a future release of Microsoft Intune, organizations will be able to leverage Intune for deployment and management of code integrity policies and catalog files.
-
- **Windows PowerShell**. Windows PowerShell is primarily used to create and service code integrity policies. These policies represent the most powerful component of Device Guard. For a step-by-step walkthrough of how to create, audit, service, enforce, and deploy code integrity policies, see the [Code integrity policies](#code-integrity-policies) section.
These options provide the same experience you are used to in order to manage your existing enterprise management solutions. For more information about how to manage and deploy Device Guard hardware and code integrity features in your organization, see the [Device Guard deployment](#dg-deployment) section.
@@ -81,11 +75,8 @@ These options provide the same experience you are used to in order to manage you
In this section, you will learn about the following topics:
- [Approach enterprise code integrity deployment](#approach-enterprise-code-integrity-deployment). Device Guard deployment in your organization requires a planned approach. In this section, you get high-level recommendations for how to approach enterprise code integrity deployment in your organization.
-
- [Device Guard deployment scenarios](#device-guard-deployment-scenarios). When you plan for Device Guard deployment, Microsoft recommends that you categorize each device in your organization into a deployment scenario. These scenarios will provide a roadmap for your Device Guard deployment.
-
- [Code signing adoption](#code-signing-adoption). Code signing is important to the security that Device Guard provides. This section outlines the options for code signing and the benefits and disadvantages of each method.
-
- [Hardware considerations](#hardware-considerations). Several Device Guard features require advanced hardware. This section outlines the requirements for each of those features and what to look for during your next hardware refresh.
## Approach enterprise code integrity deployment
@@ -113,21 +104,17 @@ To help simplify the deployment of Device Guard to your organization, Microsoft
**Fixed-workload devices**
The lists of approved applications on fixed-workload devices rarely change as they perform the same tasks day after day. Examples of such devices include kiosks, point-of-sale systems, and call center PCs. These devices could easily employ the full capabilities of Device Guard and would require little management or policy modification. Device Guard implementation to these devices is painless and requires little ongoing administration. With Device Guard fully implemented, users are able to run only those applications that the IT department installs, manages, and trusts.
-
Device Guard components that are applicable to fixed-workload devices include:
- KMCI VBS protection
-
- Enforced UMCI policy
**Fully managed devices**
Fully managed devices are those for which the IT department restricts the software that is installed and run on them, but allows users to request installation of additional software or provides a list of approved software in an application catalog. Examples of such devices include locked-down, company-owned desktops and laptops. With these devices, establish an initial baseline code integrity policy and enforce the code integrity policy. The IT department manages the policies and updates the devices when new applications are approved or are provided in the System Center Configuration Manager catalog.
-
Device Guard components that are applicable to fully managed devices include:
- KMCI VBS protection
-
- Enforced UMCI policy
In this scenario, an application list is provided and trusted, and the trust policy is constantly re-evaluated when a user requests a new application. When an application is trusted across all of these devices, new user requests for that application do not require a policy update (alignment with application catalog). In addition, you can couple this with an onboarding process for new applications that you should add to the central application catalog. Initial implementation of Device Guard to fully managed devices is simple but does require more administrative overhead to manage trusted signatures of newly requested and approved applications.
@@ -139,7 +126,6 @@ Lightly managed devices are company-owned machines over which users have full co
Device Guard components that are applicable to lightly managed devices include:
- KMCI VBS protection
-
- UMCI policy in Audit mode
**Bring Your Own Device**
@@ -149,16 +135,13 @@ Device Guard is not a good way to manage devices in a Bring Your Own Device (BYO
## Code signing adoption
Code signing is crucial to the successful implementation of configurable code integrity policies. These policies can trust the signing certificates from both independent software vendors and customers. In Windows 10, all Windows Store applications are signed. Also, you can easily trust any other signed application by adding the signing certificate to the code integrity policy.
-
For unsigned applications, customers have multiple options for signing them so that code integrity policies can trust them. The first option is traditional embedded code signing. Organizations that have in-house development teams can incorporate binary code signing into their application development process, and then simply add the signing certificate to their code integrity policies. The second option for signing unsigned applications is to use catalog files. In Windows 10, customers have the ability to create catalog files as they monitor the installation and initial run of an application. For more information about signing existing unsigned LOB applications or third-party applications, see the [Existing line-of-business applications](#existing-line-of-business-applications) section.
### Existing line-of-business applications
Until now, existing LOB applications were difficult to trust if they were signed by a source other than the Windows Store or not signed at all. With Windows 10, signing your existing LOB and third-party unsigned applications is simplified. This new signing method does not require that applications be repackaged in any way. With catalog files, administrators can sign these unsigned applications simply by monitoring for an installation and initial startup. By using this monitoring information, an administrator can generate a catalog file. Catalog files are simply Secure Hash Algorithm 2 (SHA2) hash lists of discovered binaries. These binaries’ hash values are updated every time an application is updated and therefore require an updated catalog file. For simplified administration, consider incorporating embedded code signing into your application development process. For more information about how to generate catalog files, see the [Catalog files](#catalog-files) section.
-**Note**
-Catalog files are lists of individual binaries’ hash values. If the scanned application is updated, you will need to create a new catalog file. That said, binary signing is still highly recommended for any future applications so that no catalog files are needed.
-
+>**Note:** Catalog files are lists of individual binaries’ hash values. If the scanned application is updated, you will need to create a new catalog file. That said, binary signing is still highly recommended for any future applications so that no catalog files are needed.
When you create a catalog file, you must sign it by using enterprise public key infrastructure (PKI), or a purchased code signing certificate. When signed, code integrity policies can trust the signer or signing certificate of those files. For information about catalog file signing, see the [Catalog files](#catalog-files) section.
@@ -168,7 +151,6 @@ Although in-house applications can be signed after packaging by using catalog fi
## Hardware considerations
-
Careful consideration about which hardware vendor and specific models to purchase during your next hardware refresh is vitally important to the success of your organization’s Device Guard implementation efforts. In alignment with your current hardware life cycle, consider the process that is discussed in the [Approach enterprise code integrity deployment](#approach-enterprise-code-integrity-deployment) section when you determine the appropriate order of hardware replacement in your organization. Device Guard should be deployed in phases; therefore, you have time to methodically plan for its implementation.
Different hardware features are required to implement the various features of Device Guard. There will likely be some individual features that you will be able to enable with your current hardware and some that you will not. However, for organizations that want to implement Device Guard in its entirety, several advanced hardware features will be required. For additional details about the hardware features that are required for Device Guard components, see the following table.
@@ -223,7 +205,7 @@ Different hardware features are required to implement the various features of De
Secure firmware update process |
-To verify that the firmware complies with the secure firmware update process, you can validate it against the [System.Fundamentals.Firmware.UEFISecureBoot](http://msdn.microsoft.com/library/windows/hardware/dn932805.aspx#system-fundamentals-firmware-uefisecureboot) Windows Hardware Compatibility Program requirement. |
+To verify that the firmware complies with the secure firmware update process, you can validate it against the [System.Fundamentals.Firmware.UEFISecureBoot](http://msdn.microsoft.com/library/windows/hardware/dn932805.aspx#system-fundamentals-firmware-uefisecureboot) Windows Hardware Compatibility Program requirement. Device Guard relies on the security of the underlying hardware and firmware. It is critical to keep the firmware updated with the latest security fixes. |
Signed processor microcode updates |
@@ -237,9 +219,7 @@ Different hardware features are required to implement the various features of De
In this section, you learn about the following topics:
- [Configure hardware-based security features](#configure-hardware-based-security-features). This section explains how to enable the hardware-based security features in Device Guard. Also, you verify that the features are enabled by using both Windows Management Infrastructure (WMI) and Msinfo32.exe.
-
- [Catalog files](#catalog-files). In this section, you create, sign, and deploy catalog files. You deploy the catalog files by using both Group Policy and System Center Configuration Manager. Also, you use System Center Configuration Manager to inventory the deployed catalog files for reporting purposes.
-
- [Code integrity policies](#code-integrity-policies). This section provides information on how to create, audit, service, merge, deploy, and remove signed and unsigned configurable code integrity policies.
## Configure hardware-based security features
@@ -247,18 +227,14 @@ In this section, you learn about the following topics:
Hardware-based security features make up a large part of Device Guard security offerings. VBS reinforces the most important feature of Device Guard: configurable code integrity. There are three steps to configure hardware-based security features in Device Guard:
1. **Verify that hardware requirements are met and enabled**. Verify that your client machines possess the necessary hardware to run these features. A list of hardware requirements for the hardware-based security features is available in the [Hardware considerations](#hardware-considerations) section.
-
2. **Enable the necessary Windows features**. There are several ways to enable the Windows features required for hardware-based security. For details on which Windows features are needed, see the [Windows feature requirements for virtualization-based security](#windows-feature-requirements-for-virtualization-based-security) section.
-
3. **Enable desired features**. When the necessary hardware and Windows features have been enabled, you are ready to enable the desired hardware-based security features. For UEFI Secure Boot, see the [Enable UEFI Secure Boot](#enable-unified-extensible-interface-secure-boot) section. For information about how to enable VBS protection of the KMCI service, see the [Enable virtualization-based protection of kernel mode code integrity](#enable-virtualbased) section. Finally, for information about how to enable Credential Guard, see the [Enable Credential Guard](#enable-credential-guard) section.
### Windows feature requirements for virtualization-based security
In addition to the hardware requirements found in the [Hardware considerations](#hardware-considerations) section, you must enable certain operating system features before you can enable VBS: Microsoft Hyper-V and isolated user mode (shown in Figure 1).
-**Note**
-You can configure these features manually by using Windows PowerShell or Deployment Image Servicing and Management. For specific information about these methods, refer to the [Credential Guard documentation](http://go.microsoft.com/fwlink/p/?LinkId=624529).
-
+>**Note:** You can configure these features manually by using Windows PowerShell or Deployment Image Servicing and Management. For specific information about these methods, refer to the [Credential Guard documentation](http://go.microsoft.com/fwlink/p/?LinkId=624529).
@@ -270,30 +246,25 @@ After you enable these features, you can configure any hardware-based security f
Before you begin this process, verify that the target device meets the hardware requirements for UEFI Secure Boot that are laid out in the [Hardware considerations](#hardware-considerations) section. There are two options to configure UEFI Secure Boot: manual configuration of the appropriate registry keys and Group Policy deployment. Complete the following steps to manually configure UEFI Secure Boot on a computer running Windows 10:
-**Note**
-There are two platform security levels for Secure Boot: stand-alone Secure Boot and Secure Boot with DMA protection. DMA protection provides additional memory protection but will be enabled only on systems whose processors include DMA protection (IOMMU) technologies. Without the presence of IOMMUs and with DMA protection disabled, customers will lose protection from driver-based attacks.
-
+>**Note:** There are two platform security levels for Secure Boot: stand-alone Secure Boot and Secure Boot with DMA protection. DMA protection provides additional memory protection but will be enabled only on systems whose processors include DMA protection (IOMMU) technologies. Without the presence of IOMMUs and with DMA protection disabled, customers will lose protection from driver-based attacks.
1. Navigate to the **HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\DeviceGuard** registry subkey.
-
2. Set the **EnableVirtualizationBasedSecurity DWORD** value to **1**.
-
3. Set the **RequirePlatformSecurityFeatures DWORD** value as appropriate:
- Set this value to **1** to enable the **Secure Boot** option.
-
- Set this value to **2** to enable the **Secure Boot with DMA Protection** option.
4. Restart the client machine.
Unfortunately, it would be time consuming to perform these steps manually on every protected machine in your enterprise. Group Policy offers a much simpler way to deploy UEFI Secure Boot to your organization. This example creates a test organizational unit (OU) called *DG Enabled PCs*. If you prefer to link the policy to an existing OU, and then scope the GPO by using appropriately named computer security groups, you can certainly do so.
-**Note**
-Microsoft recommends that you test-enable this feature on a group of test machines before you deploy it to machines that are currently deployed to users.
+>**Note:** Microsoft recommends that you test-enable this feature on a group of test machines before you deploy it to machines that are currently deployed to users.
**Use Group Policy to deploy Secure Boot**
+
1. To create a new GPO, right-click the OU to which you want to link the GPO, and then click **Create a GPO in this domain, and Link it here**.
@@ -316,36 +287,29 @@ Microsoft recommends that you test-enable this feature on a group of test machin
Figure 4. Enable Secure Boot
- **Note**
- Device Guard Secure Boot is maximized when combined with DMA protection. If your hardware contains the IOMMUs required for DMA protection, be sure to select the **Secure Boot and DMA Protection** platform security level. If your hardware does not contain IOMMU, there are several mitigations provided by leveraging Secure Boot without DMA Protection.
-
+ >**Note:** Device Guard Secure Boot is maximized when combined with DMA protection. If your hardware contains the IOMMUs required for DMA protection, be sure to select the **Secure Boot and DMA Protection** platform security level. If your hardware does not contain IOMMU, there are several mitigations provided by leveraging Secure Boot without DMA Protection.
-
6. Close the Group Policy Management Editor, and then restart the Windows 10 test computer. After you configure this setting, UEFI Secure Boot will be enabled upon restart.
7. Check the test computer’s event log for Device Guard GPOs.
-
+
Processed Device Guard policies are logged in event viewer at Application and Services Logs\\Microsoft\\Windows\\DeviceGuard-GPEXT\\Operational. When the **Turn On Virtualization Based Security** policy is successfully processed, event ID 7000 is logged, which contains the selected settings within the policy.
### Enable virtualization-based security of kernel-mode code integrity
Before you begin this process, verify that the desired computer meets the hardware requirements for VBS found in the [Hardware considerations](#hardware-considerations) section, and enable the Windows features discussed in the [Virtualization-based security Windows feature requirements](#virtualization-based-security-windows-featurerrequirements) section. When validated, you can enable virtualization-based protection of KMCI in one of two ways: manual configuration of the appropriate registry subkeys and Group Policy deployment.
-**Note**
-All drivers on the system must be compatible with virtualization-based protection of code integrity; otherwise, your system may fail. Microsoft recommends that you enable this feature on a group of test machines before you enable it on deployed machines.
+>**Note:** All drivers on the system must be compatible with virtualization-based protection of code integrity; otherwise, your system may fail. Microsoft recommends that you enable this feature on a group of test machines before you enable it on deployed machines.
To configure virtualization-based protection of KMCI manually:
1. Navigate to the **HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\DeviceGuard** registry subkey.
-
2. Set the **HypervisorEnforcedCodeIntegrity DWORD** value to **1**.
-
3. Restart the client computer.
It would be time consuming to perform these steps manually on every protected machine in your enterprise. Instead, use Group Policy to deploy virtualization-based protection of KMCI. This example creates a test OU called *DG Enabled PCs*, which you will use to link the GPO. If you prefer to link the policy to an existing OU rather than create a test OU and scope the policy by using appropriately named computer security groups, that is another option.
-**Note**
-Microsoft recommends that you test-enable this feature on a group of test computers before you deploy it to machines that are currently deployed to users. If untested, there is a possibility that this feature can cause system instability and ultimately cause the client operating system to fail.
+>**Note:** Microsoft recommends that you test-enable this feature on a group of test computers before you deploy it to machines that are currently deployed to users. If untested, there is a possibility that this feature can cause system instability and ultimately cause the client operating system to fail.
To use Group Policy to configure VBS of KMCI:
@@ -388,15 +352,12 @@ Before you begin this process, verify that the desired system meets the hardware
To configure VBS of Credential Guard manually:
1. Navigate to the **HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa** registry subkey.
-
2. Set the **LsaCfgFlags DWORD** value to **1**.
-
3. Restart the client computer.
To avoid spending an unnecessary amount of time in manual deployments, use Group Policy to deploy Credential Guard to your organization. This example creates a test OU called *DG Enabled PCs*. To enable Credential Guard, you can link to any OU, and then scope the GPO’s application by using security groups.
-**Note**
-Microsoft recommends that you enable Credential Guard before you join a machine to the domain to ensure that all credentials are properly protected. Setting the appropriate registry subkeys during your imaging process would be ideal to achieve this protection.
+>**Note:** Microsoft recommends that you enable Credential Guard before you join a machine to the domain to ensure that all credentials are properly protected. Setting the appropriate registry subkeys during your imaging process would be ideal to achieve this protection.
To use Group Policy to enable Credential Guard:
@@ -426,16 +387,12 @@ To use Group Policy to enable Credential Guard:
6. Close Group Policy Management Editor, and then restart the Windows 10 test computer.
- **Note**
- The default platform security level is **Secure Boot**. If IOMMUs are available within the protected machines, it is recommended that you select **Secure Boot and DMA Protection** to maximize the mitigations that are available through Credential Guard.
+ >**Note:** The default platform security level is **Secure Boot**. If IOMMUs are available within the protected machines, it is recommended that you select **Secure Boot and DMA Protection** to maximize the mitigations that are available through Credential Guard.
7. Check the test client event log for Device Guard GPOs.
-**Note**
-All processed Device Guard policies are logged in event viewer under Application and Services Logs\\Microsoft\\Windows\\DeviceGuard-GPEXT\\Operational.
-
+>**Note** All processed Device Guard policies are logged in event viewer under Application and Services Logs\\Microsoft\\Windows\\DeviceGuard-GPEXT\\Operational.
-
For additional information about how Credential Guard works as well as additional configuration options, please refer to the [Credential Guard documentation](http://go.microsoft.com/fwlink/p/?LinkId=624529).
**Validate enabled Device Guard hardware-based security features**
@@ -444,13 +401,10 @@ Windows 10 and Windows Server 2016 and later have a WMI class for Device Guard
`Get-CimInstance –ClassName Win32_DeviceGuard –Namespace root\Microsoft\Windows\DeviceGuard`
-**Note**
-The *Win32\_DeviceGuard* WMI class is only available on the Enterprise edition of Windows 10.
+>**Note:** The *Win32\_DeviceGuard* WMI class is only available on the Enterprise edition of Windows 10.
The output of this command provides details of the available hardware-based security features as well as those features that are currently enabled. For detailed information about what each property means, refer to Table 1.
-
-
Table 1. Win32\_DeviceGuard properties
@@ -532,7 +486,8 @@ Table 1. Win32\_DeviceGuard properties
-Another method to determine the available and enabled Device Guard features is to run msinfo32.exe from an elevated PowerShell session. When you run this program, the Device Guard properties are displayed at the bottom of the **System Summary** section, as shown in Figure 11.
+Another method to determine the available and enabled Device Guard features is to run msinfo32.exe from an elevated PowerShell session. When you run this program, the Device Guard properties are displayed at the bottom of the
+**System Summary** section, as shown in Figure 11.
@@ -542,18 +497,14 @@ Figure 11. Device Guard properties in the System Summary
Enforcement of Device Guard on a system requires that every trusted application have a signature or its binary hashes added to the code integrity policy. For many organizations, this can be an issue when considering unsigned LOB applications. To avoid the requirement that organizations repackage and sign these applications, Windows 10 includes a tool called Package Inspector that monitors an installation process for any deployed and executed binary files. If the tool discovers such files, it itemizes them in a catalog file. These catalog files offer you a way to trust your existing unsigned applications, whether developed in house or by a third party, as well as trust signed applications for which you do not want to trust the signer but rather the specific application. When created, these files can be signed, the signing certificates added to your existing code integrity policies, and the catalog files themselves distributed to the clients.
-**Note**
-The Enterprise edition of Windows 10 or Windows Server 2016 is required to create and use catalog files.
+>**Note:** The Enterprise edition of Windows 10 or Windows Server 2016 is required to create and use catalog files.
### Create catalog files
The creation of catalog files is the first step to add an unsigned application to a code integrity policy. To create a catalog file, copy each of the following commands into an elevated Windows PowerShell session, and then complete the steps:
-**Note**
-When you establish a naming convention it makes it easier to detect deployed catalog files in the future. In this guide, you will use *\*-Contoso.cat* as the naming convention. For more information about why this practice is helpful to inventory or detect catalog files, see the [Inventory catalog files with System Center Configuration Manager](#inventory-catalog-files-with-system-center-configuration-manager) section.
-
+>**Note:** When you establish a naming convention it makes it easier to detect deployed catalog files in the future. In this guide, you will use *\*-Contoso.cat* as the naming convention. For more information about why this practice is helpful to inventory or detect catalog files, see the [Inventory catalog files with System Center Configuration Manager](#inventory-catalog-files-with-system-center-configuration-manager) section.
-
1. Be sure that a code integrity policy is currently running in audit mode.
Package Inspector does not always detect installation files that have been removed from the machine during the installation process. To ensure that these binaries are also trusted, the code integrity policy that you created and audited in the [Create code integrity policies from golden PCs](#create-code-integrity-policies-from-golden-pcs) and [Audit code integrity policies](#audit-code-integrity-policies) sections should be deployed, in audit mode, to the system on which you are running Package Inspector.
@@ -565,8 +516,7 @@ When you establish a naming convention it makes it easier to detect deployed cat
`PackageInspector.exe Start C:`
- **Note**
- Package inspector can monitor installations on any local drive. In this example, we install the application on drive C, but any other drive can be used.
+ >**Note:** Package inspector can monitor installations on any local drive. In this example, we install the application on drive C, but any other drive can be used.
3. Copy the installation media to drive C.
@@ -574,26 +524,19 @@ When you establish a naming convention it makes it easier to detect deployed cat
4. Install and launch the application.
- Install the application to drive C. When the installation is finished, launch the application and ensure that any product updates are installed and any downloadable content caught during the scan. When finished, close and reopen the application once again to ensure that the scan has captured all binaries.
-
- **Note**
- Every binary that is run while Package Inspector is running will be captured in the catalog. Therefore, be sure not to run additional installations or updates during the scan to minimize the risk of trusting the incorrect binaries. Alternatively, if you want to add multiple applications to a single catalog file, simply repeat the installation and run process while the current scan is running.
-
+ Install the application to drive C. When the installation is finished, launch the application and ensure that any product updates are installed and any downloadable content caught during the scan. When finished, close and
+ reopen the application once again to ensure that the scan has captured all binaries.
+
+ >**Note:** Every binary that is run while Package Inspector is running will be captured in the catalog. Therefore, be sure not to run additional installations or updates during the scan to minimize the risk of trusting the incorrect binaries. Alternatively, if you want to add multiple applications to a single catalog file, simply repeat the installation and run process while the current scan is running.
-
5. Stop the scan, and then generate definition and catalog files. When application installation and initial setup are finished, stop the Package Inspector scan and generate the catalog and definition files on your desktop by using the following commands:
`$ExamplePath=$env:userprofile+"\Desktop"`
-
`$CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"`
-
`$CatDefName=$ExamplePath+"\LOBApp.cdf"`
-
`PackageInspector.exe Stop C: -Name $CatFileName -cdfpath $CatDefName`
-**Note**
-This scan catalogs the hash values for each discovered binary file. If the applications that were scanned are updated, complete this process again to trust the new binaries’ hash values.
-
+>**Note:** This scan catalogs the hash values for each discovered binary file. If the applications that were scanned are updated, complete this process again to trust the new binaries’ hash values.
When finished, the files will be saved to your desktop. To trust this catalog file within a code integrity policy, the catalog must first be signed. Then, the signing certificate can be included in the code integrity policy, and the catalog file can be distributed to the individual client machines. Catalog files can be signed by using a certificate and SignTool.exe, a free tool available in the Windows SDK. For more information about signing catalog files with SignTool.exe, see the [Catalog signing with SignTool.exe](#catalog-signing-with-signtool.exe) section.
### Catalog signing with SignTool.exe
@@ -601,9 +544,7 @@ When finished, the files will be saved to your desktop. To trust this catalog fi
Device Guard makes it easy for organizations to sign and trust existing unsigned LOB applications. In this section, you sign a catalog file you generated in a previous section by using PackageInspector.exe. For information about how to create catalog files, see the [Create catalog files](#create-catalog-files) section. In this example, you need the following:
- SignTool.exe, found in the Windows software development kit (SDK—Windows 7 or later)
-
- The catalog file that you generated in the [Create catalog files](#create-catalog-files) section, or another catalog file that you have created
-
- Internal certification authority (CA) code signing certificate or purchased code signing certificate
If you do not have a code signing certificate, please see the [Create a Device Guard code signing certificate](#create-a-device-guard-code-signing-certificate) section for a walkthrough of how to create one. In addition to using the certificate you create in the Create a Device Guard code signing certificate section, this example signs the catalog file that you created in the [Create catalog files](#create-catalog-files) section. If you are using an alternate certificate or catalog file, update the following steps with the appropriate variables and certificate. To sign the existing catalog file, copy each of the following commands into an elevated Windows PowerShell session:
@@ -614,8 +555,7 @@ If you do not have a code signing certificate, please see the [Create a Device G
'$CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"'
- **Note**
- In this example, you use the catalog file you created in the [Create catalog files](#create-catalog-files) section. If you are signing another catalog file, be sure to update the *$ExamplePath* and *$CatFileName* variables with the correct information.
+ >**Note:** In this example, you use the catalog file you created in the [Create catalog files](#create-catalog-files) section. If you are signing another catalog file, be sure to update the *$ExamplePath* and *$CatFileName* variables with the correct information.
2. Import the code signing certificate. Import the code signing certificate that will be used to sign the catalog file to the signing user’s personal store. In this example, you use the certificate that you created in the [Create a Device Guard code signing certificate](#create-a-device-guard-code-signing-certificate) section.
@@ -623,14 +563,10 @@ If you do not have a code signing certificate, please see the [Create a Device G
` sign /n "ContosoDGSigningCert" /fd sha256 /v $CatFileName`
- **Note**
- The *<Path to signtool.exe>* variable should be the full path to the Signtool.exe utility. *ContosoDGSigningCert* is the subject name of the certificate that you will use to sign the catalog file. This certificate should be imported to your personal certificate store on the machine on which you are attempting to sign the catalog file.
-
- **Note**
- For additional information about Signtool.exe and all additional switches, visit [MSDN Sign Tool page](http://go.microsoft.com/fwlink/p/?LinkId=624163).
-
+ >**Note:** The *<Path to signtool.exe>* variable should be the full path to the Signtool.exe utility. *ContosoDGSigningCert* is the subject name of the certificate that you will use to sign the catalog file. This certificate should be imported to your personal certificate store on the machine on which you are attempting to sign the catalog file.
+
+ >**Note:** For additional information about Signtool.exe and all additional switches, visit [MSDN Sign Tool page](http://go.microsoft.com/fwlink/p/?LinkId=624163).
-
4. Verify the catalog file digital signature. Right-click the catalog file, and then click **Properties**. On the **Digital Signatures** tab, verify that your signing certificate exists with a **sha256** algorithm, as shown in Figure 12.
@@ -645,20 +581,17 @@ If you do not have a code signing certificate, please see the [Create a Device G
To simplify the management of catalog files, you can use Group Policy preferences to deploy catalog files to the appropriate PCs in your organization. The following process walks you through the deployment of a signed catalog file called LOBApp-Contoso.cat to a test OU called DG Enabled PCs with a GPO called **Contoso DG Catalog File GPO Test**.
-**Note**
-This walkthrough requires that you have previously created a signed catalog file and have a Windows 10 client PC on which to test a Group Policy deployment. For more information about how to create and sign a catalog file, see the [Catalog files](#catalog-files) section.
+>**Note:** This walkthrough requires that you have previously created a signed catalog file and have a Windows 10 client PC on which to test a Group Policy deployment. For more information about how to create and sign a catalog file, see the [Catalog files](#catalog-files) section.
To deploy a catalog file with Group Policy:
1. From either a domain controller or a client PC that has Remote Server Administration Tools (RSAT) installed, open the Group Policy Management Console (GPMC) by running **GPMC.MSC** or by searching for Group Policy Management.
-
2. Create a new GPO: right-click the DG Enabled PCs OU, and then click **Create a GPO in this domain, and Link it here**, as shown in Figure 13.
- **Note**
- The DG Enabled PCs OU is just an example of where to link the test GPO that you created in this section. You can use any OU name. Also, security group filtering is an option when you consider policy partitioning options based on the strategy discussed in the [Approach enterprise code integrity deployment](#approach-enterprise-code-integrity-deployment) section.
+ >**Note:** The DG Enabled PCs OU is just an example of where to link the test GPO that you created in this section. You can use any OU name. Also, security group filtering is an option when you consider policy partitioning options based on the strategy discussed in the [Approach enterprise code integrity deployment](#approach-enterprise-code-integrity-deployment) section.
-
+
Figure 13. Create a new GPO
3. Name the new GPO **Contoso DG Catalog File GPO Test**.
@@ -687,11 +620,8 @@ To deploy a catalog file with Group Policy:
9. In the **Destination File** box, type **C:\\Windows\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\\LOBApp-Contoso.cat**.
- **Note**
- LOBApp-Contoso.cat is not a required catalog name: This name was used in the [Create catalog files](#create-catalog-files) section, and so it was used here, as well.
-
+ >**Note:** LOBApp-Contoso.cat is not a required catalog name: This name was used in the [Create catalog files](#create-catalog-files) section, and so it was used here, as well.
-
10. On the **Common** tab of the **New File Properties** dialog box, select the **Remove this item when it is no longer applied** option. Doing this ensures that the catalog file is removed from every system, in case you ever need to stop trusting this application.
11. Click **OK** to complete file creation.
@@ -702,13 +632,10 @@ To deploy a catalog file with Group Policy:
As an alternative to Group Policy, you can use System Center Configuration Manager to deploy catalog files to the managed machines in your environment. This approach can simplify the deployment and management of multiple catalog files as well as provide reporting around which catalog each client or collection has deployed. In addition to the deployment of these files, System Center Configuration Manager can also be used to inventory the currently deployed catalog files for reporting and compliance purposes. Complete the following steps to create a new deployment package for catalog files:
-**Note**
-The following example uses a network share named \\\\Shares\\CatalogShare as a source for the catalog files. If you have collection specific catalog files, or prefer to deploy them individually, use whichever folder structure works best for your organization.
+>**Note:** The following example uses a network share named \\\\Shares\\CatalogShare as a source for the catalog files. If you have collection specific catalog files, or prefer to deploy them individually, use whichever folder structure works best for your organization.
1. Open the Configuration Manager console, and select the Software Library workspace.
-
2. Navigate to Overview\\Application Management, right-click **Packages**, and then click **Create Package**.
-
3. Name the package, set your organization as the manufacturer, and select an appropriate version number (Figure 16).
@@ -716,21 +643,14 @@ The following example uses a network share named \\\\Shares\\CatalogShare as a s
Figure 16. Specify information about the new package
4. Click **Next**, and then select **Standard program** as the program type.
-
5. On the **Standard Program** page, select a name, and then set the **Command Line** property to **XCopy \\\\Shares\\CatalogShare C:\\Windows\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} /H /K /E /Y**.
-
6. On the **Standard Program** page, select the following options (Figure 17):
- In **Name**, type **Contoso Catalog File Copy Program**.
-
- In **Command line**, browse to the program location.
-
- In **Startup folder**, type **C:\\Windows\\System32**.
-
- From the **Run** list, select **Hidden**.
-
- From the **Program can run** list, select **Whether or not a user is logged on**.
-
- From the **Drive mode** list, select **Runs with UNC name**.
@@ -738,27 +658,18 @@ The following example uses a network share named \\\\Shares\\CatalogShare as a s
Figure 17. Specify information about the standard program
7. Accept the defaults for the rest of the wizard, and then close the wizard.
-
After you create the deployment package, deploy it to a collection so that the clients will receive the catalog files. In this example, you deploy the package you just created to a test collection:
1. In the Software Library workspace, navigate to Overview\\Application Management\\Packages, right-click the catalog file package, and then click **Deploy**.
-
2. On the **General** page, select the test collection to which the catalog files will be deployed, and then click **Next**.
-
3. On the **Content** page, click **Add** to select the distribution point that will serve content to the selected collection, and then click **Next**.
-
4. On the **Deployment Settings** page, select **Required** in the **Purpose** box.
-
5. On the **Scheduling** page, click **New**.
-
6. In the **Assignment Schedule** dialog box, select **Assign immediately after this event**, set the value to **As soon as possible**, and then click **OK**.
-
7. On the **Scheduling** page, click **Next**.
-
8. On the **User Experience** page (Figure 18), set the following options, and then click **Next**:
- Select the **Software installation** check box.
-
- Select the **Commit changes at deadline or during a maintenance window (requires restarts)** check box.
@@ -766,22 +677,17 @@ After you create the deployment package, deploy it to a collection so that the c
Figure 18. Specify the user experience
9. On the **Distribution Points** page, in the **Deployment options** box, select **Run program from distribution point**, and then click **Next**.
-
10. On the **Summary** page, review the selections, and then click **Next**.
-
11. Close the wizard.
### Inventory catalog files with System Center Configuration Manager
When catalog files have been deployed to the machines within your environment, whether by using Group Policy or System Center Configuration Manager, you can inventory them with the software inventory feature of System Center Configuration Manager. The following process walks you through the enablement of software inventory to discover catalog files on your managed systems through the creation and deployment of a new client settings policy.
-**Note**
-A standard naming convention for your catalog files will significantly simplify the catalog file software inventory process. In this example, *-Contoso* has been added to all catalog file names.
+>**Note:** A standard naming convention for your catalog files will significantly simplify the catalog file software inventory process. In this example, *-Contoso* has been added to all catalog file names.
1. Open the Configuration Manager console, and select the Administration workspace.
-
2. Navigate to **Overview\\Client Settings**, right-click **Client Settings**, and then click **Create Custom Client Device Settings**.
-
3. Name the new policy, and select the **Software Inventory** check box from the **Select and then configure the custom settings for client devices** list, as shown in Figure 19.
@@ -798,50 +704,37 @@ A standard naming convention for your catalog files will significantly simplify
6. In the **Name** box, type **\*Contoso.cat**, and then click **Set**.
- **Note**
- **\*Contoso.cat** is the naming convention used in this example. This should mimic the naming convention you use for your catalog files.
-
+ >**Note:** **\*Contoso.cat** is the naming convention used in this example. This should mimic the naming convention you use for your catalog files.
-
7. In the **Path Properties** dialog box, select **Variable or path name**, and then type **C:\\Windows\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}** in the box, as shown in Figure 21.
-
+
-
+
Figure 21. Set the path properties
8. Click **OK**.
9. Now that you have created the client settings policy, right-click the new policy, click **Deploy**, and then choose the collection on which you would like to inventory the catalog files.
-
At the time of the next software inventory cycle, when the targeted clients receive the new client settings policy, you will be able to view the inventoried files in the built-in System Center Configuration Manager reports or Resource Explorer. To view the inventoried files on a client within Resource Explorer, complete the following steps:
1. Open the Configuration Manager console, and select the Assets and Compliance workspace.
-
2. Navigate to Overview\\Devices, and search for the device on which you want to view the inventoried files.
-
3. Right-click the computer, point to **Start**, and then click **Resource Explorer**.
-
4. In Resource Explorer, navigate to Software\\File Details to view the inventoried catalog files.
-**Note**
-If nothing is displayed in this view, navigate to Software\\Last Software Scan in Resource Explorer to verify that the client has recently completed a software inventory scan.
-
+>**Note:** If nothing is displayed in this view, navigate to Software\\Last Software Scan in Resource Explorer to verify that the client has recently completed a software inventory scan.
-
## Code integrity policies
-
Code integrity policies maintain the standards by which a computer running Windows 10 determines whether an application is trustworthy and can be run. For an overview of code integrity, see the [Configurable code integrity](#configurable-code-integrity) section.
A common system imaging practice in today’s IT organization is to establish a “golden” image as a reference for what an ideal system should look like, and then use that image to clone additional company assets. Code integrity policies follow a similar methodology, that begins with the establishment of a golden PC. Like when imaging, you can have multiple golden PCs based on model, department, application set, and so on. Although the thought process around the creation of code integrity policies is similar to imaging, these policies should be maintained independently. Assess the necessity of additional code integrity policies based on what should be allowed to be installed and run and for whom.
-**Note**
-Each machine can have only **one** code integrity policy at a time. Whichever way you deploy this policy, it is renamed to SIPolicy.p7b and copied to C:\\Windows\\System32\\CodeIntegrity. Keep this in mind when you create your code integrity policies.
+>**Note:** Each machine can have only **one** code integrity policy at a time. Whichever way you deploy this policy, it is renamed to SIPolicy.p7b and copied to C:\\Windows\\System32\\CodeIntegrity. Keep this in mind when you create your code integrity policies.
Optionally, code integrity policies can align with your software catalog as well as any IT department–approved applications. One simple method to implement code integrity policies is to use existing images to create one master code integrity policy. You do so by creating a code integrity policy from each image, and then by merging the policies. This way, what is installed on all of those images will be allowed to run, should the applications be installed on a computer based on a different image. Alternatively, you may choose to create a base applications policy and add policies based on the computer’s role or department. Organizations have a choice of how their policies are created, merged or serviced, and managed.
-**Note**
-The following section assumes that you will deploy code integrity policies as part of your Device Guard deployment. Alternatively, configurable code integrity is available without the enablement of Device Guard.
+>**Note:** The following section assumes that you will deploy code integrity policies as part of your Device Guard deployment. Alternatively, configurable code integrity is available without the enablement of Device Guard.
### Code integrity policy rules
@@ -874,7 +767,6 @@ Table 2. Code integrity policy - policy rule options
| **8 Required:EV Signers** | In addition to being WHQL signed, this rule requires that drivers must have been submitted by a partner that has an Extended Verification (EV) certificate. All future Windows 10 and later drivers will meet this requirement. |
| **9 Enabled:Advanced Boot Options Menu** | The F8 preboot menu is disabled by default for all code integrity policies. Setting this rule option allows the F8 menu to appear to physically present users. |
| **10 Enabled:Boot Audit on Failure** | Used when the code integrity policy is in enforcement mode. When a driver fails during startup, the code integrity policy will be placed in audit mode so that Windows will load. Administrators can validate the reason for the failure in the CodeIntegrity event log. |
-
File rule levels allow administrators to specify the level at which they want to trust their applications. This level of trust could be as low as the hash of each binary and as high as a PCA certificate. File rule levels are specified both when you create a new code integrity policy from a scan and when you create a policy from audit events. In addition, to combine rule levels found in multiple policies, you can merge the policies. When merged, code integrity policies combine their file rules. Each file rule level has its benefit and disadvantage. Use Table 3 to select the appropriate protection level for your available administrative resources and Device Guard deployment scenario.
Table 3. Code integrity policy - file rule levels
@@ -893,40 +785,33 @@ Table 3. Code integrity policy - file rule levels
| **WHQLPublisher** | This is a combination of the WHQL and the CN on the leaf certificate and is primarily for kernel binaries. |
| **WHQLFilePublisher** | Specifies that the binaries are validated and signed by WHQL, with a specific publisher (WHQLPublisher), and that the binary is the specified version or newer. This is primarily for kernel binaries. |
-**Note**
-When you create code integrity policies with the **New-CIPolicy** cmdlet, you can specify a primary file rule level by including the **–Level** parameter. For discovered binaries that cannot be trusted based on the primary file rule criteria, use the **–Fallback** parameter. For example, if the primary file rule level is PCACertificate but you would like to trust the unsigned applications as well, using the Hash rule level as a fallback adds the hash values of binaries that did not have a signing certificate.
+>**Note:** When you create code integrity policies with the **New-CIPolicy** cmdlet, you can specify a primary file rule level by including the **–Level** parameter. For discovered binaries that cannot be trusted based on the primary file rule criteria, use the **–Fallback** parameter. For example, if the primary file rule level is PCACertificate but you would like to trust the unsigned applications as well, using the Hash rule level as a fallback adds the hash values of binaries that did not have a signing certificate.
### Create code integrity policies from golden PCs
The process to create a golden code integrity policy from a reference system is straightforward. This section outlines the process that is required to successfully create a code integrity policy with Windows PowerShell. First, for this example, you must initiate variables to be used during the creation process. Rather than using variables, you can simply use the full file paths in the command. Next, you create the code integrity policy by scanning the system for installed applications. When created, the policy file is converted to binary format so that Windows can consume its contents.
-**Note**
-Before you begin this procedure, ensure that the reference PC is clean of viruses or malware. Each piece of installed software should be validated as trustworthy before you create this policy. Also, be sure that any software that you would like to be scanned is installed on the system before you create the code integrity policy.
+>**Note:** Before you begin this procedure, ensure that the reference PC is clean of viruses or malware. Each piece of installed software should be validated as trustworthy before you create this policy. Also, be sure that any software that you would like to be scanned is installed on the system before you create the code integrity policy.
To create a code integrity policy, copy each of the following commands into an elevated Windows PowerShell session, in order:
1. Initialize variables that you will use:
`$CIPolicyPath=$env:userprofile+"\Desktop\"`
-
`$InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"`
-
`$CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"`
2. Create a new code integrity policy by scanning the system for installed applications:
`New-CIPolicy -Level PcaCertificate -FilePath $InitialCIPolicy –UserPEs 3> CIPolicyLog.txt `
- **Note**
- By specifying the *–UserPEs* parameter, rule option **0 Enabled:UMCI** is automatically added to the code integrity policy. If you do not specify this parameter, use the following command to enable UMCI:
-
+ >**Note:** By specifying the *–UserPEs* parameter, rule option **0 Enabled:UMCI** is automatically added to the code integrity policy. If you do not specify this parameter, use the following command to enable UMCI:
+
`Set-RuleOption -Option 0 -FilePath $InitialCIPolicy`
-
- **Note**
- You can add the *–Fallback* parameter to catch any applications not discovered using the primary file rule level specified by the *–Level* parameter. For more information about file rule level options, see the [Code integrity policy rules](#code-integrity-policy-rules) section.
-
- **Note**
- If you would like to specify the code integrity policy scan to look only at a specific drive, you can do so by using the *–ScanPath* parameter. Without this parameter, as shown in the example, the entire system is scanned.
+
+ >**Note:** You can add the *–Fallback* parameter to catch any applications not discovered using the primary file rule level specified by the *–Level* parameter. For more information about file rule level options, see the [Code integrity policy rules](#code-integrity-policy-rules) section.
+
+ >**Note:** If you would like to specify the code integrity policy scan to look only at a specific drive, you can do so by using the *–ScanPath* parameter. Without this parameter, as shown in the example, the entire system is scanned.
3. Convert the code integrity policy to a binary format:
@@ -934,8 +819,7 @@ To create a code integrity policy, copy each of the following commands into an e
After you complete these steps, the Device Guard binary file (DeviceGuardPolicy.bin) and original .xml file (IntialScan.xml) will be available on your desktop. You can use the binary version as a code integrity policy or sign it for additional security.
-**Note**
-Microsoft recommends that you keep the original .xml file of the policy for use when you need to merge the code integrity policy with another policy or update its rule options. Alternatively, you would have to create a new policy from a new scan for servicing. For more information about how to merge code integrity policies, see the [Merge code integrity policies](#merge-code-integrity-policies) section.
+>**Note:** Microsoft recommends that you keep the original .xml file of the policy for use when you need to merge the code integrity policy with another policy or update its rule options. Alternatively, you would have to create a new policy from a new scan for servicing. For more information about how to merge code integrity policies, see the [Merge code integrity policies](#merge-code-integrity-policies) section.
Microsoft recommends that every code integrity policy be run in audit mode before being enforced. Doing so allows administrators to discover any issues with the policy without receiving error message dialog boxes. For information about how to audit a code integrity policy, see the [Audit code integrity policies](#audit-code-integrity-policies) section.
@@ -943,33 +827,27 @@ Microsoft recommends that every code integrity policy be run in audit mode befor
When code integrity policies are run in audit mode, it allows administrators to discover any applications that were missed during an initial policy scan and to identify any new applications that have been installed and run since the original policy was created. While a code integrity policy is running in audit mode, any binary that runs and would have been denied had the policy been enforced is logged in the Applications and Services Logs\\Microsoft\\CodeIntegrity\\Operational event log. When these logged binaries have been validated, they can easily be added to a new code integrity policy. When the new exception policy is created, you can merge it with your existing code integrity policies.
-**Note**
-Before you begin this process, you need to create a code integrity policy binary file. If you have not already done so, see the [Create a code integrity policy](#create-a-code-integrity-policy) section for a step-by-step walkthrough of the process to create a code integrity policy and convert it to binary format.
+>**Note:** Before you begin this process, you need to create a code integrity policy binary file. If you have not already done so, see the [Create an audit code integrity policy](#create-an-audit-code-integrity-policy) section for a step-by-step walkthrough of the process to create a code integrity policy and convert it to binary format.
To audit a code integrity policy with local policy:
1. Copy the DeviceGuardPolicy.bin file that you created in the [Create code integrity policies from golden PCs](#create-code-integrity-policies-from-golden-pcs) section to C:\\Windows\\System32\\CodeIntegrity.
-
2. On the system you want to run in audit mode, open the Local Group Policy Editor by running **GPEdit.msc**.
-
3. Navigate to Computer Configuration\\Administrative Templates\\System\\Device Guard, and then select **Deploy Code Integrity Policy**. Enable this setting by using the file path C:\\Windows\\System32\\CodeIntegrity\\DeviceGuardPolicy.bin, as shown in Figure 22.
- **Note**
- *DeviceGuardPolicy.bin* is not a required policy name. This name was simply used in the [Create code integrity policies from golden PCs](#create-code-golden) section and so was used here. Also, this policy file does not need to be copied to every system. Alternatively, you can copy the code integrity policies to a file share to which all computer accounts have access.
-
- **Note**
- Any policy you select here is converted to SIPolicy.p7b when it is deployed to the individual computers.
-
+ >**Note:** *DeviceGuardPolicy.bin* is not a required policy name. This name was simply used in the [Create code integrity policies from golden PCs](#create-code-golden) section and so was used here. Also, this policy file does not need to be copied to every system. Alternatively, you can copy the code integrity policies to a file share to which all computer accounts have access.
+
+ >**Note:** Any policy you select here is converted to SIPolicy.p7b when it is deployed to the individual computers.
+
-
+
Figure 22. Deploy your code integrity policy
-
- **Note**
- You may have noticed that the GPO setting references a .p7b file and this policy uses a .bin file. Regardless of the type of policy you deploy (.bin, .p7b, or .p7), they are all converted to SIPolicy.p7b when dropped on the Windows 10 computers. Microsoft recommends that you make your code integrity policies friendly and allow the system to convert the policy names for you. By doing this, it ensures that the policies are easily distinguishable when viewed in a share or any other central repository.
+
+ >**Note:** You may have noticed that the GPO setting references a .p7b file and this policy uses a .bin file. Regardless of the type of policy you deploy (.bin, .p7b, or .p7), they are all converted to SIPolicy.p7b when dropped on the Windows 10 computers. Microsoft recommends that you make your code integrity policies friendly and allow the system to convert the policy names for you. By doing this, it ensures that the policies are easily distinguishable when viewed in a share or any other central repository.
4. Restart reference system for the code integrity policy to take effect.
-
-5. Monitor the CodeIntegrity event log. While in audit mode, any exception to the deployed code integrity policy will be logged in the Applications and Services Logs\\Microsoft\\CodeIntegrity\\Operational event log, as shown in Figure 23.
+5. Monitor the CodeIntegrity event log. While in audit mode, any exception to the deployed code integrity policy will be logged in the Applications and Services Logs\\Microsoft\\CodeIntegrity\\Operational event log, as shown in
+Figure 23.
@@ -983,8 +861,7 @@ To audit a code integrity policy with local policy:
For information about how to create code integrity policies from audit events, see the [Create code integrity policies from golden PCs](#create-code-golden) section.
-**Note**
-An alternative method to test a policy is to rename the test file to SIPolicy.p7b and drop it into C:\\Windows\\System32\\CodeIntegrity, rather than deploy it with the local machine policy.
+>**Note:** An alternative method to test a policy is to rename the test file to SIPolicy.p7b and drop it into C:\\Windows\\System32\\CodeIntegrity, rather than deploy it with the local machine policy.
### Create an audit code integrity policy
@@ -993,7 +870,6 @@ When you run code integrity policies in audit mode, validate any exceptions and
1. Initialize the variables that will be used:
`$CIPolicyPath=$env:userprofile+"\Desktop\"`
-
`$CIAuditPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"`
2. Analyze audit results.
@@ -1004,45 +880,34 @@ When you run code integrity policies in audit mode, validate any exceptions and
`New-CIPolicy -Audit -Level Hash -FilePath $CIAuditPolicy –UserPEs 3> CIPolicylog.txt`
-**Note**
-When you create policies from audit events, you should carefully consider the file rule level that you select to trust. In this example, you use the Hash rule level, which should be used as a last resort.
-
+>**Note:** When you create policies from audit events, you should carefully consider the file rule level that you select to trust. In this example, you use the Hash rule level, which should be used as a last resort.
After you complete these steps, the Device Guard audit policy .xml file (DeviceGuardAuditPolicy.xml) will be available on your desktop. You can now use this file to update the existing code integrity policy that you ran in audit mode by merging the two policies. For instructions on how to merge this audit policy with the existing code integrity policy, see the [Merge code integrity policies](#merge-code-integrity-policies) section.
-**Note**
-You may have noticed that you did not generate a binary version of this policy as you did in the [Create code integrity policies from golden PCs](#create-code-integrity-policies-from-golden-pcs) section. This is because code integrity policies created from an audit log are not intended to run as stand-alone policies but rather to update existing code integrity policies.
+>**Note:** You may have noticed that you did not generate a binary version of this policy as you did in the [Create code integrity policies from golden PCs](#create-code-integrity-policies-from-golden-pcs) section. This is because code integrity policies created from an audit log are not intended to run as stand-alone policies but rather to update existing code integrity policies.
### Merge code integrity policies
When you develop code integrity policies, you will occasionally need to merge two policies. A common example is when a code integrity policy is initially created and audited. Another example is when you create a single master policy by using multiple code integrity policies previously created from golden PCs. Because each Windows 10 machine can have only one code integrity policy, it is important to properly maintain these policies. In this example, audit events have been saved into a secondary code integrity policy that you then merge with the initial code integrity policy.
-**Note**
-The following example uses the code integrity policy .xml files that you created in the [Create code integrity policies from golden PCs](#create-code-integrity-policies-from-golden-pcs) and [Audit code integrity policies](#audit-code-integrity-policies) sections. You can follow this process, however, with any two code integrity policies you would like to combine.
+>**Note:** The following example uses the code integrity policy .xml files that you created in the [Create code integrity policies from golden PCs](#create-code-integrity-policies-from-golden-pcs) and [Audit code integrity policies](#audit-code-integrity-policies) sections. You can follow this process, however, with any two code integrity policies you would like to combine.
To merge two code integrity policies, complete the following steps in an elevated Windows PowerShell session:
1. Initialize the variables that will be used:
` $CIPolicyPath=$env:userprofile+"\Desktop\"`
-
`$InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"`
-
`$AuditCIPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"`
-
`$MergedCIPolicy=$CIPolicyPath+"MergedPolicy.xml"`
-
` $CIPolicyBin=$CIPolicyPath+"NewDeviceGuardPolicy.bin"`
-
- **Note**
- The variables in this section specifically expect to find an initial policy on your desktop called InitialScan.xml and an audit code integrity policy called DeviceGuardAuditPolicy.xml. If you want to merge other code integrity policies, update the variables accordingly.
-
+
+ >**Note:** The variables in this section specifically expect to find an initial policy on your desktop called InitialScan.xml and an audit code integrity policy called DeviceGuardAuditPolicy.xml. If you want to merge other code integrity policies, update the variables accordingly.
-
2. Merge two policies to create a new code integrity policy:
-
+
`Merge-CIPolicy -PolicyPaths $InitialCIPolicy,$AuditCIPolicy -OutputFilePath $MergedCIPolicy`
-
-3. Convert the merged code integrity policy to binary format:
+3.
+Convert the merged code integrity policy to binary format:
` ConvertFrom-CIPolicy $MergedCIPolicy $CIPolicyBin `
@@ -1052,24 +917,17 @@ Now that you have created a new code integrity policy called NewDeviceGuardPolic
Every code integrity policy is created with audit mode enabled. After you have successfully deployed and tested a code integrity policy in audit mode and are ready to test the policy in enforced mode, complete the following steps in an elevated Windows PowerShell session:
-**Note**
-Every code integrity policy should be tested in audit mode first. For information about how to audit code integrity policies, see the [Audit code integrity policies](#audit-code-integrity) section.
+>**Note:** Every code integrity policy should be tested in audit mode first. For information about how to audit code integrity policies, see the [Audit code integrity policies](#audit-code-integrity) section.
1. Initialize the variables that will be used:
`$CIPolicyPath=$env:userprofile+"\Desktop\"`
-
`$InitialCIPolicy=$CIPolicyPath+"InitialScan.xml" `
-
`$EnforcedCIPolicy=$CIPolicyPath+"EnforcedPolicy.xml"`
-
`$CIPolicyBin=$CIPolicyPath+"EnforcedDeviceGuardPolicy.bin"`
- **Note**
- The initial code integrity policy that this section referenced was created in the [Create code integrity polices from golden PCs](#create-code-golden) section. If you are using a different code integrity policy, update the **CIPolicyPath** and **InitialCIPolicy** variables.
-
+ >**Note:** The initial code integrity policy that this section referenced was created in the [Create code integrity polices from golden PCs](#create-code-golden) section. If you are using a different code integrity policy, update the **CIPolicyPath** and **InitialCIPolicy** variables.
-
2. Copy the initial file to maintain an original copy:
`cp $InitialCIPolicy $EnforcedCIPolicy`
@@ -1078,20 +936,13 @@ Every code integrity policy should be tested in audit mode first. For informatio
`Set-RuleOption -Option 3 -FilePath $EnforcedCIPolicy -Delete`
- **Note**
- Rather than adding an **Enforced** option, code integrity policies are implicitly enforced if no **Audit Mode Enabled** option is present.
-
+ >**Note:** Rather than adding an **Enforced** option, code integrity policies are implicitly enforced if no **Audit Mode Enabled** option is present.
-
4. Convert the new code integrity policy to binary format:
-
+
`ConvertFrom-CIPolicy $EnforcedCIPolicy $CIPolicyBin`
-
- **Note**
- Microsoft strongly recommends that you enable rule options 9 and 10 before you run any enforced policy for the first time. If already present in the policy, do not remove it. Doing so allows Windows to start if the code integrity policy blocks a kernel-mode driver from running and provides administrators with a pre-boot command prompt. When ready for enterprise deployment, you can remove these options.
-
+ >**Note:** Microsoft strongly recommends that you enable rule options 9 and 10 before you run any enforced policy for the first time. If already present in the policy, do not remove it. Doing so allows Windows to start if the code integrity policy blocks a kernel-mode driver from running and provides administrators with a pre-boot command prompt. When ready for enterprise deployment, you can remove these options.
-
Now that this policy has been enforced, you can deploy it to your test machines. Rename the policy to SIPolicy.p7b and copy it to C:\\Windows\\System32\\CodeIntegrity for testing, or deploy the policy through Group Policy by following the instructions in the [Deploy and manage code integrity policies with Group Policy](#deploy-and-manage-code-integrity-policies-with-group-policy) section, or through client management software by following the instructions in the section “Deploying and managing code integrity policies by using Microsoft client management solutions.”
**Signing code integrity policies with SignTool.exe**
@@ -1100,25 +951,22 @@ Signed code integrity policies give organizations the highest level of malware p
Signing code integrity policies by using an on-premises CA-generated certificate or a purchased code signing certificate is straightforward. If you do not currently have a code signing certificate exported in .pfx format (containing private keys, extensions, and root certificates), see [Create a Device Guard code signing certificate](#create-a-device-guard-code-signing-certificate) to create one with your on-premises CA. Before signing code integrity policies for the first time, be sure to enable rule options 9 and 10 to leave troubleshooting options available to test administrators. When validated and ready for enterprise deployment, you can remove these options. For information about how to add rule options, see the [Code integrity policy rules](#code-integrity-policy-rules) section.
-**Note**
-Signing code integrity policies is the last step in a code integrity deployment. It is much more difficult to remove a signed code integrity policy than an unsigned one. Before you deploy a signed code integrity policy to deployed client computers, be sure to test its effect on a subset of machines.
+>**Note:** Signing code integrity policies is the last step in a code integrity deployment. It is much more difficult to remove a signed code integrity policy than an unsigned one. Before you deploy a signed code integrity policy to deployed client computers, be sure to test its effect on a subset of machines.
To sign a code integrity policy with SignTool.exe, you need the following components:
- SignTool.exe, found in the Windows SDK (Windows 7 or later)
-
- The binary format of the code integrity policy that you generated in the [Create code integrity policies from golden PCs](#create-code-golden) section or another code integrity policy that you have created
-
- An internal CA code signing certificate or a purchased code signing certificate
-If you do not have a code signing certificate, see the [Create a Device Guard code signing certificate](#create-dg-code) section for instructions on how to create one. If you use an alternate certificate or code integrity policy, be sure to update the following steps with the appropriate variables and certificate so that the commands will function properly. To sign the existing code integrity policy, copy each of the following commands into an elevated Windows PowerShell session:
+If you do not have a code signing certificate, see the [Create a Device Guard code signing certificate](#create-dg-code) section for instructions on how to create one. If you use an alternate certificate or code integrity policy, be sure to update the following steps with the appropriate variables and certificate so that the commands will function properly. To sign the existing code integrity policy, copy each of the following commands into an elevated
+Windows PowerShell session:
1. Initialize the variables that will be used:
`$CIPolicyPath=$env:userprofile+"\Desktop\" $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml" $CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"`
- **Note**
- This example uses the code integrity policy that you created in the [Create code integrity policies from golden PCs](#create-code-golden) section. If you are signing another policy, be sure to update the **$CIPolicyPath** and **$CIPolicyBin** variables with the correct information.
+ >**Note:** This example uses the code integrity policy that you created in the [Create code integrity policies from golden PCs](#create-code-golden) section. If you are signing another policy, be sure to update the **$CIPolicyPath** and **$CIPolicyBin** variables with the correct information.
2. Import the .pfx code signing certificate. Import the code signing certificate that you will use to sign the code integrity policy into the signing user’s personal store on the machine that will be doing the signing. In this example, you use the certificate that was created in the [Create a Device Guard code signing certificate](#create-dg-code) section.
@@ -1132,11 +980,9 @@ If you do not have a code signing certificate, see the [Create a Device Guard co
`Add-SignerRule -FilePath $InitialCIPolicy -CertificatePath -Kernel -User –Update`
- **Note**
- *<Path to exported .cer certificate>* should be the full path to the certificate that you exported in step 3.
+ >**Note:** *<Path to exported .cer certificate>* should be the full path to the certificate that you exported in step 3.
- **Note**
- Adding update signers is crucial to being able to modify or disable this policy in the future. For more information about how to disable signed code integrity policies, see the [Disable signed code integrity policies within Windows](#disable-signed-code) section.
+ >**Note:** Adding update signers is crucial to being able to modify or disable this policy in the future. For more information about how to disable signed code integrity policies, see the [Disable signed code integrity policies within Windows](#disable-signed-code) section.
6. Remove the unsigned policy rule option:
@@ -1149,9 +995,7 @@ If you do not have a code signing certificate, see the [Create a Device Guard co
8. Sign the code integrity policy by using SignTool.exe:
` sign -v /n "ContosoDGSigningCert" -p7 . -p7co 1.3.6.1.4.1.311.79.1 -fd sha256 $CIPolicyBin`
-
- **Note**
- The *<Path to signtool.exe>* variable should be the full path to the SignTool.exe utility. **ContosoDGSigningCert** is the subject name of the certificate that will be used to sign the code integrity policy. You should import this certificate to your personal certificate store on the machine you use to sign the policy.
+ >**Note:** The *<Path to signtool.exe>* variable should be the full path to the SignTool.exe utility. **ContosoDGSigningCert** is the subject name of the certificate that will be used to sign the code integrity policy. You should import this certificate to your personal certificate store on the machine you use to sign the policy.
9. Validate the signed file. When complete, the commands should output a signed policy file called DeviceGuardPolicy.bin.p7 to your desktop. You can deploy this file the same way you deploy an enforced or non-enforced policy. For information about how to deploy code integrity policies, see the [Deploy and manage code integrity policies with Group Policy](#deploy-and-manage-code-integrity-policies-with-group-policy) section.
@@ -1160,7 +1004,6 @@ If you do not have a code signing certificate, see the [Create a Device Guard co
There may come a time when an administrator wants to disable a code integrity policy. For unsigned code integrity policies, this process is simple. Depending on how the code integrity policy was deployed, unsigned policies can be disabled in one of two ways. If a code integrity policy was manually enabled and copied to the code integrity folder location, simply delete the file and restart the machine. The following locations can contain executing code integrity policies:
- <EFI System Partition>\\Microsoft\\Boot\\
-
- <OS Volume>\\Windows\\System32\\CodeIntegrity\\
If the code integrity policy was deployed by using Group Policy, the GPO that is currently enabling and deploying the policy must be set to disabled. Then, the code integrity policy will be disabled on the next computer restart.
@@ -1169,25 +1012,20 @@ If the code integrity policy was deployed by using Group Policy, the GPO that is
Signed policies protect Windows from administrative manipulation as well as malware that has gained administrative-level access to the system. For this reason, signed code integrity policies are intentionally more difficult to remove than unsigned policies. They inherently protect themselves from modification or removal and therefore are difficult even for administrators to remove successfully. If the signed code integrity policy is manually enabled and copied to the CodeIntegrity folder, to remove the policy, you must complete the following steps:
-**Note**
-For reference, signed code integrity policies should be replaced and removed from the following locations:
+>**Note:** For reference, signed code integrity policies should be replaced and removed from the following locations:
- <EFI System Partition>\\Microsoft\\Boot\\
-
- <OS Volume>\\Windows\\System32\\CodeIntegrity\\
-
1. Replace the existing policy with another signed policy that has the **6 Enabled: Unsigned System Integrity Policy** rule option enabled.
- **Note**
- To take effect, this policy must be signed with a certificate previously added to the **UpdatePolicySigners** section of the original signed policy you want to replace.
+ >**Note:** To take effect, this policy must be signed with a certificate previously added to the **UpdatePolicySigners** section of the original signed policy you want to replace.
2. Restart the client computer.
3. Verify that the new signed policy exists on the client.
- **Note**
- If the signed policy that contains rule option 6 has not been processed on the client, the addition of an unsigned policy may cause boot failures.
+ >**Note:** If the signed policy that contains rule option 6 has not been processed on the client, the addition of an unsigned policy may cause boot failures.
4. Delete the new policy.
@@ -1196,23 +1034,16 @@ For reference, signed code integrity policies should be replaced and removed fro
If the signed code integrity policy has been deployed using by using Group Policy, you must complete the following steps:
1. Replace the existing policy in the GPO with another signed policy that has the **6 Enabled: Unsigned System Integrity Policy** rule option enabled.
-
- **Note**
- To take effect, this policy must be signed with a certificate previously added to the **UpdatePolicySigners** section of the original signed policy you want to replace.
-
+ >**Note:** To take effect, this policy must be signed with a certificate previously added to the **UpdatePolicySigners** section of the original signed policy you want to replace.
-
2. Restart the client computer.
3. Verify that the new signed policy exists on the client.
- **Note**
- If the signed policy that contains rule option 6 has not been processed on the client, the addition of an unsigned policy may cause boot failures.
+ >**Note:** If the signed policy that contains rule option 6 has not been processed on the client, the addition of an unsigned policy may cause boot failures.
4. Set the GPO to disabled.
-
5. Delete the new policy.
-
6. Restart the client computer.
### Disable signed code integrity policies within the BIOS
@@ -1220,7 +1051,6 @@ If the signed code integrity policy has been deployed using by using Group Polic
There may be a time when signed code integrity policies cause a boot failure. Because code integrity policies enforce kernel mode drivers, it is important that they be thoroughly tested on each software and hardware configuration before being enforced and signed. Signed code integrity policies are validated in the pre-boot sequence by using Secure Boot. When you disable the Secure Boot feature in the BIOS, and then delete the file from the following locations on the operating system disk, it allows the system to boot into Windows:
- <EFI System Partition>\\Microsoft\\Boot\\
-
- <OS Volume>\\Windows\\System32\\CodeIntegrity\\
###
@@ -1229,23 +1059,19 @@ There may be a time when signed code integrity policies cause a boot failure. Be
Code integrity policies can easily be deployed and managed with Group Policy. A Device Guard administrative template will be available in Windows Server 2016 that allows you to simplify deployment of Device Guard hardware-based security features and code integrity policies. The following procedure walks you through how to deploy a code integrity policy called **DeviceGuardPolicy.bin** to a test OU called *DG Enabled PCs* by using a GPO called **Contoso GPO Test**.
-**Note**
-This walkthrough requires that you have previously created a code integrity policy and have a Windows 10 client PC on which to test a Group Policy deployment. For more information about how to create a code integrity policy, see the [Create code integrity polices from golden PCs](#create-code-integrity-polices-from-golden-pcs) section.
-
-**Note**
-Signed code integrity policies can cause boot failures when deployed. Microsoft recommends that signed code integrity policies be thoroughly tested on each hardware platform before enterprise deployment.
+>**Note:** This walkthrough requires that you have previously created a code integrity policy and have a Windows 10 client PC on which to test a Group Policy deployment. For more information about how to create a code integrity policy, see the [Create code integrity polices from golden PCs](#create-code-integrity-polices-from-golden-pcs) section.
+>**Note:** Signed code integrity policies can cause boot failures when deployed. Microsoft recommends that signed code integrity policies be thoroughly tested on each hardware platform before enterprise deployment.
To deploy and manage a code integrity policy with Group Policy:
1. On a domain controller on a client computer on which RSAT is installed, open the GPMC by running **GPMC.MSC** or searching for “Group Policy Management” in Windows Search.
2. Create a new GPO: right-click the DG Enabled PCs OU, and then click **Create a GPO in this domain, and Link it here**, as shown in Figure 24.
- **Note**
- The DG Enabled PCs OU is just an example of where to link the test GPO created in this section. Any OU name can be used. Also, security group filtering is an option when considering policy partitioning options based on the strategy discussed in the [Approach enterprise code integrity deployment](#approach-enterprise) section.
-
+ >**Note:** The DG Enabled PCs OU is just an example of where to link the test GPO created in this section. Any OU name can be used. Also, security group filtering is an option when considering policy partitioning options based on the strategy discussed in the [Approach enterprise code integrity deployment](#approach-enterprise) section.
+
-
+
Figure 24. Create a GPO
3. Name new GPO **Contoso GPO Test**. This example uses Contoso GPO Test as the name of the GPO. You can choose any name that you prefer for this example.
@@ -1259,18 +1085,15 @@ To deploy and manage a code integrity policy with Group Policy:
Figure 25. Edit the code integration policy
6. In the **Display Code Integrity Policy** dialog box, select the **Enabled** option, and then specify the code integrity policy deployment path.
-
In this policy setting, you specify either the local path in which the policy will exist on the client computer or a Universal Naming Convention (UNC) path that the client computers will look to retrieve the latest version of the policy. This example copied the DeviceGuardPolicy.bin file onto the test machine and will enable this setting and use the file path C:\\Windows\\System32\\CodeIntegrity\\DeviceGuardPolicy.bin, as shown in Figure 26.
- **Note**
- *DeviceGuardPolicy.bin* is not a required policy name: It was simply used in the [Create code integrity policies from golden PCs](#create-code-golden) section and so is used here, as well. Also, this policy file does not need to be copied to every computer. Alternatively, you can copy the code integrity policies to a file share to which the computer accounts have access. Any policy selected here is converted to SIPolicy.p7b when it is deployed to the individual client computers.
-
+ >**Note:** *DeviceGuardPolicy.bin* is not a required policy name: It was simply used in the [Create code integrity policies from golden PCs](#create-code-golden) section and so is used here, as well. Also, this policy file does not need to be copied to every computer. Alternatively, you can copy the code integrity policies to a file share to which the computer accounts have access. Any policy selected here is converted to SIPolicy.p7b when it is deployed to the individual client computers.
+
-
+
Figure 26. Enable the code integrity policy
-
- **Note**
- You may have noticed that the GPO setting references a .p7b file and this example uses a .bin file for the policy. Regardless of the type of policy you deploy (.bin, .p7b, or .p7), they are all converted to SIPolicy.p7b when dropped on the Windows 10 client computers. Make your code integrity policies friendly and allow the system to convert the policy names for you to ensure that the policies are easily distinguishable when viewed in a share or any other central repository.
+
+ >**Note:** You may have noticed that the GPO setting references a .p7b file and this example uses a .bin file for the policy. Regardless of the type of policy you deploy (.bin, .p7b, or .p7), they are all converted to SIPolicy.p7b when dropped on the Windows 10 client computers. Make your code integrity policies friendly and allow the system to convert the policy names for you to ensure that the policies are easily distinguishable when viewed in a share or any other central repository.
7. Close the Group Policy Management Editor, and then restart the Windows 10 test machine. Restarting the client computer updates the code integrity policy. For information about how to audit code integrity policies, see the [Audit code integrity policies](#audit-code-integrity-policies)section.
@@ -1279,7 +1102,6 @@ To deploy and manage a code integrity policy with Group Policy:
To sign catalog files or code integrity policies internally, you will either need a publicly issued code signing certificate or an internal CA. If you have purchased a code signing certificate, you can skip these steps and proceed to the sections that outline the steps to sign catalog files and code integrity policies. If you have not purchased a certificate but have an internal CA, complete these steps to create a code signing certificate:
1. Open the Certification Authority Microsoft Management Console (MMC) snap-in, and then select your issuing CA.
-
2. When connected, right-click **Certificate Templates**, and then click **Manage** to open the Certification Templates Console.
@@ -1289,81 +1111,56 @@ To sign catalog files or code integrity policies internally, you will either nee
3. In the navigation pane, right-click the Code Signing certificate, and then click **Duplicate Template**.
4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2012** from the **Certification Authority** list, and then select **Windows 8 / Windows Server 2012** from the **Certificate recipient** list.
-
5. On the **General** tab, specify the **Template display name** and **Template name**. This example uses **DG Catalog Signing Certificate**.
-
6. On the **Request Handling** tab, select the **Allow private key to be exported** check box.
-
7. On the **Extensions** tab, select the **Basic Constraints** check box, and then click **Edit**.
-
8. In the **Edit Basic Constraints Extension** dialog box, select the **Enable the extension** check box, as shown in Figure 28.
-
+
-
+
Figure 28. Enable constraints on the new template
-
-9. If a certificate manager is required to approve any issued certificates, on the **Issuance Requirements** tab, select **CA certificate manager approval**.
-
+9.
+If a certificate manager is required to approve any issued certificates, on the **Issuance Requirements** tab, select **CA certificate manager approval**.
10. On the **Subject Name** tab, select **Supply in the request**.
-
11. On the **Security** tab, verify that whatever account will be used to request the certificate has the right to enroll the certificate.
-
12. Click **OK** to create the template, and then close the Certificate Template Console.
-
When this certificate template has been created, you must publish it to the CA published template store. To do so, complete the following steps:
-
1. In the Certification Authority MMC snap-in, right-click **Certification Templates**, point to **New**, and then click **Certificate Template to Issue**, as shown in Figure 29.
A list of available templates to issue appears, including the template you just created.
-
+
-
+
Figure 29. Select the new certificate template to issue
-
+
2. Select the DG Catalog signing certificate, and then click **OK**.
-
Now that the template is available to be issued, you must request one from the Windows 10 computer that you use to create and sign catalog files. To begin, open the MMC, and then complete the following steps:
-
1. In MMC, from the **File** menu, click **Add/Remove Snap-in**. Double-click **Certificates**, and then select **My user account**.
-
2. In the Certificates snap-in, right-click the Personal store folder, point to **All Tasks**, and then click **Request New Certificate**.
-
3. Click **Next** twice to get to the certificate selection list.
-
4. In the **Request Certificate** list, select your newly created code signing certificate, and then select the blue text that requests additional information, as shown in Figure 30.
-
+
-
+
Figure 30. Get more information for your code signing certificate
-
-5. In the **Certificate Properties** dialog box, for **Type**, select **Common name**. For **Value**, select **ContosoDGSigningCert**, and then click **Add**. When added, click **OK.**
-
+5.
+In the **Certificate Properties** dialog box, for **Type**, select **Common name**. For **Value**, select **ContosoDGSigningCert**, and then click **Add**. When added, click **OK.**
6. Enroll and finish.
-**Note**
-If a certificate manager is required to approve any issued certificates and you selected to require management approval on the template, the request will need to be approved in the CA before it will be issued to the client.
+>**Note:** If a certificate manager is required to approve any issued certificates and you selected to require management approval on the template, the request will need to be approved in the CA before it will be issued to the client.
This certificate must be installed in the user’s personal store on the computer that will be signing the catalog files and code integrity policies. If the signing is going to be taking place on the machine on which you just requested the certificate, exporting the certificate to a .pfx file will not be required because it already exists in your personal store. If you are signing on another computer, you will need to export the .pfx certificate with the necessary keys and properties. To do so, complete the following steps:
1. Right-click the certificate, point to **All Tasks**, and then click **Export**.
-
2. Click **Next**, and then select **Yes, export the private key**.
-
3. Choose the default settings, and then select **Export all extended properties**.
-
4. Set a password, select an export path, and then select **DGCatSigningCert.pfx** as the file name.
-
When the certificate has been exported, import it into the personal store for the user who will be signing the catalog files or code integrity policies on the specific computer that will be signing them.
## Related topics
-
-[AppLocker overview](applocker-overview.md)
-
-[Code integrity](http://go.microsoft.com/fwlink/p/?LinkId=624173)
-
-[Credential guard](credential-guard.md)
-
-[Driver compatibility with Device Guard in Windows 10](http://go.microsoft.com/fwlink/p/?LinkId=624843)
-
-[Dropping the Hammer Down on Malware Threats with Windows 10’s Device Guard](http://go.microsoft.com/fwlink/p/?LinkId=624844)
+- [AppLocker overview](applocker-overview.md)
+- [Code integrity](http://go.microsoft.com/fwlink/p/?LinkId=624173)
+- [Credential guard](credential-guard.md)
+- [Driver compatibility with Device Guard in Windows 10](http://go.microsoft.com/fwlink/p/?LinkId=624843)
+- [Dropping the Hammer Down on Malware Threats with Windows 10’s Device Guard](http://go.microsoft.com/fwlink/p/?LinkId=624844)
diff --git a/windows/keep-secure/devices-allow-undock-without-having-to-log-on.md b/windows/keep-secure/devices-allow-undock-without-having-to-log-on.md
index 5b03d0aedc..1283cb2181 100644
--- a/windows/keep-secure/devices-allow-undock-without-having-to-log-on.md
+++ b/windows/keep-secure/devices-allow-undock-without-having-to-log-on.md
@@ -2,53 +2,32 @@
title: Devices Allow undock without having to log on (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Devices Allow undock without having to log on security policy setting.
ms.assetid: 1d403f5d-ad41-4bb4-9f4a-0779c1c14b8c
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Devices: Allow undock without having to log on
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **Devices: Allow undock without having to log on** security policy setting.
-
## Reference
-
-
This policy setting enables or disables the ability of a user to remove a portable device from a docking station without logging on. If you enable this policy setting, users can press a docked portable device's physical eject button to safely undock the device. If you disable this policy setting, the user must log on to receive permission to undock the device. Only users who have the **Remove Computer from Docking Station** privilege can obtain this permission.
-
**Note**
Disabling this policy setting only reduces theft risk for portable devices that cannot be mechanically undocked. Devices that can be mechanically undocked can be physically removed by the user whether or not they use the Windows undocking functionality.
-
-
Enabling this policy setting means that anyone with physical access to a device that has been placed in its docking station can remove the computer and possibly tamper with it. For devices that do not have docking stations, this policy setting has no impact. However, for users with a mobile computer that is normally docked while they are in the office, this policy setting will help lower the risk of equipment theft or a malicious user gaining physical access to these devices
-
### Possible values
-
- Enabled
-
- Disabled
-
- Not defined
-
### Best practices
-
It is advisable to disable the **Devices: Allow undock without having to log on** policy setting. Users who have docked their devices will have to log on to the local console before they can undock their systems.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -87,45 +66,20 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
If this policy setting is enabled, anyone with physical access to portable computers in docking stations could remove them and possibly tamper with them.
-
### Countermeasure
-
Disable the **Devices: Allow undock without having to log on** setting.
-
### Potential impact
-
Users who have docked their device must log on to the local console before they can undock their computers. For devices that do not have docking stations, this policy setting has no impact.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/devices-allowed-to-format-and-eject-removable-media.md b/windows/keep-secure/devices-allowed-to-format-and-eject-removable-media.md
index 40c23ebc27..146ef13dde 100644
--- a/windows/keep-secure/devices-allowed-to-format-and-eject-removable-media.md
+++ b/windows/keep-secure/devices-allowed-to-format-and-eject-removable-media.md
@@ -2,50 +2,30 @@
title: Devices Allowed to format and eject removable media (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Devices Allowed to format and eject removable media security policy setting.
ms.assetid: d1b42425-7244-4ab1-9d46-d68de823459c
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Devices: Allowed to format and eject removable media
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **Devices: Allowed to format and eject removable media** security policy setting.
-
## Reference
-
-
This policy setting determines who is allowed to format and eject removable media.
-
Users can move removable disks to a different device where they have administrative user rights and then take ownership of any file, assign themselves full control, and view or modify any file. The advantage of configuring this policy setting is diminished by the fact that most removable storage devices will eject media with the press of a button.
-
### Possible values
-
- Administrators
-
- Administrators and Power Users
-
- Administrators and Interactive Users (not applicable to Windows Server 2008 R2 or Windows 7 and later)
-
- Not defined
-
### Best practices
-
- It is advisable to set **Allowed to format and eject removable media** to **Administrators**. Only administrators will be able to eject NTFS-formatted removable media.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -84,45 +64,20 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Users could move data on removable disks to a different computer where they have administrative privileges. The user could then take ownership of any file, grant themselves full control, and view or modify any file. The fact that most removable storage devices eject media when a mechanical button is pressed diminishes the advantage of this policy setting.
-
### Countermeasure
-
Configure the **Devices: Allowed to format and eject removable media** setting to **Administrators**.
-
### Potential impact
-
Only administrators can format and eject removable media. If users are in the habit of using removable media for file transfers and storage, they must be informed of the change in policy.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/devices-prevent-users-from-installing-printer-drivers.md b/windows/keep-secure/devices-prevent-users-from-installing-printer-drivers.md
index b6c244f268..9a31968fed 100644
--- a/windows/keep-secure/devices-prevent-users-from-installing-printer-drivers.md
+++ b/windows/keep-secure/devices-prevent-users-from-installing-printer-drivers.md
@@ -2,50 +2,30 @@
title: Devices Prevent users from installing printer drivers (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Devices Prevent users from installing printer drivers security policy setting.
ms.assetid: ab70a122-f7f9-47e0-ad8c-541f30a27ec3
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Devices: Prevent users from installing printer drivers
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **Devices: Prevent users from installing printer drivers** security policy setting.
-
## Reference
-
-
For a device to print to a network printer, the driver for that network printer must be installed locally. The **Devices: Prevent users from installing printer drivers** policy setting determines who can install a printer driver as part of adding a network printer. When you set the value to **Enabled**, only Administrators and Power Users can install a printer driver as part of adding a network printer. Setting the value to **Disabled** allows any user to install a printer driver as part of adding a network printer. This setting prevents unprivileged users from downloading and installing an untrusted printer driver.
-
This setting has no impact if you have configured a trusted path for downloading drivers. When using trusted paths, the print subsystem attempts to use the trusted path to download the driver. If the trusted path download succeeds, the driver is installed on behalf of any user. If the trusted path download fails, the driver is not installed and the network printer is not added.
-
Although it might be appropriate in some organizations to allow users to install printer drivers on their own workstations, this is not suitable for servers. Installing a printer driver on a server can cause the system to become less stable. Only administrators should have this user right on servers. A malicious user might deliberately try to damage the system by installing inappropriate printer drivers.
-
### Possible values
-
- Enabled
-
- Disabled
-
- Not defined
-
### Best practices
-
- It is advisable to set **Devices: Prevent users from installing printer drivers** to Enabled. Only users in the Administrative, Power User, or Server Operator groups will be able to install printers on servers. If this policy setting is enabled, but the driver for a network printer already exists on the local computer, users can still add the network printer. This policy setting does not affect a user's ability to add a local printer.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -84,45 +64,20 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a computer restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
It may be appropriate in some organizations to allow users to install printer drivers on their own workstations. However, you should allow only administrators, not users, to do so on servers because printer driver installation on a server may unintentionally cause the computer to become less stable. A malicious user could install inappropriate printer drivers in a deliberate attempt to damage the computer, or a user might accidentally install malicious software that masquerades as a printer driver.
-
### Countermeasure
-
Enable the **Devices: Prevent users from installing printer drivers** setting.
-
### Potential impact
-
Only members of the Administrator, Power Users, or Server Operator groups can install printers on the servers. If this policy setting is enabled but the driver for a network printer already exists on the local computer, users can still add the network printer.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/devices-restrict-cd-rom-access-to-locally-logged-on-user-only.md b/windows/keep-secure/devices-restrict-cd-rom-access-to-locally-logged-on-user-only.md
index 4a6476a263..d4a806d762 100644
--- a/windows/keep-secure/devices-restrict-cd-rom-access-to-locally-logged-on-user-only.md
+++ b/windows/keep-secure/devices-restrict-cd-rom-access-to-locally-logged-on-user-only.md
@@ -2,50 +2,30 @@
title: Devices Restrict CD-ROM access to locally logged-on user only (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Devices Restrict CD-ROM access to locally logged-on user only security policy setting.
ms.assetid: 8b8f44bb-84ce-4f18-af30-ab89910e234d
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Devices: Restrict CD-ROM access to locally logged-on user only
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **Devices: Restrict CD-ROM access to locally logged-on user only** security policy setting.
-
## Reference
-
-
This policy setting determines whether a CD is accessible to local and remote users simultaneously. If you enable this policy setting, only the interactively logged-on user is allowed to access removable CDs. If this policy setting is enabled and no one is logged on interactively, the CD can be accessed over the network.
-
The security benefit of enabling this policy setting is small because it only prevents network users from accessing the drive when someone is logged on to the local console of the system at the same time. Additionally, CD drives are not automatically made available as network shared drives; you must deliberately choose to share the drive. This is important when administrators are installing software or copying data from a CD-ROM, and they do not want network users to be able to execute the applications or view the data.
-
If this policy setting is enabled, users who connect to the server over the network will not be able to use any CD drives that are installed on the server when anyone is logged on to the local console of the server. Enabling this policy setting is not suitable for a system that serves as a CD jukebox for network users.
-
### Possible values
-
- Enabled
-
- Disabled
-
- Not defined
-
### Best practices
-
- Best practices are dependent on your security and user accessibility requirements for CD drives.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -84,45 +64,20 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
A remote user could potentially access a mounted CD that contains sensitive information. This risk is small because CD drives are not automatically made available as shared drives; you must deliberately choose to share the drive. However, you can deny network users the ability to view data or run applications from removable media on the server.
-
### Countermeasure
-
Enable the **Devices: Restrict CD-ROM drive access to locally logged-on user only** setting.
-
### Potential impact
-
Users who connect to the server over the network cannot use any CD drives that are installed on the server when anyone is logged on to the local console of the server. System tools that require access to the CD drive will fail. For example, the Volume Shadow Copy service attempts to access all CD and floppy disk drives that are present on the computer when it initializes, and if the service cannot access one of these drives, it fails. This condition causes the Windows Backup tool to fail if volume shadow copies were specified for the backup job. Any non-Microsoft backup products that use volume shadow copies also fail. This policy setting would not be suitable for a computer that serves as a CD jukebox for network users.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/devices-restrict-floppy-access-to-locally-logged-on-user-only.md b/windows/keep-secure/devices-restrict-floppy-access-to-locally-logged-on-user-only.md
index ade06f8756..c031c438a6 100644
--- a/windows/keep-secure/devices-restrict-floppy-access-to-locally-logged-on-user-only.md
+++ b/windows/keep-secure/devices-restrict-floppy-access-to-locally-logged-on-user-only.md
@@ -2,50 +2,30 @@
title: Devices Restrict floppy access to locally logged-on user only (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Devices Restrict floppy access to locally logged-on user only security policy setting.
ms.assetid: 92997910-da95-4c03-ae6f-832915423898
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Devices: Restrict floppy access to locally logged-on user only
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **Devices: Restrict floppy access to locally logged-on user only** security policy setting.
-
## Reference
-
-
This policy setting determines whether removable floppy disks are accessible to local and remote users simultaneously. Enabling this policy setting allows only the interactively logged-on user to access removable floppy disks. If this policy setting is enabled and no one is logged on interactively, the floppy disk can be accessed over the network.
-
The security benefit of enabling this policy setting is small because it only prevents network users from accessing the floppy disk drive when someone is logged on to the local console of the system at the same time. Additionally, floppy disk drives are not automatically made available as network shared drives; you must deliberately choose to share the drive. This becomes important when you are installing software or copying data from a floppy disk and they do not want network users to be able to execute the applications or view the data.
-
If this policy setting is enabled, users who connect to the server over the network will not be able to use any floppy disk drives that are installed on the server when anyone is logged on to the local console of the server.
-
### Possible values
-
- Enabled
-
- Disabled
-
- Not defined
-
### Best practices
-
- Best practices are dependent on your security and user accessibility requirements for CD drives.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -84,45 +64,20 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
A remote user could potentially access a mounted floppy disk that contains sensitive information. This risk is small because floppy disk drives are not automatically shared; administrators must deliberately choose to share the drive. However, you can deny network users the ability to view data or run applications from removable media on the server.
-
### Countermeasure
-
Enable the **Devices: Restrict floppy access to locally logged-on user only** setting.
-
### Potential impact
-
Users who connect to the server over the network cannot use any floppy disk drives that are installed on the device when anyone is logged on to the local console of the server. System tools that require access to floppy disk drives fail. For example, the Volume Shadow Copy service attempts to access all CD-ROM and floppy disk drives that are present on the computer when it initializes, and if the service cannot access one of these drives, it fails. This condition causes the Windows Backup tool to fail if volume shadow copies were specified for the backup job. Any non-Microsoft backup products that use volume shadow copies also fail.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/display-a-custom-url-message-when-users-try-to-run-a-blocked-application.md b/windows/keep-secure/display-a-custom-url-message-when-users-try-to-run-a-blocked-application.md
index 1cd3b2b2c5..ea5e8e17a8 100644
--- a/windows/keep-secure/display-a-custom-url-message-when-users-try-to-run-a-blocked-application.md
+++ b/windows/keep-secure/display-a-custom-url-message-when-users-try-to-run-a-blocked-application.md
@@ -2,46 +2,25 @@
title: Display a custom URL message when users try to run a blocked app (Windows 10)
description: This topic for IT professionals describes the steps for displaying a customized message to users when an AppLocker policy denies access to an app.
ms.assetid: 9a2534a5-d1fa-48a9-93c6-989d4857cf85
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Display a custom URL message when users try to run a blocked app
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals describes the steps for displaying a customized message to users when an AppLocker policy denies access to an app.
-
Using Group Policy, AppLocker can be configured to display a message with a custom URL. You can use this URL to redirect users to a support site that contains info about why the user received the error and which apps are allowed. If you do not display a custom message when an apps is blocked, the default access denied message is displayed.
-
To complete this procedure, you must have the **Edit Setting** permission to edit a GPO. By default, members of the **Domain Admins** group, the **Enterprise Admins** group, and the **Group Policy Creator Owners** group have this permission.
-
**To display a custom URL message when users try to run a blocked app**
-
1. On the **Start** screen, type **gpmc.msc** to open the Group Policy Management Console (GPMC).
-
2. Navigate to the Group Policy Object (GPO) that you want to edit.
-
3. Right-click the GPO, and then click **Edit**.
-
4. In the console tree under **Policies\\Administrative Templates\\Windows Components**, click **File Explorer**.
-
5. In the details pane, double-click **Set a support web page link**.
-
6. Click **Enabled**, and then type the URL of the custom Web page in the **Support Web page URL** box.
-
7. Click **OK** to apply the setting.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/dll-rules-in-applocker.md b/windows/keep-secure/dll-rules-in-applocker.md
index aeabe9379e..545d8c5359 100644
--- a/windows/keep-secure/dll-rules-in-applocker.md
+++ b/windows/keep-secure/dll-rules-in-applocker.md
@@ -2,29 +2,20 @@
title: DLL rules in AppLocker (Windows 10)
description: This topic describes the file formats and available default rules for the DLL rule collection.
ms.assetid: a083fd08-c07e-4534-b0e7-1e15d932ce8f
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# DLL rules in AppLocker
-
-
**Applies to**
-
- Windows 10
-
This topic describes the file formats and available default rules for the DLL rule collection.
-
AppLocker defines DLL rules to include only the following file formats:
-
- .dll
-
- .ocx
-
The following table lists the default rules that are available for the DLL rule collection.
-
@@ -61,29 +52,14 @@ The following table lists the default rules that are available for the DLL rule
-
-
**Important**
If you use DLL rules, a DLL allow rule has to be created for each DLL that is used by all of the allowed apps
-
-
**Caution**
When DLL rules are used, AppLocker must check each DLL that an app loads. Therefore, users may experience a reduction in performance if DLL rules are used.
-
-
## Related topics
-
-
[Understanding AppLocker default rules](understanding-applocker-default-rules.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/document-group-policy-structure-and-applocker-rule-enforcement.md b/windows/keep-secure/document-group-policy-structure-and-applocker-rule-enforcement.md
index a3e357256e..e97b186290 100644
--- a/windows/keep-secure/document-group-policy-structure-and-applocker-rule-enforcement.md
+++ b/windows/keep-secure/document-group-policy-structure-and-applocker-rule-enforcement.md
@@ -2,38 +2,24 @@
title: Document the Group Policy structure and AppLocker rule enforcement (Windows 10)
description: This planning topic describes what you need to investigate, determine, and record in your application control policies plan when you use AppLocker.
ms.assetid: 389ffa8e-11fc-49ff-b0b1-89553e6fb6e5
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Document the Group Policy structure and AppLocker rule enforcement
-
-
**Applies to**
-
- Windows 10
-
This planning topic describes what you need to investigate, determine, and record in your application control policies plan when you use AppLocker.
-
## Record your findings
-
-
To complete this AppLocker planning document, you should first complete the following steps:
-
1. [Determine your application control objectives](determine-your-application-control-objectives.md)
-
2. [Create a list of apps deployed to each business group](create-list-of-applications-deployed-to-each-business-group.md)
-
3. [Select the types of rules to create](select-types-of-rules-to-create.md)
-
4. [Determine the Group Policy structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md)
-
After you determine how to structure your Group Policy Objects (GPOs) so that you can apply AppLocker policies, you should record your findings. You can use the following table to determine how many GPOs to create (or edit) and which objects they are linked to. If you decided to create custom rules to allow system files to run, note the high-level rule configuration in the **Use default rule or define new rule condition** column.
-
The following table includes the sample data that was collected when you determined your enforcement settings and the GPO structure for your AppLocker policies.
-
@@ -123,23 +109,10 @@ The following table includes the sample data that was collected when you determi
-
-
## Next steps
-
-
After you have determined the Group Policy structure and rule enforcement strategy for each business group's apps, the following tasks remain:
-
- [Plan for AppLocker policy management](plan-for-applocker-policy-management.md)
-
- [Create your AppLocker planning document](create-your-applocker-planning-document.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/document-your-application-control-management-processes.md b/windows/keep-secure/document-your-application-control-management-processes.md
index c5d5c7ecf4..b5a9cd95a7 100644
--- a/windows/keep-secure/document-your-application-control-management-processes.md
+++ b/windows/keep-secure/document-your-application-control-management-processes.md
@@ -2,52 +2,31 @@
title: Document your application control management processes (Windows 10)
description: This planning topic describes the AppLocker policy maintenance information to record for your design document.
ms.assetid: 6397f789-0e36-4933-9f86-f3f6489cf1fb
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Document your application control management processes
-
-
**Applies to**
-
- Windows 10
-
This planning topic describes the AppLocker policy maintenance information to record for your design document.
-
## Record your findings
-
-
To complete this AppLocker planning document, you should first complete the following steps:
-
1. [Determine your application control objectives](determine-your-application-control-objectives.md)
-
2. [Create a list of apps deployed to each business group](create-list-of-applications-deployed-to-each-business-group.md)
-
3. [Select the types of rules to create](select-types-of-rules-to-create.md)
-
4. [Determine the Group Policy structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md)
-
5. [Plan for AppLocker policy management](plan-for-applocker-policy-management.md)
-
The three key areas to determine for AppLocker policy management are:
-
1. Support policy
-
Document the process that you will use for handling calls from users who have attempted to run a blocked app, and ensure that support personnel know recommended troubleshooting steps and escalation points for your policy.
-
2. Event processing
-
Document whether events will be collected in a central location, how that store will be archived, and whether the events will be processed for analysis.
-
3. Policy maintenance
-
Detail how rules will be added to the policy, in which Group Policy Object (GPO) the rules should be defined, and how to modify rules when apps are retired, updated, or added.
-
The following table contains the added sample data that was collected when determining how to maintain and manage AppLocker policies.
-
@@ -144,17 +123,11 @@ The following table contains the added sample data that was collected when deter
-
-
The following two tables illustrate examples of documenting considerations to maintain and manage AppLocker policies.
-
**Event processing policy**
-
One discovery method for app usage is to set the AppLocker enforcement mode to **Audit only**. This will write events to the AppLocker logs, which can be managed and analyzed like other Windows logs. After apps have been identified, you can begin to develop policies regarding the processing and access to AppLocker events.
-
The following table is an example of what to consider and record.
-
@@ -189,15 +162,10 @@ The following table is an example of what to consider and record.
-
-
**Policy maintenance policy**
-
When applications are identified and policies are created for application control, then you can begin documenting how you intend to update those policies.
-
The following table is an example of what to consider and record.
-
@@ -240,21 +208,9 @@ The following table is an example of what to consider and record.
-
-
## Next steps
-
-
After you have determined your application control management strategy for each of the business group's applications, the following task remains:
-
- [Create your AppLocker planning document](create-your-applocker-planning-document.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/document-your-application-list.md b/windows/keep-secure/document-your-application-list.md
index 89cf353d55..1b7c7906fa 100644
--- a/windows/keep-secure/document-your-application-list.md
+++ b/windows/keep-secure/document-your-application-list.md
@@ -2,34 +2,22 @@
title: Document your app list (Windows 10)
description: This planning topic describes the app information that you should document when you create a list of apps for AppLocker policies.
ms.assetid: b155284b-f75d-4405-aecf-b74221622dc0
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Document your app list
-
-
**Applies to**
-
- Windows 10
-
This planning topic describes the app information that you should document when you create a list of apps for AppLocker policies.
-
## Record your findings
-
-
**Apps**
-
Record the name of the app, whether it is signed as indicated by the publisher's name, and whether it is a mission critical, business productivity, optional, or personal app. Later, as you manage your rules, AppLocker displays this information in the format shown in the following example: *MICROSOFT OFFICE INFOPATH signed by O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US*.
-
**Installation path**
-
Record the installation path of the apps. For example, Microsoft Office 2016 installs files to *%programfiles%\\Microsoft Office\\Office16\\*, which is *C:\\Program Files\\Microsoft Office\\Office16\\* on most devices.
-
The following table provides an example of how to list applications for each business group at the early stage of designing your application control policies. Eventually, as more planning information is added to the list, the information can be used to build AppLocker rules.
-
@@ -92,62 +80,30 @@ The following table provides an example of how to list applications for each bus
-
-
**Note**
AppLocker only supports publisher rules for Universal Windows apps. Therefore, collecting the installation path information for Universal Windows apps is not necessary.
-
-
**Event processing**
-
As you create your list of apps, you need to consider how to manage the events that are generated by user access, or you need to deny running those apps to make your users as productive as possible. The following list is an example of what to consider and what to record:
-
- Will event forwarding be implemented for AppLocker events?
-
- What is the location of the AppLocker event collection?
-
- Should an event archival policy be implemented?
-
- Will the events be analyzed and how often?
-
- Should a security policy be in place for event collection?
-
**Policy maintenance**
-
As you create your list of apps, you need to consider how to manage and maintain the policies that you will eventually create. The following list is an example of what to consider and what to record:
-
- How will rules be updated for emergency app access and permanent access?
-
- How will apps be removed?
-
- How many older versions of the same app will be maintained?
-
- How will new apps be introduced?
-
## Next steps
-
-
After you have created the list of applications, the next step is to identify the rule collections, which will become the application control policies. This information can be added to the table under the following columns:
-
- Use default rule or define new rule condition
-
- Allow or deny
-
- GPO name
-
To identify the rule collections, see the following topics:
-
- [Select the types of rules to create](select-types-of-rules-to-create.md)
-
- [Determine Group Policy structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/document-your-applocker-rules.md b/windows/keep-secure/document-your-applocker-rules.md
index 9abb8817ee..97bd6545ef 100644
--- a/windows/keep-secure/document-your-applocker-rules.md
+++ b/windows/keep-secure/document-your-applocker-rules.md
@@ -2,40 +2,25 @@
title: Document your AppLocker rules (Windows 10)
description: This topic describes what rule conditions to associate with each file, how to associate the rule conditions with each file, the source of the rule, and whether the file should be included or excluded.
ms.assetid: 91a198ce-104a-45ff-b49b-487fb40cd2dd
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Document your AppLocker rules
-
-
**Applies to**
-
- Windows 10
-
This topic describes what rule conditions to associate with each file, how to associate the rule conditions with each file, the source of the rule, and whether the file should be included or excluded.
-
## Record your findings
-
-
To complete this AppLocker planning document, you should first complete the following steps:
-
1. [Determine your application control objectives](determine-your-application-control-objectives.md)
-
2. [Create a list of apps deployed to each business group](create-list-of-applications-deployed-to-each-business-group.md)
-
3. [Select the types of rules to create](select-types-of-rules-to-create.md)
-
Document the following items for each business group or organizational unit:
-
- Whether your organization will use the built-in default AppLocker rules to allow system files to run.
-
- The types of rule conditions that you will use to create rules, stated in order of preference.
-
The following table details sample data for documenting rule type and rule condition findings. In addition, you should now consider whether to allow an app to run or deny permission for it to run. For info about these settings, see [Understanding AppLocker allow and deny actions on rules](understanding-applocker-allow-and-deny-actions-on-rules.md).
-
@@ -114,25 +99,11 @@ The following table details sample data for documenting rule type and rule condi
-
-
## Next steps
-
-
For each rule, determine whether to use the allow or deny option. Then, three tasks remain:
-
- [Determine Group Policy structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md)
-
- [Plan for AppLocker policy management](plan-for-applocker-policy-management.md)
-
- [Create your AppLocker planning document](create-your-applocker-planning-document.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/domain-controller-allow-server-operators-to-schedule-tasks.md b/windows/keep-secure/domain-controller-allow-server-operators-to-schedule-tasks.md
index de5c0393cd..9830087bd1 100644
--- a/windows/keep-secure/domain-controller-allow-server-operators-to-schedule-tasks.md
+++ b/windows/keep-secure/domain-controller-allow-server-operators-to-schedule-tasks.md
@@ -2,55 +2,33 @@
title: Domain controller Allow server operators to schedule tasks (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Domain controller Allow server operators to schedule tasks security policy setting.
ms.assetid: 198b12a4-8a5d-48e8-a752-2073b8a2cb0d
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Domain controller: Allow server operators to schedule tasks
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **Domain controller: Allow server operators to schedule tasks** security policy setting.
-
## Reference
-
-
This policy setting determines whether server operators can use the**at** command to submit jobs. If you enable this policy setting, jobs that are created by server operators by means of the **at** command run in the context of the account that runs the Task Scheduler service. By default, that is the Local System account.
-
**Note**
This security option setting affects only the scheduler tool for the **at** command. It does not affect the Task Scheduler tool.
-
-
Enabling this policy setting means jobs that are created by server operators through the **at** command will be executed in the context of the account that is running that service—by default, that is the Local System account. This means that server operators can perform tasks that the Local System account is able to do, but server operators would normally not be able to do, such as add their account to the local Administrators group.
-
The impact of enabling this policy setting should be small for most organizations. Users, including those in the Server Operators group, will still be able to create jobs by using the Task Scheduler Wizard, but those jobs will run in the context of the account that the user authenticates with when setting up the job.
-
### Possible values
-
- Enabled
-
- Disabled
-
- Not defined
-
### Best practices
-
- Best practices for this policy are dependent on your security and operational requirements for task scheduling.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -89,49 +67,22 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Command-line tools
-
The **at** command schedules commands and programs to run on a computer at a specified time and date. The Schedule service must be running to use the **at** command.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Tasks that run under the context of the Local System account can affect resources that are at a higher privilege level than the user account that scheduled the task.
-
### Countermeasure
-
Disable the **Domain controller: Allow server operators to schedule tasks** setting.
-
### Potential impact
-
The impact should be small for most organizations. Users (including those in the Server Operators group) can still create jobs by means of the Task Scheduler snap-in. However, those jobs run in the context of the account that the user authenticates with when setting up the job.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/domain-controller-ldap-server-signing-requirements.md b/windows/keep-secure/domain-controller-ldap-server-signing-requirements.md
index 72848b8339..50f94a37d3 100644
--- a/windows/keep-secure/domain-controller-ldap-server-signing-requirements.md
+++ b/windows/keep-secure/domain-controller-ldap-server-signing-requirements.md
@@ -2,57 +2,34 @@
title: Domain controller LDAP server signing requirements (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Domain controller LDAP server signing requirements security policy setting.
ms.assetid: fe122179-7571-465b-98d0-b8ce0f224390
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Domain controller: LDAP server signing requirements
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **Domain controller: LDAP server signing requirements** security policy setting.
-
## Reference
-
-
This policy setting determines whether the Lightweight Directory Access Protocol (LDAP) server requires LDAP clients to negotiate data signing.
-
Unsigned network traffic is susceptible to man-in-the-middle attacks, where an intruder captures packets between the server and the client device and modifies them before forwarding them to the client device. In the case of an LDAP server, this means that a malicious user can cause a client device to make decisions based on false records from the LDAP directory. You can lower the risk of a malicious user accomplishing this in a corporate network by implementing strong physical security measures to protect the network infrastructure. Furthermore, implementing Internet Protocol security (IPsec) Authentication Header mode, which provides mutual authentication and packet integrity for IP traffic, can make all types of man-in-the-middle attacks extremely difficult.
-
This setting does not have any impact on LDAP simple bind or LDAP simple bind through SSL.
-
If signing is required, then LDAP simple bind and LDAP simple bind through SSL requests are rejected.
-
**Caution**
If you set the server to Require signature, you must also set the client device. Not setting the client device results in loss of connection with the server.
-
-
### Possible values
-
- None. Data signatures are not required to bind with the server. If the client computer requests data signing, the server supports it.
-
- Require signature. The LDAP data-signing option must be negotiated unless Transport Layer Security/Secure Sockets Layer (TLS/SSL) is in use.
-
- Not defined.
-
### Best practices
-
- It is advisable to set **Domain controller: LDAP server signing requirements** to **Require signature**. Clients that do not support LDAP signing will be unable to execute LDAP queries against the domain controllers.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -91,45 +68,20 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Unsigned network traffic is susceptible to man-in-the-middle attacks. In such attacks, an intruder captures packets between the server and the client device, modifies them, and then forwards them to the client device. Where LDAP servers are concerned, an attacker could cause a client device to make decisions that are based on false records from the LDAP directory. To lower the risk of such an intrusion in an organization's network, you can implement strong physical security measures to protect the network infrastructure. You could also implement Internet Protocol security (IPsec) Authentication Header mode, which performs mutual authentication and packet integrity for IP traffic to make all types of man-in-the-middle attacks extremely difficult.
-
### Countermeasure
-
Configure the **Domain controller: LDAP server signing requirements** setting to **Require signature**.
-
### Potential impact
-
Client device that do not support LDAP signing cannot run LDAP queries against the domain controllers.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/domain-controller-refuse-machine-account-password-changes.md b/windows/keep-secure/domain-controller-refuse-machine-account-password-changes.md
index 8b810e64e2..acab069b02 100644
--- a/windows/keep-secure/domain-controller-refuse-machine-account-password-changes.md
+++ b/windows/keep-secure/domain-controller-refuse-machine-account-password-changes.md
@@ -2,52 +2,31 @@
title: Domain controller Refuse machine account password changes (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Domain controller Refuse machine account password changes security policy setting.
ms.assetid: 5a7fa2e2-e1a8-4833-90f7-aa83e3b456a9
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Domain controller: Refuse machine account password changes
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **Domain controller: Refuse machine account password changes** security policy setting.
-
## Reference
-
-
This policy setting enables or disables blocking a domain controller from accepting password change requests for machine accounts. By default, devices joined to the domain change their machine account passwords every 30 days. If enabled, the domain controller will refuse machine account password change requests.
-
### Possible values
-
- Enabled
-
When enabled, this setting does not allow a domain controller to accept any changes to a machine account's password.
-
- Disabled
-
When disabled, this setting allows a domain controller to accept any changes to a machine account's password.
-
- Not defined
-
Same as Disabled.
-
### Best practices
-
- Enabling this policy setting on all domain controllers in a domain prevents domain members from changing their machine account passwords. This, in turn, leaves those passwords susceptible to attack. Make sure that this conforms to your overall security policy for the domain.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -86,45 +65,20 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
If you enable this policy setting on all domain controllers in a domain, domain members cannot change their machine account passwords, and those passwords are more susceptible to attack.
-
### Countermeasure
-
Disable the **Domain controller: Refuse machine account password changes** setting.
-
### Potential impact
-
None. This is the default configuration.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md b/windows/keep-secure/domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md
index 951b940928..b6ebe0166a 100644
--- a/windows/keep-secure/domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md
+++ b/windows/keep-secure/domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md
@@ -2,81 +2,46 @@
title: Domain member Digitally encrypt or sign secure channel data (always) (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Domain member Digitally encrypt or sign secure channel data (always) security policy setting.
ms.assetid: 4480c7cb-adca-4f29-b4b8-06eb68d272bf
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Domain member: Digitally encrypt or sign secure channel data (always)
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **Domain member: Digitally encrypt or sign secure channel data (always)** security policy setting.
-
## Reference
-
-
This setting determines whether all secure channel traffic that is initiated by the domain member meets minimum security requirements. Specifically, it determines whether all secure channel traffic that is initiated by the domain member must be signed or encrypted. Logon information that is transmitted over the secure channel is always encrypted regardless of whether the encryption of all other secure channel traffic is negotiated.
-
The following policy settings determine whether a secure channel can be established with a domain controller that is not capable of signing or encrypting secure channel traffic:
-
- Domain member: Digitally encrypt or sign secure channel data (always)
-
- [Domain member: Digitally encrypt secure channel data (when possible)](domain-member-digitally-encrypt-secure-channel-data-when-possible.md)
-
- [Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md)
-
Setting **Domain member: Digitally encrypt or sign secure channel data (always)** to **Enabled** prevents establishing a secure channel with any domain controller that cannot sign or encrypt all secure channel data.
-
To protect authentication traffic from man-in-the-middle, replay, and other types of network attacks, Windows-based computers create a communication channel through NetLogon called secure channels. These channels authenticate machine accounts. They also authenticate user accounts when a remote user connects to a network resource and the user account exists in a trusted domain. This is called pass-through authentication, and it allows a device running Windows othat has joined a domain to have access to the user account database in its domain and in any trusted domains.
-
To enable the **Domain member: Digitally encrypt or sign secure channel data (always)** policy setting on a member workstation or server, all domain controllers in the domain that the member belongs to must be capable of signing or encrypting all secure-channel data.
-
Enabling the **Domain member: Digitally encrypt or sign secure channel data (always)** policy setting automatically enables the [Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md) policy setting.
-
When a device joins a domain, a machine account is created. After joining the domain, the device uses the password for that account to create a secure channel with the domain controller for its domain every time it restarts. This secure channel is used to perform operations such as NTLM pass-through authentication and LSA SID/name Lookup. Requests that are sent on the secure channel are authenticated—and sensitive information such as passwords are encrypted—but the integrity of the channel is not checked, and not all information is encrypted. If a system is set to always encrypt or sign secure channel data, a secure channel cannot be established with a domain controller that is not capable of signing or encrypting all secure channel traffic. If the computer is configured to encrypt or sign secure channel data when possible, a secure channel can be established, but the level of encryption and signing is negotiated.
-
### Possible values
-
- Enabled
-
The policy [Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md) is assumed to be enabled regardless of its current setting. This ensures that the domain member attempts to negotiate at least signing of the secure channel traffic.
-
- Disabled
-
The encryption and signing of all secure channel traffic is negotiated with the domain controller, in which case the level of signing and encryption depends on the version of the domain controller and the settings of the following policies:
-
1. [Domain member: Digitally encrypt secure channel data (when possible)](domain-member-digitally-encrypt-secure-channel-data-when-possible.md)
-
2. [Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md)
-
- Not defined
-
### Best practices
-
- Set **Domain member: Digitally encrypt or sign secure channel data (always)** to **Enabled**.
-
- Set [Domain member: Digitally encrypt secure channel data (when possible)](domain-member-digitally-encrypt-secure-channel-data-when-possible.md) to **Enabled**.
-
- Set [Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md) to **Enabled**.
-
**Note**
You can enable the policy settings [Domain member: Digitally encrypt secure channel data (when possible)](domain-member-digitally-encrypt-secure-channel-data-when-possible.md) and [Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md) on all devices in the domain that support these policy settings without affecting earlier-version clients and applications.
-
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -115,55 +80,25 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Group Policy
-
Distribution of this policy through Group Policy overrides the Local Security Policy setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
When a device joins a domain, a machine account is created. After it joins the domain, the device uses the password for that account to create a secure channel with the domain controller for its domain every time it restarts. Requests that are sent on the secure channel are authenticated—and sensitive information such as passwords are encrypted—but the channel is not integrity-checked, and not all information is encrypted. If a device is configured to always encrypt or sign secure channel data but the domain controller cannot sign or encrypt any portion of the secure channel data, the computer and domain controller cannot establish a secure channel. If the device is configured to encrypt or sign secure channel data, when possible, a secure channel can be established, but the level of encryption and signing is negotiated.
-
### Countermeasure
-
Select one of the following settings as appropriate for your environment to configure the computers in your domain to encrypt or sign secure channel data.
-
- **Domain member: Digitally encrypt or sign secure channel data (always)**
-
- [Domain member: Digitally encrypt secure channel data (when possible)](domain-member-digitally-encrypt-secure-channel-data-when-possible.md)
-
- [Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md)
-
### Potential impact
-
Digital encryption and signing of the secure channel is a good idea because the secure channel protects domain credentials as they are sent to the domain controller.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/domain-member-digitally-encrypt-secure-channel-data-when-possible.md b/windows/keep-secure/domain-member-digitally-encrypt-secure-channel-data-when-possible.md
index d27e70e4a0..693a34601d 100644
--- a/windows/keep-secure/domain-member-digitally-encrypt-secure-channel-data-when-possible.md
+++ b/windows/keep-secure/domain-member-digitally-encrypt-secure-channel-data-when-possible.md
@@ -2,73 +2,42 @@
title: Domain member Digitally encrypt secure channel data (when possible) (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Domain member Digitally encrypt secure channel data (when possible) security policy setting.
ms.assetid: 73e6023e-0af3-4531-8238-82f0f0e4965b
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Domain member: Digitally encrypt secure channel data (when possible)
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **Domain member: Digitally encrypt secure channel data (when possible)** security policy setting.
-
## Reference
-
-
This setting determines whether all secure channel traffic that is initiated by the domain member meets minimum security requirements. Specifically, it determines whether all secure channel traffic that is initiated by the domain member must be encrypted. Logon information that is transmitted over the secure channel is always encrypted regardless of whether the encryption of all other secure channel traffic is negotiated.
-
In addition to this policy setting, the following policy settings determine whether a secure channel can be established with a domain controller that is not capable of signing or encrypting secure channel traffic:
-
- [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md)
-
- [Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md)
-
Setting **Domain member: Digitally encrypt or sign secure channel data (always)** to **Enabled** prevents establishing a secure channel with any domain controller that cannot sign or encrypt all secure channel data.
-
To protect authentication traffic from man-in-the-middle, replay, and other types of network attacks, Windows-based computers create a communication channel through NetLogon called secure channels. These channels authenticate machine accounts. They also authenticate user accounts when a remote user connects to a network resource and the user account exists in a trusted domain. This is called pass-through authentication, and it allows a computer running the Windows operating system that has joined a domain to have access to the user account database in its domain and in any trusted domains.
-
Enabling the [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md) policy setting automatically enables the **Domain member: Digitally sign secure channel data (when possible)** policy setting.
-
When a device joins a domain, a machine account is created. After joining the domain, the device uses the password for that account to create a secure channel with the domain controller for its domain every time it restarts. This secure channel is used to perform operations such as NTLM pass through authentication and LSA SID/name Lookup. Requests that are sent on the secure channel are authenticated—and sensitive information such as passwords are encrypted—but the integrity of the channel is not checked, and not all information is encrypted. If a system is set to always encrypt or sign secure channel data, a secure channel cannot be established with a domain controller that is not capable of signing or encrypting all secure channel traffic. If the computer is configured to encrypt or sign secure channel data when possible, a secure channel can be established, but the level of encryption and signing is negotiated.
-
### Possible values
-
- Enabled
-
The domain member will request encryption of all secure channel traffic. If the domain controller supports encryption of all secure channel traffic, then all secure channel traffic will be encrypted. Otherwise, only logon information that is transmitted over the secure channel will be encrypted.
-
- Disabled
-
The domain member will not attempt to negotiate secure channel encryption.
-
**Note**
If the security policy setting [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md) is enabled, this setting will be overwritten.
-
-
- Not defined
-
### Best practices
-
- Set [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md) to **Enabled**.
-
- Set **Domain member: Digitally encrypt secure channel data (when possible)** to **Enabled**.
-
- Set [Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md) to **Enabled**.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -107,55 +76,25 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Group Policy
-
Distribution of this policy through Group Policy does not override the Local Security Policy setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
When a device joins a domain, a machine account is created. After it joins the domain, the device uses the password for that account to create a secure channel with the domain controller for its domain every time it restarts. Requests that are sent on the secure channel are authenticated—and sensitive information such as passwords are encrypted—but the channel is not integrity-checked, and not all information is encrypted. If a device is configured to always encrypt or sign secure channel data but the domain controller cannot sign or encrypt any portion of the secure channel data, the computer and domain controller cannot establish a secure channel. If the computer is configured to encrypt or sign secure channel data when possible, a secure channel can be established, but the level of encryption and signing is negotiated.
-
### Countermeasure
-
Select one of the following settings as appropriate for your environment to configure the computers in your domain to encrypt or sign secure channel data:
-
- [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md)
-
- **Domain member: Digitally encrypt secure channel data (when possible)**
-
- [Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md)
-
### Potential impact
-
Digital signing of the secure channel is a good idea because it protects domain credentials as they are sent to the domain controller.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/domain-member-digitally-sign-secure-channel-data-when-possible.md b/windows/keep-secure/domain-member-digitally-sign-secure-channel-data-when-possible.md
index d3e4df1b1f..670f0b9024 100644
--- a/windows/keep-secure/domain-member-digitally-sign-secure-channel-data-when-possible.md
+++ b/windows/keep-secure/domain-member-digitally-sign-secure-channel-data-when-possible.md
@@ -2,75 +2,43 @@
title: Domain member Digitally sign secure channel data (when possible) (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Domain member Digitally sign secure channel data (when possible) security policy setting.
ms.assetid: a643e491-4f45-40ea-b12c-4dbe47e54f34
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Domain member: Digitally sign secure channel data (when possible)
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **Domain member: Digitally sign secure channel data (when possible)** security policy setting.
-
## Reference
-
-
This setting determines whether all secure channel traffic that is initiated by the domain member meets minimum security requirements. Specifically, it determines whether all secure channel traffic that is initiated by the domain member must be signed. Logon information that is transmitted over the secure channel is always encrypted regardless of whether the encryption of all other secure channel traffic is negotiated.
-
The following policy settings determine whether a secure channel can be established with a domain controller that is not capable of signing or encrypting secure channel traffic:
-
- [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md)
-
- [Domain member: Digitally encrypt secure channel data (when possible)](domain-member-digitally-encrypt-secure-channel-data-when-possible.md)
-
- Domain member: Digitally sign secure channel data (when possible)
-
Setting [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md) to **Enabled** prevents establishing a secure channel with any domain controller that cannot sign or encrypt all secure channel data.
-
To protect authentication traffic from man-in-the-middle, replay, and other types of network attacks, Windows-based computers create a communication channel through NetLogon called secure channels. These channels authenticate computer accounts. They also authenticate user accounts when a remote user connects to a network resource and the user account exists in a trusted domain. This is called pass-through authentication, and it allows a computer running the Windows operating system that has joined a domain to have access to the user account database in its domain and in any trusted domains.
-
Enabling the [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md) policy setting automatically enables the **Domain member: Digitally sign secure channel data (when possible)** policy setting.
-
When a device joins a domain, a machine account is created. After joining the domain, the device uses the password for that account to create a secure channel with the domain controller for its domain every time it restarts. This secure channel is used to perform operations such as NTLM pass through authentication and LSA SID/name Lookup. Requests that are sent on the secure channel are authenticated—and sensitive information such as passwords are encrypted—but the integrity of the channel is not checked, and not all information is encrypted. If a system is set to always encrypt or sign secure channel data, a secure channel cannot be established with a domain controller that is not capable of signing or encrypting all secure channel traffic. If the computer is configured to encrypt or sign secure channel data when possible, a secure channel can be established, but the level of encryption and signing is negotiated.
-
### Possible values
-
- Enabled
-
The domain member will request signing of all secure channel traffic. If the domain controller supports signing of all secure channel traffic, then all secure channel traffic will be signed which ensures that it cannot be tampered with in transit.
-
- Disabled
-
Signing will not be negotiated unless the policy [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md) is enabled.
-
- Not defined
-
### Best practices
-
- Set [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md) to **Enabled**.
-
- Set [Domain member: Digitally encrypt secure channel data (when possible)](domain-member-digitally-encrypt-secure-channel-data-when-possible.md) to **Enabled**.
-
- Set **Domain member: Digitally sign secure channel data (when possible)** to **Enabled**.
-
**Note**
You can enable the other two policy settings, Domain member: [Domain member: Digitally encrypt secure channel data (when possible)](domain-member-digitally-encrypt-secure-channel-data-when-possible.md) and **Domain member: Digitally sign secure channel data (when possible)**, on all devices joined to the domain that support these policy settings without affecting earlier-version clients and applications.
-
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -109,55 +77,25 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Group Policy
-
Distribution of this policy through Group Policy does not override the Local Security Policy setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
When a device joins a domain, a machine account is created. After it joins the domain, the device uses the password for that account to create a secure channel with the domain controller for its domain every time it restarts. Requests that are sent on the secure channel are authenticated—and sensitive information such as passwords are encrypted—but the channel is not integrity-checked, and not all information is encrypted. If a device is configured to always encrypt or sign secure channel data but the domain controller cannot sign or encrypt any portion of the secure channel data, the computer and domain controller cannot establish a secure channel. If the computer is configured to encrypt or sign secure channel data when possible, a secure channel can be established, but the level of encryption and signing is negotiated.
-
### Countermeasure
-
Because these policies are closely related and useful depending on your environment, select one of the following settings as appropriate to configure the devices in your domain to encrypt or sign secure channel data when possible.
-
- [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md)
-
- [Domain member: Digitally encrypt secure channel data (when possible)](domain-member-digitally-encrypt-secure-channel-data-when-possible.md)
-
- **Domain member: Digitally sign secure channel data (when possible)**
-
### Potential impact
-
Digital signing of the secure channel is a good idea because the secure channel protects domain credentials as they are sent to the domain controller.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/domain-member-disable-machine-account-password-changes.md b/windows/keep-secure/domain-member-disable-machine-account-password-changes.md
index e25f87d1fa..39fdae996b 100644
--- a/windows/keep-secure/domain-member-disable-machine-account-password-changes.md
+++ b/windows/keep-secure/domain-member-disable-machine-account-password-changes.md
@@ -2,50 +2,30 @@
title: Domain member Disable machine account password changes (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Domain member Disable machine account password changes security policy setting.
ms.assetid: 1f660300-a07a-4243-a09f-140aa1ab8867
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Domain member: Disable machine account password changes
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **Domain member: Disable machine account password changes** security policy setting.
-
## Reference
-
-
The **Domain member: Disable machine account password changes** policy setting determines whether a domain member periodically changes its machine account password. Setting its value to **Enabled** prevents the domain member from changing the machine account password. Setting it to **Disabled** allows the domain member to change the machine account password as specified by the value of the [Domain member: Maximum machine account password age](domain-member-maximum-machine-account-password-age.md) policy setting, which is every 30 days by default.
-
By default, devices that belong to a domain are automatically required to change the passwords for their accounts every 30 days. Devices that are no longer able to automatically change their machine password are at risk of a malicious user determining the password for the system's domain account.
-
Verify that the **Domain member: Disable machine account password changes** option is set to **Disabled**.
-
### Possible values
-
- Enabled
-
- Disabled
-
### Best practices
-
1. Do not enable this policy setting. Machine account passwords are used to establish secure channel communications between members and domain controllers and between the domain controllers within the domain. After it is established, the secure channel transmits sensitive information that is necessary for making authentication and authorization decisions.
-
2. Do not use this policy setting in an attempt to support dual-boot scenarios that use the same machine account. If you want to dual-boot installations that are joined to the same domain, give the two installations different computer names. This policy setting was added to the Windows operating system to make it easier for organizations that stockpile pre-built computers that are put into production months later; those devices do not have to be rejoined to the domain.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -84,45 +64,20 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
By default, devices running Windows Server that belong to a domain automatically change their passwords for their accounts every certain number of days, typically 30. If you disable this policy setting, devices that run Windows Server retain the same passwords as their machine accounts. Devices that cannot automatically change their account password are at risk from an attacker who could determine the password for the machine's domain account.
-
### Countermeasure
-
Verify that the **Domain member: Disable machine account password changes** setting is configured to **Disabled**.
-
### Potential impact
-
None. This is the default configuration.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/domain-member-maximum-machine-account-password-age.md b/windows/keep-secure/domain-member-maximum-machine-account-password-age.md
index 78a8d9b843..9deffaa2c2 100644
--- a/windows/keep-secure/domain-member-maximum-machine-account-password-age.md
+++ b/windows/keep-secure/domain-member-maximum-machine-account-password-age.md
@@ -2,48 +2,29 @@
title: Domain member Maximum machine account password age (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Domain member Maximum machine account password age security policy setting.
ms.assetid: 0ec6f7c1-4d82-4339-94c0-debb2d1ac109
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Domain member: Maximum machine account password age
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **Domain member: Maximum machine account password age** security policy setting.
-
## Reference
-
-
The **Domain member: Maximum machine account password age** policy setting determines the maximum allowable age for a machine account password.
-
In Active Directory–based domains, each device has an account and password, just like every user. By default, the domain members automatically change their domain password every 30 days. Increasing this interval significantly, or setting it to **0** so that the device no longer change their passwords, gives a malicious user more time to undertake a brute-force password-guessing attack against one of the machine accounts.
-
### Possible values
-
- User-defined number of days between 0 and 999
-
- Not defined.
-
### Best practices
-
1. It is often advisable to set **Domain member: Maximum machine account password age** to about 30 days.
-
2. Some organizations pre-build devices and then store them for later use or ship them to remote locations. If the machine's account has expired, it will no longer be able to authenticate with the domain. Devices that cannot authenticate with the domain must be removed from the domain and rejoined to it. For this reason, some organizations might want to create a special organizational unit (OU) for computers that are prebuilt, and configure the value for this policy setting to a larger number of days.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -82,45 +63,20 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a computer restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
In Active Directory–based domains, each device has an account and password, just as every user does. By default, the domain members automatically change their domain password every 30 days. If you increase this interval significantly, or set it to 0 so that the computers no longer change their passwords, an attacker has more time to undertake a brute-force attack to guess the password of one or more computer accounts.
-
### Countermeasure
-
Configure the **Domain member: Maximum machine account password age** setting to 30 days.
-
### Potential impact
-
None. This is the default configuration.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/domain-member-require-strong-windows-2000-or-later-session-key.md b/windows/keep-secure/domain-member-require-strong-windows-2000-or-later-session-key.md
index b230c318e1..2a95144b2d 100644
--- a/windows/keep-secure/domain-member-require-strong-windows-2000-or-later-session-key.md
+++ b/windows/keep-secure/domain-member-require-strong-windows-2000-or-later-session-key.md
@@ -2,52 +2,31 @@
title: Domain member Require strong (Windows 2000 or later) session key (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Domain member Require strong (Windows 2000 or later) session key security policy setting.
ms.assetid: 5ab8993c-5086-4f09-bc88-1b27454526bd
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Domain member: Require strong (Windows 2000 or later) session key
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **Domain member: Require strong (Windows 2000 or later) session key** security policy setting.
-
## Reference
-
-
The **Domain member: Require strong (Windows 2000 or later) session key** policy setting determines whether a secure channel can be established with a domain controller that is not capable of encrypting secure channel traffic with a strong, 128-bit session key. Enabling this policy setting prevents establishing a secure channel with any domain controller that cannot encrypt secure channel data with a strong key. Disabling this policy setting allows 64-bit session keys.
-
Whenever possible, you should take advantage of these stronger session keys to help protect secure channel communications from eavesdropping and session-hijacking network attacks. Eavesdropping is a form of hacking in which network data is read or altered in transit. The data can be modified to hide or change the name of the sender, or it can be redirected.
-
### Possible values
-
- Enabled
-
When enabled on a member workstation or server, all domain controllers in the domain that the member belongs to must be capable of encrypting secure channel data with a strong, 128-bit key. This means that all such domain controllers must be running at least Windows 2000 Server.
-
- Disabled
-
Allows 64-bit session keys to be used.
-
- Not defined.
-
### Best practices
-
- It is advisable to set **Domain member: Require strong (Windows 2000 or later) session key** to Enabled. Enabling this policy setting ensures that all outgoing secure channel traffic will require a strong encryption key. Disabling this policy setting requires that key strength be negotiated. Only enable this option if the domain controllers in all trusted domains support strong keys. By default, this value is disabled.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -86,55 +65,25 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Group Policy
-
Misuse of this policy setting is a common error that can cause data loss or problems with data access or security.
-
You will you be able to join devices that do not support this policy setting to domains where the domain controllers have this policy setting enabled.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Session keys that are used to establish secure channel communications between domain controllers and member computers are much stronger starting with Windows 2000.
-
Whenever possible, you should take advantage of these stronger session keys to help protect secure channel communications from attacks that attempt to hijack network sessions and eavesdrop. (Eavesdropping is a form of hacking in which network data is read or altered in transit. The data can be modified to hide or change the sender, or be redirected.)
-
### Countermeasure
-
Enable the **Domain member: Require strong (Windows 2000 or later) session key** setting.
-
If you enable this policy setting, all outgoing secure channel traffic requires a strong encryption key. If you disable this policy setting, the key strength is negotiated. You should enable this policy setting only if the domain controllers in all trusted domains support strong keys. By default, this policy setting is disabled.
-
### Potential impact
-
Devices that do not support this policy setting cannot join domains in which the domain controllers have this policy setting enabled.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/edit-an-applocker-policy.md b/windows/keep-secure/edit-an-applocker-policy.md
index b878d37679..725e1f5ac0 100644
--- a/windows/keep-secure/edit-an-applocker-policy.md
+++ b/windows/keep-secure/edit-an-applocker-policy.md
@@ -2,135 +2,70 @@
title: Edit an AppLocker policy (Windows 10)
description: This topic for IT professionals describes the steps required to modify an AppLocker policy.
ms.assetid: dbc72d1f-3fe0-46c2-aeeb-96621fce7637
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Edit an AppLocker policy
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals describes the steps required to modify an AppLocker policy.
-
You can edit an AppLocker policy by adding, changing, or removing rules. However, you cannot create a new version of the policy by importing additional rules. To modify an AppLocker policy that is in production, you should use Group Policy management software that allows you to version Group Policy Objects (GPOs). If you have created multiple AppLocker policies and need to merge them to create one AppLocker policy, you can either manually merge the policies or use the Windows PowerShell cmdlets for AppLocker. You cannot automatically merge policies by using the AppLocker snap-in. You must create one rule collection from two or more policies. The AppLocker policy is saved in XML format, and the exported policy can be edited with any text or XML editor. For info about merging policies, see [Merge AppLocker policies manually](merge-applocker-policies-manually.md) or [Merge AppLocker policies by using Set-ApplockerPolicy](merge-applocker-policies-by-using-set-applockerpolicy.md).
-
There are two methods you can use to edit an AppLocker policy:
-
- [Editing an AppLocker policy by using Group Policy](#bkmk-editapppolingpo)
-
- [Editing an AppLocker policy by using the Local Security Policy snap-in](#bkmk-editapplolnotingpo)
-
## Editing an AppLocker policy by using Group Policy
-
-
The steps to edit an AppLocker policy distributed by Group Policy include the following:
-
### Step 1: Use Group Policy management software to export the AppLocker policy from the GPO
-
AppLocker provides a feature to export and import AppLocker policies as an XML file. This allows you to modify an AppLocker policy outside your production environment. Because updating an AppLocker policy in a deployed GPO could have unintended consequences, you should first export the AppLocker policy to an XML file. For the procedure to do this, see [Export an AppLocker policy from a GPO](export-an-applocker-policy-from-a-gpo.md).
-
### Step 2: Import the AppLocker policy into the AppLocker reference PC or the PC you use for policy maintenance
-
After exporting the AppLocker policy to an XML file, you should import the XML file onto a reference PC so that you can edit the policy. For the procedure to import an AppLocker policy, see [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md).
-
**Caution**
Importing a policy onto another PC will overwrite the existing policy on that PC.
-
-
### Step 3: Use AppLocker to modify and test the rule
-
AppLocker provides ways to modify, delete, or add rules to a policy by modifying the rules within the collection.
-
- For the procedure to modify a rule, see [Edit AppLocker rules](edit-applocker-rules.md).
-
- For the procedure to delete a rule, see [Delete an AppLocker rule](delete-an-applocker-rule.md).
-
- For procedures to create rules, see:
-
- [Create a rule that uses a publisher condition](create-a-rule-that-uses-a-publisher-condition.md)
-
- [Create a rule that uses a path condition](create-a-rule-that-uses-a-path-condition.md)
-
- [Create a rule that uses a file hash condition](create-a-rule-that-uses-a-file-hash-condition.md)
-
- [Enable the DLL rule collection](enable-the-dll-rule-collection.md)
-
- For steps to test an AppLocker policy, see [Test and update an AppLocker policy](test-and-update-an-applocker-policy.md).
-
- For procedures to export the updated policy from the reference computer back into the GPO, see [Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md) and [Import an AppLocker policy into a GPO](import-an-applocker-policy-into-a-gpo.md).
-
### Step 4: Use AppLocker and Group Policy to import the AppLocker policy back into the GPO
-
For procedures to export the updated policy from the reference computer back into the GPO, see [Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md) and [Import an AppLocker policy into a GPO](import-an-applocker-policy-into-a-gpo.md).
-
**Caution**
You should never edit an AppLocker rule collection while it is being enforced in Group Policy. Because AppLocker controls what files are allowed run, making changes to a live policy can create unexpected behavior. For info about testing policies, see [Test and update an AppLocker policy](test-and-update-an-applocker-policy.md).
-
-
**Note**
If you are performing these steps by using Microsoft Advanced Group Policy Management (AGPM), check out the GPO before exporting the policy.
-
-
## Editing an AppLocker policy by using the Local Security Policy snap-in
-
-
The steps to edit an AppLocker policy distributed by using the Local Security Policy snap-in (secpol.msc) include the following tasks.
-
### Step 1: Import the AppLocker policy
-
On the PC where you maintain policies, open the AppLocker snap-in from the Local Security Policy snap-in (secpol.msc). If you exported the AppLocker policy from another PC, use AppLocker to import it onto the PC.
-
After exporting the AppLocker policy to an XML file, you should import the XML file onto a reference PC so that you can edit the policy. For the procedure to import an AppLocker policy, see [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md).
-
**Caution**
Importing a policy onto another PC will overwrite the existing policy on that PC.
-
-
### Step 2: Identify and modify the rule to change, delete, or add
-
AppLocker provides ways to modify, delete, or add rules to a policy by modifying the rules within the collection.
-
- For the procedure to modify a rule, see [Edit AppLocker rules](edit-applocker-rules.md).
-
- For the procedure to delete a rule, see [Delete an AppLocker rule](delete-an-applocker-rule.md).
-
- For procedures to create rules, see:
-
- [Create a rule that uses a publisher condition](create-a-rule-that-uses-a-publisher-condition.md)
-
- [Create a rule that uses a path condition](create-a-rule-that-uses-a-path-condition.md)
-
- [Create a rule that uses a file hash condition](create-a-rule-that-uses-a-file-hash-condition.md)
-
- [Enable the DLL rule collection](enable-the-dll-rule-collection.md)
-
### Step 3: Test the effect of the policy
-
For steps to test an AppLocker policy, see [Test and update an AppLocker policy](test-and-update-an-applocker-policy.md).
-
### Step 4: Export the policy to an XML file and propagate it to all targeted computers
-
For procedures to export the updated policy from the reference computer to targeted computers, see [Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md) and [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md).
-
## Additional resources
-
-
- For steps to perform other AppLocker policy tasks, see [Administer AppLocker](administer-applocker.md).
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/edit-applocker-rules.md b/windows/keep-secure/edit-applocker-rules.md
index e5b8372c9d..69c9a61c3a 100644
--- a/windows/keep-secure/edit-applocker-rules.md
+++ b/windows/keep-secure/edit-applocker-rules.md
@@ -2,80 +2,42 @@
title: Edit AppLocker rules (Windows 10)
description: This topic for IT professionals describes the steps to edit a publisher rule, path rule, and file hash rule in AppLocker.
ms.assetid: 80016cda-b915-46a0-83c6-5e6b0b958e32
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Edit AppLocker rules
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals describes the steps to edit a publisher rule, path rule, and file hash rule in AppLocker.
-
For more info about these rule types, see [Understanding AppLocker rule condition types](understanding-applocker-rule-condition-types.md).
-
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group Policy Object (GPO) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or in a security template. For info how to use these MMC snap-ins to administer AppLocker, see [Administer AppLocker](administer-applocker.md#bkmk-using-snapins).
-
**To edit a publisher rule**
-
1. Open the AppLocker console, and then click the appropriate rule collection.
-
2. In the **Action** pane, right-click the publisher rule, and then click **Properties**.
-
3. Click the appropriate tab to edit the rule properties.
-
- Click the **General** tab to change the rule name, add a rule description, configure whether the rule is used to allow or deny applications, and set the security group for which this rule should apply.
-
- Click the **Publisher** tab to configure the certificate's common name, the product name, the file name, or file version of the publisher.
-
- Click the **Exceptions** tab to create or edit exceptions.
-
- When you finish updating the rule, click **OK**.
-
**To edit a file hash rule**
-
1. Open the AppLocker console, and then click the appropriate rule collection.
-
2. Choose the appropriate rule collection.
-
3. In the **Action** pane, right-click the file hash rule, and then click **Properties**.
-
4. Click the appropriate tab to edit the rule properties.
-
- Click the **General** tab to change the rule name, add a rule description, configure whether the rule is used to allow or deny applications, and set the security group in which this rule should apply.
-
- Click the **File Hash** tab to configure the files that should be used to enforce the rule. You can click **Browse Files** to add a specific file or click **Browse Folders** to add all files in a specified folder. To remove hashes individually, click **Remove**.
-
- When you finish updating the rule, click **OK**.
-
**To edit a path rule**
-
1. Open the AppLocker console, and then click the appropriate rule collection.
-
2. Choose the appropriate rule collection.
-
3. In the **Action** pane, right-click the path rule, and then click **Properties**.
-
4. Click the appropriate tab to edit the rule properties.
-
- Click the **General** tab to change the rule name, add a rule description, configure whether the rule is used to allow or deny applications, and set the security group in which this rule should apply.
-
- Click the **Path** tab to configure the path on the computer in which the rule should be enforced.
-
- Click the **Exceptions** tab to create exceptions for specific files in a folder.
-
- When you finish updating the rule, click **OK**.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/enable-computer-and-user-accounts-to-be-trusted-for-delegation.md b/windows/keep-secure/enable-computer-and-user-accounts-to-be-trusted-for-delegation.md
index 34680d437c..af9eb0fbc6 100644
--- a/windows/keep-secure/enable-computer-and-user-accounts-to-be-trusted-for-delegation.md
+++ b/windows/keep-secure/enable-computer-and-user-accounts-to-be-trusted-for-delegation.md
@@ -2,52 +2,31 @@
title: Enable computer and user accounts to be trusted for delegation (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Enable computer and user accounts to be trusted for delegation security policy setting.
ms.assetid: 524062d4-1595-41f3-8ce1-9c85fd21497b
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Enable computer and user accounts to be trusted for delegation
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Enable computer and user accounts to be trusted for delegation** security policy setting.
-
## Reference
-
-
This policy setting determines which users can set the **Trusted for Delegation** setting on a user or computer object.
-
Security account delegation provides the ability to connect to multiple servers, and each server change retains the authentication credentials of the original client. Delegation of authentication is a capability that client and server applications use when they have multiple tiers. It allows a public-facing service to use client credentials to authenticate to an application or database service. For this configuration to be possible, the client and the server must run under accounts that are trusted for delegation.
-
Only administrators who have the **Enable computer and user accounts to be trusted for delegation** credential can set up delegation. Domain admins and Enterprise admins have this credential. The procedure to allow a user to be trusted for delegation depends on the functionality level of the domain.
-
The user or machine object that is granted this right must have write access to the account control flags. A server process running on a device (or under a user context) that is trusted for delegation can access resources on another computer by using the delegated credentials of a client. However, the client account must have Write access to the account control flags on the object.
-
Constant: SeEnableDelegationPrivilege
-
### Possible values
-
- User-defined list of accounts
-
- Not defined
-
### Best practices
-
- There is no reason to assign this user right to anyone on member servers and workstations that belong to a domain because it has no meaning in those contexts. It is only relevant on domain controllers and stand-alone devices.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
-
@@ -86,68 +65,32 @@ The following table lists the actual and effective default policy values for the
-
-
## Policy management
-
-
This section describes features, tools and guidance to help you manage this policy.
-
Modifying this setting might affect compatibility with clients, services, and applications.
-
A restart of the device is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
### Group Policy
-
This user right is defined in the Default Domain Controller Group Policy Object (GPO) and in the local security policy of workstations and servers.
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Misuse of the **Enable computer and user accounts to be trusted for delegation** user right could allow unauthorized users to impersonate other users on the network. An attacker could exploit this privilege to gain access to network resources and make it difficult to determine what has happened after a security incident.
-
### Countermeasure
-
The **Enable computer and user accounts to be trusted for delegation** user right should be assigned only if there is a clear need for its functionality. When you assign this right, you should investigate the use of constrained delegation to control what the delegated accounts can do. On domain controllers, this right is assigned to the Administrators group by default.
-
**Note**
There is no reason to assign this user right to anyone on member servers and workstations that belong to a domain because it has no meaning in those contexts. It is only relevant on domain controllers and stand-alone computers.
-
-
### Potential impact
-
None. Not defined is the default configuration.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/enable-the-dll-rule-collection.md b/windows/keep-secure/enable-the-dll-rule-collection.md
index 903c1b67bf..bf0a849440 100644
--- a/windows/keep-secure/enable-the-dll-rule-collection.md
+++ b/windows/keep-secure/enable-the-dll-rule-collection.md
@@ -2,43 +2,24 @@
title: Enable the DLL rule collection (Windows 10)
description: This topic for IT professionals describes the steps to enable the DLL rule collection feature for AppLocker.
ms.assetid: 88ef9561-6eb2-491a-803a-b8cdbfebae27
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Enable the DLL rule collection
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals describes the steps to enable the DLL rule collection feature for AppLocker.
-
The DLL rule collection includes the .dll and .ocx file formats.
-
For info about these rules, see [DLL rules in AppLocker](dll-rules-in-applocker.md).
-
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group Policy Object (GPO) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or in a security template. For info how to use these MMC snap-ins to administer AppLocker, see [Administer AppLocker](administer-applocker.md#bkmk-using-snapins).
-
**To enable the DLL rule collection**
-
1. From the AppLocker console, right-click **AppLocker**, and then click **Properties.**
-
2. Click the **Advanced** tab, select the **Enable the DLL rule collection** check box, and then click **OK**.
-
**Important**
Before you enforce DLL rules, make sure that there are allow rules for each DLL that is used by any of the allowed apps.
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/encrypted-hard-drive.md b/windows/keep-secure/encrypted-hard-drive.md
index b283dc1b4c..a47495f67c 100644
--- a/windows/keep-secure/encrypted-hard-drive.md
+++ b/windows/keep-secure/encrypted-hard-drive.md
@@ -2,130 +2,66 @@
title: Encrypted Hard Drive (Windows 10)
description: Encrypted Hard Drive uses the rapid encryption that is provided by BitLocker Drive Encryption to enhance data security and management.
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Encrypted Hard Drive
-
-
**Applies to**
-
- Windows 10
-
Encrypted Hard Drive uses the rapid encryption that is provided by BitLocker Drive Encryption to enhance data security and management.
-
By offloading the cryptographic operations to hardware, Encrypted Hard Drives increase BitLocker performance and reduce CPU usage and power consumption. Because Encrypted Hard Drives encrypt data quickly, enterprise devices can expand BitLocker deployment with minimal impact on productivity.
-
Encrypted Hard Drives are a new class of hard drives that are self-encrypting at a hardware level and allow for full disk hardware encryption. In Windows 8, Windows Server 2012, and later you can install to these devices without additional modification.
-
Some of the benefits of Encrypted Hard Drives include:
-
- **Better performance**: Encryption hardware, integrated into the drive controller, allows the drive to operate at full data rate with no performance degradation.
-
- **Strong security based in hardware**: Encryption is always "on" and the keys for encryption never leave the hard drive. User authentication is performed by the drive before it will unlock, independently of the operating system
-
- **Ease of use**: Encryption is transparent to the user because it is on by default. There is no user interaction needed to enable encryption. Encrypted Hard Drives are easily erased using on-board encryption key; there is no need to re-encrypt data on the drive.
-
- **Lower cost of ownership**: There is no need for new infrastructure to manage encryption keys, since BitLocker leverages your Active Directory Domain Services infrastructure to store recovery information. Your device operates more efficiently because processor cycles do not need to be used for the encryption process.
-
Encrypted Hard Drives are supported natively in the operating system through the following mechanisms:
-
- **Identification**: The operating system can identify that the drive is an Encrypted Hard Drive device type
-
- **Activation**: The operating system disk management utility can activate, create and map volumes to ranges/bands as appropriate
-
- **Configuration**: The operating system can create and map volumes to ranges/bands as appropriate
-
- **API**: API support for applications to manage Encrypted Hard Drives independently of BitLocker Drive Encryption (BDE)
-
- **BitLocker support**: Integration with the BitLocker Control Panel provides a seamless BitLocker end user experience.
-
**Warning**
Self-Encrypting Hard Drives and Encrypted Hard Drives for Windows are not the same type of device. Encrypted Hard Drives for Windows require compliance for specific TCG protocols as well as IEEE 1667 compliance; Self-Encrypting Hard Drives do not have these requirements. It is important to confirm the device type is an Encrypted Hard Drive for Windows when planning for deployment.
-
-
If you are a storage device vendor who is looking for more info on how to implement Encrypted Hard Drive, see the [Encrypted Hard Drive Device Guide](http://msdn.microsoft.com/library/windows/hardware/dn653989.aspx).
-
## System Requirements
-
-
To use Encrypted Hard Drive, the following system requirements apply:
-
For Encrypted Hard Drives used as **data drives**:
-
- The drive must be in an uninitialized state.
-
- The drive must be in a security inactive state.
-
For Encrypted Hard Drives used as **startup drives**:
-
- The drive must be in an uninitialized state.
-
- The drive must be in a security inactive state.
-
- The computer must be UEFI 2.3.1 based and have the EFI\_STORAGE\_SECURITY\_COMMAND\_PROTOCOL defined. (This protocol is used to allow programs running in the EFI boot services environment to send security protocol commands to the drive).
-
- The computer must have the Compatibility Support Module (CSM) disabled in UEFI.
-
- The computer must always boot natively from UEFI.
-
**Warning**
All Encrypted Hard Drives must be attached to non-RAID controllers to function properly.
-
-
## Technical overview
-
-
Rapid encryption in BitLocker directly addresses the security needs of enterprises while offering significantly improved performance. In versions of Windows earlier than Windows Server 2012, BitLocker required a two-step process to complete read/write requests. In Windows Server 2012, Windows 8, or later, Encrypted Hard Drives offload the cryptographic operations to the drive controller for much greater efficiency. When the operating system an Encrypted Hard Drive, it activates the security mode. This activation lets the drive controller generate a media key for every volume that the host computer creates. This media key, which is never exposed outside the disk, is used to rapidly encrypt or decrypt every byte of data that is sent or received from the disk.
-
## Configuring Encrypted Hard Drives as Startup drives
-
-
Configuration of Encrypted Hard Drives as startup drives is done using the same methods as standard hard drives. These methods include:
-
- **Deploy from media**: Configuration of Encrypted Hard Drives happens automatically through the installation process.
-
- **Deploy from network**: This deployment method involves booting a Windows PE environment and using imaging tools to apply a Windows image from a network share. Using this method, the Enhanced Storage optional component needs to be included in the Windows PE image. You can enable this component using Server Manager, Windows PowerShell, or the DISM command line tool. If this component is not present, configuration of Encrypted Hard Drives will not work.
-
- **Deploy from server**: This deployment method involves PXE booting a client with Encrypted Hard Drives present. Configuration of Encrypted Hard Drives happens automatically in this environment when the Enhanced Storage component is added to the PXE boot image. During deployment, the [TCGSecurityActivationDisabled](http://msdn.microsoft.com/library/windows/hardware/dn923247.aspx) setting in unattend.xml controls the encryption behavior of Encrypted Hard Drives.
-
- **Disk Duplication**: This deployment method involves use of a previously configured device and disk duplication tools to apply a Windows image to an Encrypted Hard Drive. Disks must be partitioned using at least Windows 8 or Windows Server 2012 for this configuration to work. Images made using disk duplicators will not work.
-
### Encrypted Hard Drive Architecture
-
Encrypted Hard Drives utilize two encryption keys on the device to control the locking and unlocking of data on the drive. These are the Data Encryption Key (DEK) and the Authentication Key (AK).
-
The Data Encryption Key is the key used to encrypt all of the data on the drive. The drive generates the DEK and it never leaves the device. It is stored in an encrypted format at a random location on the drive. If the DEK is changed or erased, data encrypted using the DEK is irrecoverable.
-
The Authentication Key is the key used to unlock data on the drive. A hash of the key is stored on drive and requires confirmation to decrypt the DEK.
-
When a computer with an Encrypted Hard Drive is in a powered off state, the drive locks automatically. As a computer powers on, the device remains in a locked state and is only unlocked after the Authentication Key decrypts the Data Encryption Key. Once the Authentication Key decrypts the Data Encryption Key, read-write operations can take place on the device.
-
When writing data to the drive, it passes through an encryption engine before the write operation completes. Likewise, reading data from the drive requires the encryption engine to decrypt the data before passing that data back to the user. In the event that the DEK needs to be changed or erased, the data on the drive does not need to be re-encrypted. A new Authentication Key needs to be created and it will re-encrypt the DEK. Once completed, the DEK can now be unlocked using the new AK and read-writes to the volume can continue.
-
## Re-configuring Encrypted Hard Drives
-
-
Many Encrypted Hard Drive devices come pre-configured for use. If reconfiguration of the drive is required, use the following procedure after removing all available volumes and reverting the drive to an uninitialized state:
-
1. Open Disk Management (diskmgmt.msc)
-
2. Initialize the disk and select the appropriate partition style (MBR or GPT)
-
3. Create one or more volumes on the disk.
-
4. Use the BitLocker setup wizard to enable BitLocker on the volume.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/enforce-applocker-rules.md b/windows/keep-secure/enforce-applocker-rules.md
index 0e2fcdd077..e71f69a725 100644
--- a/windows/keep-secure/enforce-applocker-rules.md
+++ b/windows/keep-secure/enforce-applocker-rules.md
@@ -2,39 +2,22 @@
title: Enforce AppLocker rules (Windows 10)
description: This topic for IT professionals describes how to enforce application control rules by using AppLocker.
ms.assetid: e1528b7b-77f2-4419-8e27-c9cc3721d96d
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Enforce AppLocker rules
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals describes how to enforce application control rules by using AppLocker.
-
After AppLocker rules are created within the rule collection, you can configure the enforcement setting to **Enforce rules** or **Audit only** on the rule collection.
-
When AppLocker policy enforcement is set to **Enforce rules**, rules are enforced for the rule collection and all events are audited. When AppLocker policy enforcement is set to **Audit only**, rules are only evaluated but all events generated from that evaluation are written to the AppLocker log.
-
There is no audit mode for the DLL rule collection. DLL rules affect specific apps. Therefore, test the impact of these rules first before deploying them to production.
-
To enforce AppLocker rules by configuring an AppLocker policy to **Enforce rules**, see [Configure an AppLocker policy for enforce rules](configure-an-applocker-policy-for-enforce-rules.md).
-
**Caution**
AppLocker rules will be enforced immediately on the local device or when the Group Policy object (GPO) is updated by performing this procedure. If you want to see the effect of applying an AppLocker policy before setting the enforcement setting to **Enforce rules**, configure the policy to **Audit only**. For info about how to do this, see [Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md)or [Test an AppLocker policy by Using Test-AppLockerPolicy](test-an-applocker-policy-by-using-test-applockerpolicy.md).
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/enforce-password-history.md b/windows/keep-secure/enforce-password-history.md
index 8a06a8f98b..aaf1fdefe7 100644
--- a/windows/keep-secure/enforce-password-history.md
+++ b/windows/keep-secure/enforce-password-history.md
@@ -2,52 +2,31 @@
title: Enforce password history (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Enforce password history security policy setting.
ms.assetid: 8b2ab871-3e52-4dd1-9776-68bb1e935442
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Enforce password history
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Enforce password history** security policy setting.
-
## Reference
-
-
The **Enforce password history** policy setting determines the number of unique new passwords that must be associated with a user account before an old password can be reused.
-
Password reuse is an important concern in any organization. Many users want to reuse the same password for their account over a long period of time. The longer the same password is used for a particular account, the greater the chance that an attacker will be able to determine the password through brute force attacks. If users are required to change their password, but they can reuse an old password, the effectiveness of a good password policy is greatly reduced.
-
Specifying a low number for **Enforce password history** allows users to continually use the same small number of passwords repeatedly. If you do not also set [Minimum password age](minimum-password-age.md), users can change their password as many times in a row as necessary to reuse their original password.
-
### Possible values
-
- User-specified number from 0 through 24
-
- Not defined
-
### Best practices
-
- Set **Enforce password history** to 24. This will help mitigate vulnerabilities that are caused by password reuse.
-
- Set [Maximum password age](maximum-password-age.md) to expire passwords between 60 and 90 days. Try to expire the passwords between major business cycles to prevent work loss.
-
- Configure [Minimum password age](minimum-password-age.md) so that you do not allow passwords to be changed immediately.
-
### Location
-
**Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Password Policy**
-
### Default values
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -86,54 +65,25 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
The longer a user uses the same password, the greater the chance that an attacker can determine the password through brute force attacks. Also, any accounts that may have been compromised remain exploitable for as long as the password is left unchanged. If password changes are required but password reuse is not prevented, or if users continually reuse a small number of passwords, the effectiveness of a good password policy is greatly reduced.
-
If you specify a low number for this policy setting, users can use the same small number of passwords repeatedly. If you do not also configure the [Minimum password age](minimum-password-age.md) policy setting, users might repeatedly change their passwords until they can reuse their original password.
-
**Note**
After an account has been compromised, a simple password reset might not be enough to restrict a malicious user because the malicious user might have modified the user's environment so that the password is changed back to a known value automatically at a certain time. If an account has been compromised, it is best to delete the account and assign the user a new account after all affected systems have been restored to normal operations and verified that they are no longer compromised.
-
-
### Countermeasure
-
Configure the **Enforce password history** policy setting to 24 (the maximum setting) to help minimize the number of vulnerabilities that are caused by password reuse.
-
For this policy setting to be effective, you should also configure effective values for the [Minimum password age](minimum-password-age.md) and [Maximum password age](maximum-password-age.md) policy settings.
-
### Potential impact
-
The major impact of configuring the **Enforce password history** setting to 24 is that users must create a new password every time they are required to change their old one. If users are required to change their passwords to new unique values, there is an increased risk of users who write their passwords somewhere so that they do not forget them. Another risk is that users may create passwords that change incrementally (for example, password01, password02, and so on) to facilitate memorization, but this makes them easier for an attacker to guess. Also, an excessively low value for the [Maximum password age](maximum-password-age.md) policy setting is likely to increase administrative overhead because users who forget their passwords might ask the Help Desk to reset them frequently.
-
## Related topics
-
-
[Password Policy](password-policy.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/enforce-user-logon-restrictions.md b/windows/keep-secure/enforce-user-logon-restrictions.md
index 18dd084c4c..ed3f79446b 100644
--- a/windows/keep-secure/enforce-user-logon-restrictions.md
+++ b/windows/keep-secure/enforce-user-logon-restrictions.md
@@ -2,48 +2,29 @@
title: Enforce user logon restrictions (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Enforce user logon restrictions security policy setting.
ms.assetid: 5891cb73-f1ec-48b9-b703-39249e48a29f
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Enforce user logon restrictions
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Enforce user logon restrictions** security policy setting.
-
## Reference
-
-
The **Enforce user logon restrictions** policy setting determines whether the Kerberos V5 Key Distribution Center (KDC) validates every request for a session ticket against the user rights policy of the user account. Validating each request for a session ticket is optional because the extra step takes time, and that can slow network access to services.
-
The possible values for this Group Policy setting are:
-
- Enabled
-
- Disabled
-
- Not defined
-
### Best practices
-
- If this policy setting is disabled, users might be granted session tickets for services that they do not have the right to use.
-
It is advisable to set **Enforce user logon restrictions** to Enabled.
-
### Location
-
**Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Kerberos Policy**
-
### Default Values
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -82,59 +63,27 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
A restart of the device is not required for this policy setting to be effective.
-
### Group Policy
-
Client devices will get the new setting during the next scheduled and successful Group Policy refresh. But for domain controllers to assign these new settings immediately, a gpupdate.exe /force is required. On the local device, the Security Configuration Engine will refresh this setting in about five minutes.
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
If you disable this policy setting, users could receive session tickets for services that they no longer have the right to use because the right was removed after they logged on.
-
### Countermeasure
-
Enable the **Enforce user logon restrictions** setting.
-
### Potential impact
-
None. This is the default configuration.
-
## Related topics
-
-
[Kerberos Policy](kerberos-policy.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/executable-rules-in-applocker.md b/windows/keep-secure/executable-rules-in-applocker.md
index 9bc04a00e9..b215d8ffe5 100644
--- a/windows/keep-secure/executable-rules-in-applocker.md
+++ b/windows/keep-secure/executable-rules-in-applocker.md
@@ -2,23 +2,17 @@
title: Executable rules in AppLocker (Windows 10)
description: This topic describes the file formats and available default rules for the executable rule collection.
ms.assetid: 65e62f90-6caa-48f8-836a-91f8ac9018ee
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Executable rules in AppLocker
-
-
**Applies to**
-
- Windows 10
-
This topic describes the file formats and available default rules for the executable rule collection.
-
AppLocker defines executable rules as any files with the .exe and .com extensions that are associated with an app. Because all of the default rules for the executable rule collection are based on folder paths, all files under those paths will be allowed. The following table lists the default rules that are available for the executable rule collection.
-
@@ -55,19 +49,8 @@ AppLocker defines executable rules as any files with the .exe and .com extension
-
-
## Related topics
-
-
[Understanding AppLocker Default Rules](understanding-applocker-default-rules.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/export-an-applocker-policy-from-a-gpo.md b/windows/keep-secure/export-an-applocker-policy-from-a-gpo.md
index 4d3bebaea0..565c1d0597 100644
--- a/windows/keep-secure/export-an-applocker-policy-from-a-gpo.md
+++ b/windows/keep-secure/export-an-applocker-policy-from-a-gpo.md
@@ -2,42 +2,23 @@
title: Export an AppLocker policy from a GPO (Windows 10)
description: This topic for IT professionals describes the steps to export an AppLocker policy from a Group Policy Object (GPO) so that it can be modified.
ms.assetid: 7db59719-a8be-418b-bbfd-22cf2176c9c0
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Export an AppLocker policy from a GPO
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals describes the steps to export an AppLocker policy from a Group Policy Object (GPO) so that it can be modified.
-
Updating an AppLocker policy that is currently enforced in your production environment can have unintended results. Therefore, export the policy from the GPO and update the rule or rules by using AppLocker on your AppLocker reference device
-
To complete this procedure, you must have the **Edit Setting** permission to edit a GPO. By default, members of the **Domain Admins** group, the **Enterprise Admins** group, and the **Group Policy Creator Owners** group have this permission.
-
**Export the policy from the GPO**
-
1. In the Group Policy Management Console (GPMC), open the GPO that you want to edit.
-
2. In the console tree under **Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Application Control Policies**, click **AppLocker**.
-
3. Right-click **AppLocker**, and then click **Export Policy**.
-
4. In the **Export Policy** dialog box, type a name for the exported policy (for example, the name of the GPO), select a location to save the policy, and then click **Save**.
-
5. The **AppLocker** dialog box will notify you of how many rules were exported. Click **OK**.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/export-an-applocker-policy-to-an-xml-file.md b/windows/keep-secure/export-an-applocker-policy-to-an-xml-file.md
index db8273ad60..5812fda7ae 100644
--- a/windows/keep-secure/export-an-applocker-policy-to-an-xml-file.md
+++ b/windows/keep-secure/export-an-applocker-policy-to-an-xml-file.md
@@ -2,36 +2,20 @@
title: Export an AppLocker policy to an XML file (Windows 10)
description: This topic for IT professionals describes the steps to export an AppLocker policy to an XML file for review or testing.
ms.assetid: 979bd23f-6815-478b-a6a4-a25239cb1080
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Export an AppLocker policy to an XML file
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals describes the steps to export an AppLocker policy to an XML file for review or testing.
-
Membership in the local **Administrators** group, or equivalent, is the minimum required to complete this procedure.
-
**To export an AppLocker policy to an XML file**
-
1. From the AppLocker console, right-click **AppLocker**, and then click **Export Policy**.
-
2. Browse to the location where you want to save the XML file.
-
3. In the **File name** box, type a file name for the XML file, and then click **Save**.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/file-system-global-object-access-auditing.md b/windows/keep-secure/file-system-global-object-access-auditing.md
index b9eaa059fb..8d1bf75dc2 100644
--- a/windows/keep-secure/file-system-global-object-access-auditing.md
+++ b/windows/keep-secure/file-system-global-object-access-auditing.md
@@ -2,37 +2,20 @@
title: File System (Global Object Access Auditing) (Windows 10)
description: This topic for the IT professional describes the Advanced Security Audit policy setting, File System (Global Object Access Auditing), which enables you to configure a global system access control list (SACL) on the file system for an entire computer.
ms.assetid: 4f215d61-0e23-46e4-9e58-08511105d25b
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# File System (Global Object Access Auditing)
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional describes the Advanced Security Audit policy setting, **File System (Global Object Access Auditing)**, which enables you to configure a global system access control list (SACL) on the file system for an entire computer.
-
If you select the **Configure security** check box on the policy’s property page, you can add a user or group to the global SACL. This enables you to define computer system access control lists (SACLs) per object type for the file system. The specified SACL is then automatically applied to every file system object type.
-
If both a file or folder SACL and a global SACL are configured on a computer, the effective SACL is derived by combining the file or folder SACL and the global SACL. This means that an audit event is generated if an activity matches either the file or folder SACL or the global SACL.
-
This policy setting must be used in combination with the **File System** security policy setting under Object Access. For more information, see [Audit File System](audit-file-system.md).
-
## Related topics
-
-
[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/force-shutdown-from-a-remote-system.md b/windows/keep-secure/force-shutdown-from-a-remote-system.md
index 28d7bc97d6..4f4d1d9ed6 100644
--- a/windows/keep-secure/force-shutdown-from-a-remote-system.md
+++ b/windows/keep-secure/force-shutdown-from-a-remote-system.md
@@ -2,48 +2,29 @@
title: Force shutdown from a remote system (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Force shutdown from a remote system security policy setting.
ms.assetid: 63129243-31ea-42a4-a598-c7064f48a3df
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Force shutdown from a remote system
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Force shutdown from a remote system** security policy setting.
-
## Reference
-
-
This security setting determines which users are allowed to shut down a device from a remote location on the network. This allows members of the Administrators group or specific users to manage computers (for tasks such as a restart) from a remote location.
-
Constant: SeRemoteShutdownPrivilege
-
### Possible values
-
- User-defined list of accounts
-
- Administrators
-
### Best practices
-
- Explicitly restrict this user right to members of the Administrators group or other specifically assigned roles that require this capability, such as non-administrative operations staff.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
By default this setting is Administrators and Server Operators on domain controllers and Administrators on stand-alone servers.
-
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
-
@@ -84,63 +65,29 @@ The following table lists the actual and effective default policy values for the
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
A restart of the computer is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
This policy setting must be applied on the computer that is being accessed remotely.
-
### Group Policy
-
This user right is defined in the Default Domain Controller Group Policy Object (GPO) and in the local security policy of workstations and servers.
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Any user who can shut down a device could cause a denial-of-service condition to occur. Therefore, this user right should be tightly restricted.
-
### Countermeasure
-
Restrict the **Force shutdown from a remote system** user right to members of the Administrators group or other specifically assigned roles that require this capability, such as non-administrative operations staff.
-
### Potential impact
-
On a domain controller, if you remove the **Force shutdown from a remote system** user right from the Server Operator group, you could limit the abilities of users who are assigned to specific administrative roles in your environment. You should confirm that delegated activities are not adversely affected.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/generate-security-audits.md b/windows/keep-secure/generate-security-audits.md
index db7aaf05aa..71e55bf774 100644
--- a/windows/keep-secure/generate-security-audits.md
+++ b/windows/keep-secure/generate-security-audits.md
@@ -2,50 +2,30 @@
title: Generate security audits (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Generate security audits security policy setting.
ms.assetid: c0e1cd80-840e-4c74-917c-5c2349de885f
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Generate security audits
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Generate security audits** security policy setting.
-
## Reference
-
-
This policy setting determines which accounts can be used by a process to generate audit records in the security event log. The Local Security Authority Subsystem Service (LSASS) writes events to the log. You can use the information in the security event log to trace unauthorized device access.
-
Constant: SeAuditPrivilege
-
### Possible values
-
- User-defined list of accounts
-
- Local Service
-
- Network Service
-
### Best practices
-
- Because the audit log can potentially be an attack vector if an account is compromised, ensure that only the Local Service and Network Service accounts have the **Generate security audits** user right assigned to them.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
By default, this setting is Local Service and Network Service on domain controllers and stand-alone servers.
-
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
-
@@ -89,61 +69,28 @@ The following table lists the actual and effective default policy values for the
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
A restart of the computer is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
Misuse of this user right can result in the generation of many auditing events, potentially hiding evidence of an attack or causing a denial-of-service (DoS) if the [Audit: Shut down system immediately if unable to log security audits](audit-shut-down-system-immediately-if-unable-to-log-security-audits.md) security policy setting is enabled.
-
### Group Policy
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
A malicious user could use accounts that can write to the Security log to fill that log with meaningless events. If the computer is configured to overwrite events as needed, malicious users could use this method to remove evidence of their unauthorized activities. If the computer is configured to shut down when it is unable to write to the Security log, and it is not configured to automatically back up the log files, this method could be used to create a DoS condition.
-
### Countermeasure
-
Ensure that only the Local Service and Network Service accounts have the **Generate security audits** user right assigned to them.
-
### Potential impact
-
None. Restricting the **Generate security audits** user right to the Local Service and Network Service accounts is the default configuration.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/get-started-with-windows-defender-for-windows-10.md b/windows/keep-secure/get-started-with-windows-defender-for-windows-10.md
index 90a0b0d76a..f7b4350a6f 100644
--- a/windows/keep-secure/get-started-with-windows-defender-for-windows-10.md
+++ b/windows/keep-secure/get-started-with-windows-defender-for-windows-10.md
@@ -5,14 +5,13 @@ ms.assetid: 045F5BF2-87D7-4522-97E1-C1D508E063A7
ms.prod: W10
ms.mktglfcycl: manage
ms.sitesec: library
+ms.pagetype: security
author: jasesso
---
# Update and manage Windows Defender in Windows 10
-
**Applies to**
-
- Windows 10
IT professionals can manage Windows Defender on Windows 10 endpoints in their organization using Microsoft Active Directory or Windows Server Update Services (WSUS), apply updates to endpoints, and manage scans using:
@@ -23,14 +22,11 @@ IT professionals can manage Windows Defender on Windows 10 endpoints in their o
## Manage Windows Defender endpoints through Active Directory and WSUS
-
All Windows 10 endpoints are installed with Windows Defender and include support for management through:
-
- Active Directory
- WSUS
You can use the Active Directory to configure the settings; Group policies can be used for centralized configuration and enforcement of many Windows Defender settings including client user interface, scan settings, and exclusions.
-
WSUS can be used to view basic update compliance and deploy updates manually or through automatic rules.
Note that System Center 2012 R2 Configuration Manager SP1, System Center 2012 Configuration Manager SP2, and Microsoft Intune can provide centralized management of Windows Defender, including:
@@ -41,192 +37,153 @@ Note that System Center 2012 R2 Configuration Manager SP1, System Center 2012
- Reports and reporting
When you enable *Endpoint Protection* on your clients, it will install an additional management layer on Windows Defender to manage the in-box Windows Defender agent. While the client user interface will still appear as Windows Defender, the management layer for System Center Endpoint Protection or Intune will be listed in the **Add/Remove Programs** control panel, though it will appear as if the full product is installed. Learn more about managing *Endpoint Protection*:
+
- [Help secure Windows PCs with Endpoint Protection for Microsoft Intune](https://technet.microsoft.com/library/dn646970.aspx)
- [Endpoint Protection in Configuration Manager](https://technet.microsoft.com/library/hh508760.aspx)
Read more about System Center Configuration Manager in [Introduction to Endpoint Protection in Configuration Manager](https://technet.microsoft.com/library/hh508781.aspx).
-
-**Important** You must be licensed to use *Endpoint Protection* to manage clients in your Configuration Manager hierarchy.
-
+> **Important:** You must be licensed to use *Endpoint Protection* to manage clients in your Configuration Manager hierarchy.
-
## Apply updates to Windows Defender endpoints
-
It is important to keep Windows Defender endpoints updated to ensure they are protected. All Windows Defender updates, including General Distribution Release (GDR) updates, are now applied as operating system updates.
-
You can manage the distribution of updates through the [Windows Server Update Services (WSUS)](https://technet.microsoft.com/windowsserver/bb332157).
## Manage email scans in Windows Defender
-
You can use Windows Defender to scan email files. Malware can install itself and hide in email files, and although real-time protection offers you the best protection from email malware, you can also scan emails stored on your PC or server with Windows Defender.
-
-**Important** Mail scanning only applies to on-demand and scheduled scans, not on-access scans.
-
+> **Important:** Mail scanning only applies to on-demand and scheduled scans, not on-access scans.
-
Windows Defender scans Microsoft Office Outlook 2003 and older email files. We identify the file type at run-time based on the content of the file, not on location or extension.
-
-**Note** Scanning email files might increase the time required to complete a scan.
-
+> **Note: ** Scanning email files might increase the time required to complete a scan.
-
Windows Defender can extract embedded objects within a file (attachments and archived files, for example) and scan internally.
-
-**Note** While Windows Defender can be configured to scan email files, it can only remediate threats detected inside certain files, for example:
+> **Note:** While Windows Defender can be configured to scan email files, it can only remediate threats detected inside certain files, for example:
- DBX
- MBX
- MIME
-
-
You can configure Windows Defender to scan PST files used by Outlook 2003 or older versions (where the archive type is set to non-uni-code), but Windows Defender cannot remediate threats detected inside PST files. We recommend using real-time protection to protect against email malware.
If Windows Defender detects a threat inside an email, it will show you the following information to assist you in identifying the compromised email, so you can remediate the threat:
-
- Email subject
- Attachment name
-
Email scanning in Windows Defender is turned off by default. There are three ways you can manage scans through Windows Defender:
-
- *Group Policy* settings
- WMI
- PowerShell
-
-**Important** There are some risks associated with scanning some Microsoft Outlook files and email messages. You can read about tips and risks associated with scanning Outlook files and email messages in the following articles:
+> **Important:** There are some risks associated with scanning some Microsoft Outlook files and email messages. You can read about tips and risks associated with scanning Outlook files and email messages in the following articles:
- [Scanning Outlook files in Outlook 2013](https://technet.microsoft.com/library/dn769141.aspx#bkmk-1)
- [Scanning email messages in Outlook 2013](https://technet.microsoft.com/library/dn769141.aspx#bkmk-2)
-
-
## Use *Group Policy* settings to enable email scans
-
This policy setting allows you to turn on email scanning. When email scanning is enabled, the engine will parse the mailbox and mail files to analyze the mail bodies and attachments.
Turn on email scanning with the following *Group Policy* settings:
-
1. Open the **Group Policy Editor**.
2. In the **Local Computer Policy** tree, expand **Computer Configuration**, then **Administrative Templates**, then **Windows Components**, then **Windows Defender**.
3. Click **Scan**.
4. Double-click **Turn on e-mail scanning**.
- This will open the **Turn on e-mail scanning** window: 
-
+ This will open the **Turn on e-mail scanning** window:
+
+ 
+
5. Select **Enabled**.
6. Click **OK** to apply changes.
## Use WMI to disable email scans
-
You can write a WMI script or application to disable email scanning. Read more about [WMI in this article](https://msdn.microsoft.com/library/windows/desktop/dn439477.aspx), and read about [Windows Preference classes in this article](https://msdn.microsoft.com/library/windows/desktop/dn455323.aspx).
Use the **DisableEmailScanning** property of the **MSFT\_MpPreference** class (part of the Windows DefenderWMI provider) to enable or disable this setting:
-
**DisableEmailScanning**
Data type: **boolean**
Access type: Read-only
Disable email scanning.
+
## Use PowerShell to enable email scans
-
You can also enable email scanning using the following PowerShell parameter:
-
1. Open PowerShell or PowerShellIntegrated Scripting Environment (ISE).
2. Type **Set-MpPreference -DisableEmailScanning $false**.
Read more about this in:
-
- • [Scripting with Windows PowerShell](https://technet.microsoft.com/library/bb978526.aspx)
- • [Defender Cmdlets](https://technet.microsoft.com/library/dn433280.aspx)
## Manage archive scans in Windows Defender
-
You can use Windows Defender to scan archive files. Malware can install itself and hide in archive files, and although real-time protection offers you the best protection from malware, you can also scan archives stored on your PC or server with Windows Defender.
-
-**Important** Archive scanning only applies to on-demand and scheduled scans, not on-access scans.
-
+> **Important:** Archive scanning only applies to on-demand and scheduled scans, not on-access scans.
-
Archive scanning in Windows Defender is turned on by default. There are four ways you can manage scans through Windows Defender:
-
- *Group Policy* settings
- WMI
- PowerShell
- Endpoint Protection
-
-**Note** Scanning archive files might increase the time required to complete a scan.
-
+> **Note:** Scanning archive files might increase the time required to complete a scan.
-
If you exclude an archive file type by using the **Extensions** box, Windows Defender will not scan files with that extension (no matter what the content is), even when you have selected the **Scan archive files** check box. For example, if you exclude .rar files but there’s a .r00 file that’s actually .rar content, it will still be scanned if archive scanning is enabled.
## Use *Group Policy* settings to enable archive scans
-
This policy setting allows you to turn on archive scanning.
Turn on email scanning with the following *Group Policy* settings:
-
1. Open the **Group Policy Editor**.
2. In the **Local Computer Policy** tree, expand **Computer Configuration**, then **Administrative Templates**, then **Windows Components**, then **Windows Defender**.
3. Click **Scan**.
4. Double-click **Scan archive files**.
- This will open the **Scan archive files** window: 
-
+ This will open the **Scan archive files** window:
+
+ 
+
5. Select **Enabled**.
6. Click **OK** to apply changes.
There are a number of archive scan settings in the **Scan** repository you can configure through *Group Policy*, for example:
+- Maximum directory depth level into which archive files are unpacked during scanning
-- Maximum directory depth level into which archive files are unpacked during scanning 
-- Maximum size of archive files that will be scanned 
-- Maximum percentage CPU utilization permitted during a scan 
+ 
+
+- Maximum size of archive files that will be scanned
+
+ 
+
+- Maximum percentage CPU utilization permitted during a scan
+
+ 
## Use WMI to disable archive scans
-
You can write a WMI script or application to disable archive scanning. Read more about [WMI in this article](https://msdn.microsoft.com/library/windows/desktop/dn439477.aspx), and read about [Windows Preference classes in this article](https://msdn.microsoft.com/library/windows/desktop/dn455323.aspx).
Use the **DisableArchiveScanning** property of the **MSFT\_MpPreference** class (part of the Windows DefenderWMI provider) to enable or disable this setting:
-
**DisableArchiveScanning**
Data type: **boolean**
Access type: Read-only
Disable archive scanning.
+
## Use PowerShell to enable archive scans
-
You can also enable archive scanning using the following PowerShell parameter:
-
1. Open PowerShell or PowerShellISE.
2. Type **Set-MpPreference -DisableArchiveScanning $false**.
Read more about this in:
-
-- • [Scripting with Windows PowerShell](https://technet.microsoft.com/library/bb978526.aspx)
-- • [Defender Cmdlets](https://technet.microsoft.com/library/dn433280.aspx)
+- [Scripting with Windows PowerShell](https://technet.microsoft.com/library/bb978526.aspx)
+- [Defender Cmdlets](https://technet.microsoft.com/library/dn433280.aspx)
## Use Endpoint Protection to configure archive scans
-
In Endpoint Protection, you can use the advanced scanning options to configure archive scanning. For more information, see [What are advanced scanning options?](https://technet.microsoft.com/library/ff823807.aspx)
## Related topics
-
[Configure Windows Defender in Windows 10](configure-windows-defender-in-windows-10.md)
-
[Troubleshoot Windows Defender in Windows 10](troubleshoot-windows-defender-in-windows-10.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/getting-apps-to-run-on-device-guard-protected-devices.md b/windows/keep-secure/getting-apps-to-run-on-device-guard-protected-devices.md
index 2780dd8b05..f9af00d1cd 100644
--- a/windows/keep-secure/getting-apps-to-run-on-device-guard-protected-devices.md
+++ b/windows/keep-secure/getting-apps-to-run-on-device-guard-protected-devices.md
@@ -2,18 +2,17 @@
title: Get apps to run on Device Guard-protected devices (Windows 10)
description: Windows 10 introduces several new features and settings that when combined all equal what we're calling, Device Guard.
ms.assetid: E62B68C3-8B9F-4842-90FC-B4EE9FF8A67E
-keywords: ["Package Inspector", "packageinspector.exe", "sign catalog file"]
+keywords: Package Inspector, packageinspector.exe, sign catalog file
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Get apps to run on Device Guard-protected devices
-
**Applies to**
-
- Windows 10
Windows 10 introduces several new features and settings that when combined all equal what we're calling, Device Guard. Device Guard can help to protect your enterprise devices against the accidental running of malicious apps by requiring all of your apps to be signed by a trusted entity.
@@ -22,49 +21,33 @@ To use Device Guard in an enterprise, you must be able to get your existing line
## What you need to run your apps on Device-Guard protected devices
-
Before you can get your apps to run on Device Guard-protected devices, you must have:
- A device running Windows 10 Enterprise, Windows 10 Education, or Windows Server 2016 Technical Preview.
-
- Determined which unsigned apps you need to include in your catalog file.
-
- Created a code integrity policy for use by Device Guard.
-
- A [code signing certificate](http://go.microsoft.com/fwlink/p/?LinkId=619282), created using an internal public key infrastructure (PKI).
-
- [SignTool]( http://go.microsoft.com/fwlink/p/?LinkId=619283). A command-line tool that digitally signs files, verifies signatures in files, or time stamps files. The tool is installed in the \\Bin folder of the Microsoft Windows Software Development Kit (SDK) installation path.
## Create a catalog file for unsigned apps
-
You must run Package Inspector on a device that's running a temporary Code Integrity Policy in audit mode, created explicitly for this purpose. Audit mode lets this policy catch any binaries missed by the inspection tool, but because it's audit mode, allows everything to continue running.
-
-**Important** This temporary policy, shouldn't be used for normal business purposes.
-
+> **Important:** This temporary policy, shouldn't be used for normal business purposes.
-
**To create a catalog file for an existing app**
-
1. Start PowerShell as an administrator, and create your temporary policy file by typing:
-
``` syntax
mkdir temp
New-CIPolicy -l FileName -f .\tempdeny.xml -s .\temp -u
ConvertFrom-CIPolicy .\tempdeny.xml .\tempdeny.bin
cp .\tempdeny.bin C:\Windows\System32\CodeIntegrity\SIPolicy.p7b
```
-
2. Restart your device.
-
3. Start PowerShell as an administrator, and start scanning your file system by typing:
-
``` syntax
PackageInspector.exe start c:
```
-
Where:
-
@@ -87,41 +70,27 @@ You must run Package Inspector on a device that's running a temporary Code Integ
-
-
4. Copy the app installation media to your C:\\ drive, and then install and run the program.
Copying the media to your local drive helps to make sure that the installer and its related files are included in your catalog file. If you miss the install files, your Code Integrity Policy might trust the app to run, but not to install. After you've installed the app, you should check for updates. If updates happen while the app is open, you should close and restart the app to make sure everything is caught during the inspection process.
-
- **Note**
- Because the Package Inspector creates a log entry in the catalog for every binary laid down on the file system, we recommend that you don't run any other installations or updates during the scanning process.
-
+
+ > **Note:** Because the Package Inspector creates a log entry in the catalog for every binary laid down on the file system, we recommend that you don't run any other installations or updates during the scanning process.
-
5. **Optional:** If you want to create a multi-app catalog (many apps included in a single catalog file), you can continue to run Steps 2-3 for each additional app. After you've added all of the apps you want to add, you can continue to Step 5.
-
- **Note** To streamline your process, we suggest:
+ > **Note: ** To streamline your process, we suggest:
- **Actively supported and updated apps.** Create a single catalog file for each app.
-
- **Legacy apps, non-active or not updated.** Create a single catalog file for all of your legacy apps.
-
-
6. Stop the scanning process and create the .\\InspectedPackage.cat and InspectedPackage.cdf files for your single app in your specified location, by typing:
-
``` syntax
PackageInspector.exe stop c:
```
-
You can also use the `scan` command in place of using both `start` and `stop` if you want to create a catalog of files that are already present on your hard drive. The `scan` command recursively scans a specified directory and includes all signable files in the catalog. You can scan a specified directory by typing:
-
``` syntax
PackageInspector.exe scan c:\
```
-
The following table shows the available options for both the `scan` and `stop` commands.
-
@@ -181,42 +150,29 @@ The following table shows the available options for both the `scan` and `stop` c
-
-
You can add additional parameters to your catalog beyond what's listed here. For more info, see the [MakeCat](http://go.microsoft.com/fwlink/p/?LinkId=618024) topic.
## Sign your catalog file using Sign Tool
-
You can sign your catalog file using Sign Tool, located in the Windows 7 or later Windows Software Development Kit (SDK) or by using the Device Guard signing portal. For details on using the Device Guard signing portal, see [Device Guard signing](http://go.microsoft.com/fwlink/p/?LinkID=698760).
-
This process shows how to use a password-protected Personal Information Exchange (.pfx) file to sign the catalog file.
-**Important** To use this tool, you must have an internal certificate authority code signing certificate, or a code signing certificate issued by an external third-party certificate authority.
-
+> **Important:** To use this tool, you must have an internal certificate authority code signing certificate, or a code signing certificate issued by an external third-party certificate authority.
-
**To use Sign Tool**
1. Check that your code signing certificates have been imported into your certificate store or that they're on the file system.
-
2. Open SignTool.exe and sign the catalog file, based on where your certificate is stored.
-
If you are using the PFX from a file system location:
-
``` syntax
signtool sign /f <\\SignCertLocation> /p <\\password> /fd sha256 /v
```
-
If you have imported the certificate into your cert store:
-
``` syntax
signtool sign /n <\\CertSubjectName> /fd sha256 /v
```
-
Where:
-
@@ -260,44 +216,32 @@ This process shows how to use a password-protected Personal Information Exchange
-
-
For more detailed info and examples using the available options, see the [SignTool.exe (Sign Tool)](http://go.microsoft.com/fwlink/p/?LinkId=618026) topic.
-
+
3. In File Explorer, right-click your catalog file, click **Properties**, and then click the **Digital Signatures** tab to make sure your catalog file's digital signature is accurate.
-
4. Copy your catalog file to C:\\Windows\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} and test the file.
- **Note** For testing purposes, you can manually copy your file to this location. However, we recommend that you use Group Policy to copy the catalog file to all of your devices for large-scale implementations.
-
-
-
+ >**Note:** For testing purposes, you can manually copy your file to this location. However, we recommend that you use Group Policy to copy the catalog file to all of your devices for large-scale implementations.
+
## Troubleshooting the Package Inspector
-
If you see "Error 1181" while stopping the Package Inspector, you'll need to increase your USN journal size and then clear all of the cached data before re-scanning the impacted apps.
You must make sure that you clear the cache by creating and setting a new temporary policy. If you reuse the same policy, the Package Inspector will fail.
**To increase your journal size**
-
1. Open a command-prompt window, and then type:
-
``` syntax
fsutil usn createjournal m=0x8000000 a=0x800000 C:
```
-
Where the "m" value needs to be increased. We recommend that you change the value to at least 4 times the default value of m=0x2000000.
-
2. Re-run the failed app installation(s).
**To clear your cached data and re-scan your apps**
1. Delete the SIPolicy.p7b file from the C:\\Windows\\System32\\CodeIntegrity\\ folder.
-
2. Create a new temporary Code Integrity Policy to clear all of the cached data by starting Windows Powershell as an administrator and typing:
-
``` syntax
mkdir temp
cp C:\Windows\System32\PackageInspector.exe .\temp\
@@ -305,19 +249,8 @@ You must make sure that you clear the cache by creating and setting a new tempor
ConvertFrom-CIPolicy .\DenyPackageInspector.xml .\DenyPackageInspector.bin
cp .\DenyPackageInspector.bin C:\Windows\System32\SIPolicy.p7b
```
-
3. Restart your device and follow the steps in the [Create a catalog file for unsigned apps](#create-a-catalog-file-for-unsigned-apps) section.
## Related topics
-
[Download SignTool]( http://go.microsoft.com/fwlink/p/?LinkId=619283)
-
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/how-applocker-works-techref.md b/windows/keep-secure/how-applocker-works-techref.md
index 344c66263f..c482e1a4bc 100644
--- a/windows/keep-secure/how-applocker-works-techref.md
+++ b/windows/keep-secure/how-applocker-works-techref.md
@@ -2,71 +2,37 @@
title: How AppLocker works (Windows 10)
description: This topic for the IT professional provides links to topics about AppLocker architecture and components, processes and interactions, rules and policies.
ms.assetid: 24bb1d73-0ff5-4af7-8b8a-2fa44d4ddbcd
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# How AppLocker works
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional provides links to topics about AppLocker architecture and components, processes and interactions, rules and policies.
-
The following topics explain how AppLocker policies for each of the rule condition types are evaluated:
-
- [AppLocker architecture and components](applocker-architecture-and-components.md)
-
- [AppLocker processes and interactions](applocker-processes-and-interactions.md)
-
The following topics explain how AppLocker rules and policies work:
-
- [Understanding AppLocker rule behavior](understanding-applocker-rule-behavior.md)
-
- [Understanding AppLocker rule exceptions](understanding-applocker-rule-exceptions.md)
-
- [Understanding AppLocker rule collections](understanding-applocker-rule-collections.md)
-
- [Understanding AppLocker allow and deny actions on rules](understanding-applocker-allow-and-deny-actions-on-rules.md)
-
- [Understanding AppLocker rule condition types](understanding-applocker-rule-condition-types.md)
-
- [Understanding the publisher rule condition in AppLocker](understanding-the-publisher-rule-condition-in-applocker.md)
-
- [Understanding the path rule condition in AppLocker](understanding-the-path-rule-condition-in-applocker.md)
-
- [Understanding the file hash rule condition in AppLocker](understanding-the-file-hash-rule-condition-in-applocker.md)
-
- [Understanding AppLocker default rules](understanding-applocker-default-rules.md)
-
- [Executable rules in AppLocker](executable-rules-in-applocker.md)
-
- [Windows Installer rules in AppLocker](windows-installer-rules-in-applocker.md)
-
- [Script rules in AppLocker](script-rules-in-applocker.md)
-
- [DLL rules in AppLocker](dll-rules-in-applocker.md)
-
- [Packaged apps and packaged app installer rules in AppLocker](packaged-apps-and-packaged-app-installer-rules-in-applocker.md)
-
## Additional resources
-
-
- [AppLocker Design Guide](applocker-policies-design-guide.md)
-
- [AppLocker deployment guide](applocker-policies-deployment-guide.md)
-
- [Administer AppLocker](administer-applocker.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/how-to-configure-security-policy-settings.md b/windows/keep-secure/how-to-configure-security-policy-settings.md
index 43a7e1c656..9ba376ff63 100644
--- a/windows/keep-secure/how-to-configure-security-policy-settings.md
+++ b/windows/keep-secure/how-to-configure-security-policy-settings.md
@@ -2,114 +2,59 @@
title: Configure security policy settings (Windows 10)
description: Describes steps to configure a security policy setting on the local device, on a domain-joined device, and on a domain controller.
ms.assetid: 63b0967b-a9fe-4d92-90af-67469ee20320
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Configure security policy settings
-
-
**Applies to**
-
- Windows 10
-
Describes steps to configure a security policy setting on the local device, on a domain-joined device, and on a domain controller.
-
You must have Administrators rights on the local device, or you must have the appropriate permissions to update a Group Policy Object (GPO) on the domain controller to perform these procedures.
-
When a local setting is inaccessible, it indicates that a GPO currently controls that setting.
-
## To configure a setting using the Local Security Policy console
-
-
1. To open Local Security Policy, on the **Start** screen, type **secpol.msc**, and then press ENTER.
-
2. Under **Security Settings** of the console tree, do one of the following:
-
- Click **Account Policies** to edit the **Password Policy** or **Account Lockout Policy**.
-
- Click **Local Policies** to edit an **Audit Policy**, a **User Rights Assignment**, or **Security Options**.
-
3. When you find the policy setting in the details pane, double-click the security policy that you want to modify.
-
4. Modify the security policy setting, and then click **OK**.
-
**Note**
- Some security policy settings require that the device be restarted before the setting takes effect.
-
- Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
-
## To configure a security policy setting using the Local Group Policy Editor console
-
-
You must have the appropriate permissions to install and use the Microsoft Management Console (MMC), and to update a Group Policy Object (GPO) on the domain controller to perform these procedures.
-
1. Open the Local Group Policy Editor (gpedit.msc).
-
2. In the console tree, click **Computer Configuration**, click **Windows Settings**, and then click **Security Settings**.
-
3. Do one of the following:
-
- Click **Account Policies** to edit the **Password Policy** or **Account Lockout Policy**.
-
- Click **Local Policies** to edit an **Audit Policy**, a **User Rights Assignment**, or **Security Options**.
-
4. In the details pane, double-click the security policy setting that you want to modify.
-
**Note**
If this security policy has not yet been defined, select the **Define these policy settings** check box.
-
-
5. Modify the security policy setting, and then click **OK**.
-
**Note** If you want to configure security settings for many devices on your network, you can use the Group Policy Management Console.
-
-
## To configure a setting for a domain controller
-
-
The following procedure describes how to configure a security policy setting for only a domain controller (from the domain controller).
-
1. To open the domain controller security policy, in the console tree, locate *GroupPolicyObject \[ComputerName\]* Policy, click **Computer Configuration**, click **Windows Settings**, and then click **Security Settings**.
-
2. Do one of the following:
-
- Double-click **Account Policies** to edit the **Password Policy**, **Account Lockout Policy**, or **Kerberos Policy**.
-
- Click **Local Policies** to edit the **Audit Policy**, a **User Rights Assignment**, or **Security Options**.
-
3. In the details pane, double-click the security policy that you want to modify.
-
**Note**
If this security policy has not yet been defined, select the **Define these policy settings** check box.
-
-
4. Modify the security policy setting, and then click **OK**.
-
**Important**
- Always test a newly created policy in a test organizational unit before you apply it to your network.
-
- When you change a security setting through a GPO and click **OK**, that setting will take effect the next time you refresh the settings.
-
-
## Related topics
-
-
[Security policy settings reference](security-policy-settings-reference.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/how-user-account-control-works.md b/windows/keep-secure/how-user-account-control-works.md
index c410eb2314..488f2bf4e5 100644
--- a/windows/keep-secure/how-user-account-control-works.md
+++ b/windows/keep-secure/how-user-account-control-works.md
@@ -2,277 +2,143 @@
title: How User Account Control works (Windows 10)
description: User Account Control (UAC) is a fundamental component of Microsoft's overall security vision. UAC helps mitigate the impact of malware.
ms.assetid: 9f921779-0fd3-4206-b0e4-05a19883ee59
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: operate
ms.sitesec: library
author: brianlic-msft
---
-
# How User Account Control works
-
-
**Applies to**
-
- Windows 10
-
User Account Control (UAC) is a fundamental component of Microsoft's overall security vision. UAC helps mitigate the impact of malware.
-
## UAC process and interactions
-
-
Each app that requires the administrator access token must prompt for consent. The one exception is the relationship that exists between parent and child processes. Child processes inherit the user's access token from the parent process. Both the parent and child processes, however, must have the same integrity level. Windows 10 protects processes by marking their integrity levels. Integrity levels are measurements of trust. A "high" integrity application is one that performs tasks that modify system data, such as a disk partitioning application, while a "low" integrity application is one that performs tasks that could potentially compromise the operating system, such as a Web browser. Apps with lower integrity levels cannot modify data in applications with higher integrity levels. When a standard user attempts to run an app that requires an administrator access token, UAC requires that the user provide valid administrator credentials.
-
In order to better understand how this process happens, let's look at the Windows logon process.
-
### Logon process
-
The following shows how the logon process for an administrator differs from the logon process for a standard user.
-
-
By default, standard users and administrators access resources and run apps in the security context of standard users. When a user logs on to a computer, the system creates an access token for that user. The access token contains information about the level of access that the user is granted, including specific security identifiers (SIDs) and Windows privileges.
-
When an administrator logs on, two separate access tokens are created for the user: a standard user access token and an administrator access token. The standard user access token contains the same user-specific information as the administrator access token, but the administrative Windows privileges and SIDs are removed. The standard user access token is used to start apps that do not perform administrative tasks (standard user apps). The standard user access token is then used to display the desktop (explorer.exe). Explorer.exe is the parent process from which all other user-initiated processes inherit their access token. As a result, all apps run as a standard user unless a user provides consent or credentials to approve an app to use a full administrative access token.
-
A user that is a member of the Administrators group can log on, browse the Web, and read e-mail while using a standard user access token. When the administrator needs to perform a task that requires the administrator access token, Windows 10 automatically prompts the user for approval. This prompt is called an elevation prompt, and its behavior can be configured by using the Local Security Policy snap-in (Secpol.msc) or Group Policy. For more info, see [User Account Control security policy settings](user-account-control-security-policy-settings.md).
-
### The UAC User Experience
-
When UAC is enabled, the user experience for standard users is different from that of administrators in Admin Approval Mode. The recommended and more secure method of running Windows 10 is to make your primary user account a standard user account. Running as a standard user helps to maximize security for a managed environment. With the built-in UAC elevation component, standard users can easily perform an administrative task by entering valid credentials for a local administrator account. The default, built-in UAC elevation component for standard users is the credential prompt.
-
The alternative to running as a standard user is to run as an administrator in Admin Approval Mode. With the built-in UAC elevation component, members of the local Administrators group can easily perform an administrative task by providing approval. The default, built-in UAC elevation component for an administrator account in Admin Approval Mode is called the consent prompt.
-
**The consent and credential prompts**
-
With UAC enabled, Windows 10 prompts for consent or prompts for credentials of a valid local administrator account before starting a program or task that requires a full administrator access token. This prompt ensures that no malicious software can be silently installed.
-
**The consent prompt**
-
The consent prompt is presented when a user attempts to perform a task that requires a user's administrative access token. The following is an example of the UAC consent prompt.
-
-
**The credential prompt**
-
The credential prompt is presented when a standard user attempts to perform a task that requires a user's administrative access token. Administrators can also be required to provide their credentials by setting the **User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode** policy setting value to **Prompt for credentials**.
-
The following is an example of the UAC credential prompt.
-
-
**UAC elevation prompts**
-
The UAC elevation prompts are color-coded to be app-specific, enabling for immediate identification of an application's potential security risk. When an app attempts to run with an administrator's full access token, Windows 10 first analyzes the executable file to determine its publisher. Apps are first separated into three categories based on the file's publisher: Windows 10, publisher verified (signed), and publisher not verified (unsigned). The following diagram illustrates how Windows 10 determines which color elevation prompt to present to the user.
-
The elevation prompt color-coding is as follows:
-
- Red background with a red shield icon: The app is blocked by Group Policy or is from a publisher that is blocked.
-
- Blue background with a blue and gold shield icon: The application is a Windows 10 administrative app, such as a Control Panel item.
-
- Blue background with a blue shield icon: The application is signed by using Authenticode and is trusted by the local computer.
-
- Yellow background with a yellow shield icon: The application is unsigned or signed but is not yet trusted by the local computer.
-
**Shield icon**
-
Some Control Panel items, such as **Date and Time Properties**, contain a combination of administrator and standard user operations. Standard users can view the clock and change the time zone, but a full administrator access token is required to change the local system time. The following is a screen shot of the **Date and Time Properties** Control Panel item.
-
-
The shield icon on the **Change date and time** button indicates that the process requires a full administrator access token and will display a UAC elevation prompt.
-
**Securing the elevation prompt**
-
The elevation process is further secured by directing the prompt to the secure desktop. The consent and credential prompts are displayed on the secure desktop by default in Windows 10. Only Windows processes can access the secure desktop. For higher levels of security, we recommend keeping the **User Account Control: Switch to the secure desktop when prompting for elevation** policy setting enabled.
-
When an executable file requests elevation, the interactive desktop, also called the user desktop, is switched to the secure desktop. The secure desktop dims the user desktop and displays an elevation prompt that must be responded to before continuing. When the user clicks **Yes** or **No**, the desktop switches back to the user desktop.
-
Malware can present an imitation of the secure desktop, but when the **User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode** policy setting is set to **Prompt for consent**, the malware does not gain elevation if the user clicks **Yes** on the imitation. If the policy setting is set to **Prompt for credentials**, malware imitating the credential prompt may be able to gather the credentials from the user. However, the malware does not gain elevated privilege and the system has other protections that mitigate malware from taking control of the user interface even with a harvested password.
-
While malware could present an imitation of the secure desktop, this issue cannot occur unless a user previously installed the malware on the PC. Because processes requiring an administrator access token cannot silently install when UAC is enabled, the user must explicitly provide consent by clicking **Yes** or by providing administrator credentials. The specific behavior of the UAC elevation prompt is dependent upon Group Policy.
-
## UAC Architecture
-
-
The following diagram details the UAC architecture.
-
-
To better understand each component, review the table below:
-
Component
Description
**User**
-
User performs operation requiring privilege
-
If the operation changes the file system or registry, Virtualization is called. All other operations call ShellExecute.
-
ShellExecute
-
ShellExecute calls CreateProcess. ShellExecute looks for the ERROR\_ELEVATION\_REQUIRED error from CreateProcess. If it receives the error, ShellExecute calls the Application Information service to attempt to perform the requested task with the elevated prompt.
-
CreateProcess
-
If the application requires elevation, CreateProcess rejects the call with ERROR\_ELEVATION\_REQUIRED.
-
**System**
-
Application Information service
-
A system service that helps start apps that require one or more elevated privileges or user rights to run, such as local administrative tasks, and apps that require higher integrity levels. The Application Information service helps start such apps by creating a new process for the application with an administrative user's full access token when elevation is required and (depending on Group Policy) consent is given by the user to do so.
-
Elevating an ActiveX install
-
If ActiveX is not installed, the system checks the UAC slider level. If ActiveX is installed, the **User Account Control: Switch to the secure desktop when prompting for elevation** Group Policy setting is checked.
-
Check UAC slider level
-
UAC has four levels of notification to choose from and a slider to use to select the notification level:
-
- High
-
If the slider is set to **Always notify**, the system checks whether the secure desktop is enabled.
-
- Medium
-
If the slider is set to **Notify me only when programs try to make changes to my computer**, the **User Account Control: Only elevate executable files that are signed and validated** policy setting is checked:
-
- If the policy setting is enabled, the public key infrastructure (PKI) certification path validation is enforced for a given file before it is permitted to run.
-
- If the policy setting is not enabled (default), the PKI certification path validation is not enforced before a given file is permitted to run. The **User Account Control: Switch to the secure desktop when prompting for elevation** Group Policy setting is checked.
-
- Low
-
If the slider is set to **Notify me only when apps try to make changes to my computer (do not dim by desktop)**, the CreateProcess is called.
-
- Never Notify
-
If the slider is set to **Never notify me when**, UAC prompt will never notify when an app is trying to install or trying to make any change on the computer.
-
**Important**
This setting is not recommended. This setting is the same as setting the **User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode** policy setting to **Elevate without prompting**.
-
-
Secure desktop enabled
-
The **User Account Control: Switch to the secure desktop when prompting for elevation** policy setting is checked:
-
- If the secure desktop is enabled, all elevation requests go to the secure desktop regardless of prompt behavior policy settings for administrators and standard users.
-
- If the secure desktop is not enabled, all elevation requests go to the interactive user's desktop, and the per-user settings for administrators and standard users are used.
-
CreateProcess
-
CreateProcess calls AppCompat, Fusion, and Installer detection to assess if the app requires elevation. The file is then inspected to determine its requested execution level, which is stored in the application manifest for the file. CreateProcess fails if the requested execution level specified in the manifest does not match the access token and returns an error (ERROR\_ELEVATION\_REQUIRED) to ShellExecute.
-
AppCompat
-
The AppCompat database stores information in the application compatibility fix entries for an application.
-
Fusion
-
The Fusion database stores information from application manifests that describe the applications. The manifest schema is updated to add a new requested execution level field.
-
Installer detection
-
Installer detection detects setup files, which helps prevent installations from being run without the user's knowledge and consent.
-
**Kernel**
-
Virtualization
-
Virtualization technology ensures that non-compliant apps do not silently fail to run or fail in a way that the cause cannot be determined. UAC also provides file and registry virtualization and logging for applications that write to protected areas.
-
File system and registry
-
The per-user file and registry virtualization redirects per-computer registry and file write requests to equivalent per-user locations. Read requests are redirected to the virtualized per-user location first and to the per-computer location second.
-
-
The slider will never turn UAC completely off. If you set it to **Never notify**, it will:
-
- Keep the UAC service running.
-
- Cause all elevation request initiated by administrators to be auto-approved without showing a UAC prompt.
-
- Automatically deny all elevation requests for standard users.
-
**Important**
In order to fully disable UAC you must disable the policy **User Account Control: Run all administrators in Admin Approval Mode**.
-
-
**Warning**
Universal Windows apps will not work when UAC is disabled.
-
-
### Virtualization
-
Because system administrators in enterprise environments attempt to secure systems, many line-of-business (LOB) applications are designed to use only a standard user access token. As a result, you do not need to replace the majority of apps when UAC is turned on.
-
Windows 10 includes file and registry virtualization technology for apps that are not UAC-compliant and that require an administrator's access token to run correctly. When an administrative apps that is not UAC-compliant attempts to write to a protected folder, such as Program Files, UAC gives the app its own virtualized view of the resource it is attempting to change. The virtualized copy is maintained in the user's profile. This strategy creates a separate copy of the virtualized file for each user that runs the non-compliant app.
-
Most app tasks operate properly by using virtualization features. Although virtualization allows a majority of applications to run, it is a short-term fix and not a long-term solution. App developers should modify their apps to be compliant as soon as possible, rather than relying on file, folder, and registry virtualization.
-
Virtualization is not an option in the following scenarios:
-
- Virtualization does not apply to apps that are elevated and run with a full administrative access token.
-
- Virtualization supports only 32-bit apps. Non-elevated 64-bit apps simply receive an access denied message when they attempt to acquire a handle (a unique identifier) to a Windows object. Native Windows 64-bit apps are required to be compatible with UAC and to write data into the correct locations.
-
- Virtualization is disabled if the app includes an app manifest with a requested execution level attribute.
-
### Request execution levels
-
An app manifest is an XML file that describes and identifies the shared and private side-by-side assemblies that an app should bind to at run time. The app manifest includes entries for UAC app compatibility purposes. Administrative apps that include an entry in the app manifest prompt the user for permission to access the user's access token. Although they lack an entry in the app manifest, most administrative app can run without modification by using app compatibility fixes. App compatibility fixes are database entries that enable applications that are not UAC-compliant to work properly.
-
All UAC-compliant apps should have a requested execution level added to the application manifest. If the application requires administrative access to the system, then marking the app with a requested execution level of "require administrator" ensures that the system identifies this program as an administrative app and performs the necessary elevation steps. Requested execution levels specify the privileges required for an app.
-
### Installer detection technology
-
Installation programs are apps designed to deploy software. Most installation programs write to system directories and registry keys. These protected system locations are typically writeable only by an administrator in Installer detection technology, which means that standard users do not have sufficient access to install programs. Windows 10 heuristically detects installation programs and requests administrator credentials or approval from the administrator user in order to run with access privileges. Windows 10 also heuristically detects updates and programs that uninstall applications. One of the design goals of UAC is to prevent installations from being run without the user's knowledge and consent because installation programs write to protected areas of the file system and registry.
-
Installer detection only applies to:
-
- 32-bit executable files.
-
- Applications without a requested execution level attribute.
-
- Interactive processes running as a standard user with UAC enabled.
-
Before a 32-bit process is created, the following attributes are checked to determine whether it is an installer:
-
- The file name includes keywords such as "install," "setup," or "update."
-
- Versioning Resource fields contain the following keywords: Vendor, Company Name, Product Name, File Description, Original Filename, Internal Name, and Export Name.
-
- Keywords in the side-by-side manifest are embedded in the executable file.
-
- Keywords in specific StringTable entries are linked in the executable file.
-
- Key attributes in the resource script data are linked in the executable file.
-
- There are targeted sequences of bytes within the executable file.
-
**Note**
The keywords and sequences of bytes were derived from common characteristics observed from various installer technologies.
-
-
**Note**
The User Account Control: Detect application installations and prompt for elevation policy setting must be enabled for installer detection to detect installation programs. For more info, see [User Account Control security policy settings](user-account-control-security-policy-settings.md).
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/images/atp.png b/windows/keep-secure/images/atp.png
index b300976d5e..840f89db48 100644
Binary files a/windows/keep-secure/images/atp.png and b/windows/keep-secure/images/atp.png differ
diff --git a/windows/keep-secure/images/machine-investigation.png b/windows/keep-secure/images/machine-investigation.png
index df55bcf318..d9ef2ad4a2 100644
Binary files a/windows/keep-secure/images/machine-investigation.png and b/windows/keep-secure/images/machine-investigation.png differ
diff --git a/windows/keep-secure/images/portqry.png b/windows/keep-secure/images/portqry.png
index 227b201d83..e14de2dc2d 100644
Binary files a/windows/keep-secure/images/portqry.png and b/windows/keep-secure/images/portqry.png differ
diff --git a/windows/keep-secure/images/windefatp-utc-console-autostart.png b/windows/keep-secure/images/windefatp-utc-console-autostart.png
index 99a69e555d..93daf5e81b 100644
Binary files a/windows/keep-secure/images/windefatp-utc-console-autostart.png and b/windows/keep-secure/images/windefatp-utc-console-autostart.png differ
diff --git a/windows/keep-secure/impersonate-a-client-after-authentication.md b/windows/keep-secure/impersonate-a-client-after-authentication.md
index c43d7641b6..45f008dc87 100644
--- a/windows/keep-secure/impersonate-a-client-after-authentication.md
+++ b/windows/keep-secure/impersonate-a-client-after-authentication.md
@@ -2,64 +2,37 @@
title: Impersonate a client after authentication (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Impersonate a client after authentication security policy setting.
ms.assetid: 4cd241e2-c680-4b43-8ed0-3b391925cec5
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Impersonate a client after authentication
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Impersonate a client after authentication** security policy setting.
-
## Reference
-
-
This policy setting determines which programs are allowed to impersonate a user or another specified account and act on behalf of the user. If this user right is required for this type of impersonation, an unauthorized user cannot cause a client to connect (for example, by remote procedure call (RPC) or named pipes) to a service that they have created to impersonate that client. (Such an action could elevate the unauthorized user's permissions to administrative or system levels.)
-
Impersonation is the ability of a thread to run in a security context that is different from the context of the process that owns the thread. Impersonation is designed to meet the security requirements of client/server applications. When running in a client's security context, a service "is" the client, to some degree. One of the service's threads uses an access token representing the client's credentials to obtain access to the objects to which the client has access.
-
The primary reason for impersonation is to cause access checks to be performed against the client's identity. Using the client's identity for access checks can cause access to be either restricted or expanded, depending on what the client has permission to do.
-
Services that are started by the Service Control Manager have the built-in Service group added by default to their access tokens. COM servers that are started by the COM infrastructure and configured to run under a specific account also have the Service group added to their access tokens. As a result, these processes are assigned this user right when they are started.
-
Constant: SeImpersonatePrivilege
-
### Possible values
-
- User-defined list of accounts
-
- Default values
-
- Not defined
-
### Best practices
-
- A user can impersonate an access token if any of the following conditions exist:
-
- The access token that is being impersonated is for this user.
-
- The user in this session logged on to the network with explicit credentials to create the access token.
-
- The requested level is less than Impersonate, such as Anonymous or Identify.
-
Because of these factors, users do not usually need to have this user right assigned.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
By default, this setting is Administrators, Local Service, Network Service, and Service on domain controllers and stand-alone servers.
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -113,59 +86,27 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
A restart of the computer is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
### Group Policy
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
An attacker with the **Impersonate a client after authentication** user right could create a service, mislead a client into connecting to the service, and then impersonate that computer to elevate the attacker's level of access to that of the device.
-
### Countermeasure
-
On member servers, ensure that only the Administrators and Service groups (Local Service, Network Service, and Service) have the **Impersonate a client after authentication** user right assigned to them.
-
### Potential impact
-
In most cases, this configuration has no impact. If you have installed optional components such as ASP.NET or IIS, you may need to assign the **Impersonate a client after authentication** user right to additional accounts that are required by those components, such as IUSR\_*<ComputerName>*, IIS\_WPG, ASP.NET, or IWAM\_*<ComputerName>*.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/implement-microsoft-passport-in-your-organization.md b/windows/keep-secure/implement-microsoft-passport-in-your-organization.md
index e7c4e15101..95e304939b 100644
--- a/windows/keep-secure/implement-microsoft-passport-in-your-organization.md
+++ b/windows/keep-secure/implement-microsoft-passport-in-your-organization.md
@@ -2,33 +2,26 @@
title: Implement Microsoft Passport in your organization (Windows 10)
description: You can create a Group Policy or mobile device management (MDM) policy that will implement Microsoft Passport on devices running Windows 10.
ms.assetid: 47B55221-24BE-482D-BD31-C78B22AC06D8
-keywords: ["identity", "PIN", "biometric", "Hello"]
+keywords: identity, PIN, biometric, Hello
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: jdeckerMS
---
# Implement Microsoft Passport in your organization
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
You can create a Group Policy or mobile device management (MDM) policy that will implement Microsoft Passport on devices running Windows 10.
-
-**Important**
-The Group Policy setting **Turn on PIN sign-in** does not apply to Windows 10. Use **Microsoft Passport for Work** policy settings to manage PINs.
-
+> **Important:** The Group Policy setting **Turn on PIN sign-in** does not apply to Windows 10. Use **Microsoft Passport for Work** policy settings to manage PINs.
-
## Group Policy settings for Passport
-
The following table lists the Group Policy settings that you can configure for Passport use in your workplace. These policy settings are available in **Computer Configuration** > **Policies** > **Administrative Templates** > **Windows Components** > **Microsoft Passport for Work**.
-
| Policy |
@@ -145,9 +138,7 @@ The following table lists the Group Policy settings that you can configure for P
## MDM policy settings for Passport
-
The following table lists the MDM policy settings that you can configure for Passport use in your workplace. These MDM policy settings use the [PassportForWork configuration service provider (CSP)](http://go.microsoft.com/fwlink/p/?LinkId=692070).
-
| Policy |
@@ -293,14 +284,10 @@ The following table lists the MDM policy settings that you can configure for Pas
**Note**
If policy is not configured to explicitly require letters or special characters, users will be restricted to creating a numeric PIN.
-
-
## Prerequisites
-
You’ll need this software to set Microsoft Passport policies in your enterprise.
-
@@ -355,25 +342,18 @@ You’ll need this software to set Microsoft Passport policies in your enterpris
-
-
Configuration Manager and MDM provide the ability to manage Passport policy and to deploy and manage certificates protected by Passport.
-
Azure AD provides the ability to register devices with your enterprise and to provision Passport for organization accounts.
-
Active Directory provides the ability to authorize users and devices using keys protected by Passport if domain controllers are running Windows 10 and the Microsoft Passport provisioning service in Windows 10 AD FS.
## Passport for BYOD
-
Passport can be managed on personal devices that your employees use for work purposes using MDM. On personal devices, users can create a personal Passport PIN for unlocking the device and a separate work PIN for access to work resources.
-
The work PIN is managed using the same Passport policies that you can use to manage Passport on organization owned devices. The personal PIN is managed separately using DeviceLock policy. DeviceLock policy can be used to control length, complexity, history, and expiration requirements and can be configured using the [Policy configuration service provider](http://go.microsoft.com/fwlink/p/?LinkID=623244).
## Related topics
-
[Windows Hello biometrics in the enterprise](windows-hello-in-enterprise.md)
[Why a PIN is better than a password](why-a-pin-is-better-than-a-password.md)
@@ -384,15 +364,8 @@ The work PIN is managed using the same Passport policies that you can use to man
[Microsoft Passport and password changes](microsoft-passport-and-password-changes.md)
+
[Microsoft Passport errors during PIN creation](microsoft-passport-errors-during-pin-creation.md)
[Event ID 300 - Passport successfully created](passport-event-300.md)
-
-
-
-
-
-
-
-
-
+
\ No newline at end of file
diff --git a/windows/keep-secure/import-an-applocker-policy-from-another-computer.md b/windows/keep-secure/import-an-applocker-policy-from-another-computer.md
index f8a57d092a..02cf23e310 100644
--- a/windows/keep-secure/import-an-applocker-policy-from-another-computer.md
+++ b/windows/keep-secure/import-an-applocker-policy-from-another-computer.md
@@ -2,45 +2,25 @@
title: Import an AppLocker policy from another computer (Windows 10)
description: This topic for IT professionals describes how to import an AppLocker policy.
ms.assetid: b48cb2b2-8ef8-4cc0-89bd-309d0b1832f6
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Import an AppLocker policy from another computer
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals describes how to import an AppLocker policy.
-
Before completing this procedure, you should have exported an AppLocker policy. For more information, see [Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md).
-
Membership in the local **Administrators** group, or equivalent, is the minimum required to complete this procedure.
-
**Caution**
Importing a policy will overwrite the existing policy on that computer.
-
-
**To import an AppLocker policy**
-
1. From the AppLocker console, right-click **AppLocker**, and then click **Import Policy**.
-
2. In the **Import Policy** dialog box, locate the file that you exported, and then click **Open**.
-
3. The **Import Policy** dialog box will warn you that importing a policy will overwrite the existing rules and enforcement settings. If acceptable, click **OK** to import and overwrite the policy.
-
4. The **AppLocker** dialog box will notify you of how many rules were overwritten and imported. Click **OK**.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/import-an-applocker-policy-into-a-gpo.md b/windows/keep-secure/import-an-applocker-policy-into-a-gpo.md
index 5124290a7d..94411b2263 100644
--- a/windows/keep-secure/import-an-applocker-policy-into-a-gpo.md
+++ b/windows/keep-secure/import-an-applocker-policy-into-a-gpo.md
@@ -2,47 +2,26 @@
title: Import an AppLocker policy into a GPO (Windows 10)
description: This topic for IT professionals describes the steps to import an AppLocker policy into a Group Policy Object (GPO).
ms.assetid: 0629ce44-f5e2-48a8-ba47-06544c73261f
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Import an AppLocker policy into a GPO
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals describes the steps to import an AppLocker policy into a Group Policy Object (GPO).
-
AppLocker policies can be created as local security policies and modified like any other local security policy, or they can be created as part of a GPO and managed by using Group Policy. You can create AppLocker policies on any supported computer. For info about which Windows editions are supported, see [Requirements to Use AppLocker](requirements-to-use-applocker.md).
-
**Important**
Follow your organization's standard procedures for updating GPOs. For info about specific steps to follow for AppLocker policies, see [Maintain AppLocker policies](maintain-applocker-policies.md).
-
-
To complete this procedure, you must have the **Edit Setting** permission to edit a GPO. By default, members of the **Domain Admins** group, the **Enterprise Admins** group, and the **Group Policy Creator Owners** group have this permission.
-
**To import an AppLocker policy into a GPO**
-
1. In the Group Policy Management Console (GPMC), open the GPO that you want to edit.
-
2. In the console tree under **Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Application Control Policies**, click **AppLocker**.
-
3. Right-click **AppLocker**, and then click **Import Policy**.
-
4. In the **Import Policy** dialog box, locate the XML policy file, and click **Open**.
-
5. The **AppLocker** dialog box will notify you of how many rules were imported. Click **OK**.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/increase-a-process-working-set.md b/windows/keep-secure/increase-a-process-working-set.md
index de979e2f5a..8b8320a5d9 100644
--- a/windows/keep-secure/increase-a-process-working-set.md
+++ b/windows/keep-secure/increase-a-process-working-set.md
@@ -2,48 +2,29 @@
title: Increase a process working set (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Increase a process working set security policy setting.
ms.assetid: b742ad96-37f3-4686-b8f7-f2b48367105b
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Increase a process working set
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Increase a process working set** security policy setting.
-
## Reference
-
-
This policy setting determines which users can increase or decrease the size of the working set of a process. The working set of a process is the set of memory pages currently visible to the process in physical RAM. These pages are resident, and they are available for an application to use without triggering a page fault. The minimum and maximum working set sizes affect the virtual memory paging behavior of a process.
-
Constant: SeIncreaseWorkingSetPrivilege
-
### Possible values
-
- User-defined list of accounts
-
- Not Defined
-
### Best practices
-
- You should make users aware that adverse performance issues may occur if they modify this security setting.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
By default, standard users have this right.
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -82,59 +63,27 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
A restart of the computer is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
### Group Policy
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Increasing the working set size for a process decreases the amount of physical memory that is available to the rest of the system.
-
### Countermeasure
-
Increase user’s awareness about the impact of increasing the working set of a process and how to recognize that their system is adversely affected if they change this setting.
-
### Potential impact
-
None. Allowing standard users to increase the working set of a process is the default configuration.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/increase-scheduling-priority.md b/windows/keep-secure/increase-scheduling-priority.md
index 62107e69fa..187e8ef3a7 100644
--- a/windows/keep-secure/increase-scheduling-priority.md
+++ b/windows/keep-secure/increase-scheduling-priority.md
@@ -2,52 +2,31 @@
title: Increase scheduling priority (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Increase scheduling priority security policy setting.
ms.assetid: fbec5973-d35e-4797-9626-d0d56061527f
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Increase scheduling priority
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Increase scheduling priority** security policy setting.
-
## Reference
-
-
This policy setting determines which user accounts can increase the base priority class of a process. It is not a privileged operation to increase relative priority within a priority class. This user right is not required by administrative tools that are supplied with the operating system, but it might be required by software development tools.
-
Specifically, this security setting determines which accounts can use a process with Write Property access to another process to increase the run priority that is assigned to the other process. A user with this privilege can change the scheduling priority of a process through the Task Manager user interface.
-
Constant: SeIncreaseBasePriorityPrivilege
-
### Possible values
-
- User-defined list of accounts
-
- Not defined
-
- Administrators
-
### Best practices
-
- Allow the default value, Administrators, as the only account responsible for controlling process scheduling priorities.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
By default this setting is Administrators on domain controllers and on stand-alone servers.
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -86,59 +65,27 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
A restart of the computer is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
### Group Policy
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
A user who is assigned this user right could increase the scheduling priority of a process to Real-Time, which would leave little processing time for all other processes and could lead to a denial-of-service condition.
-
### Countermeasure
-
Verify that only Administrators have the **Increase scheduling priority** user right assigned to them.
-
### Potential impact
-
None. Restricting the **Increase scheduling priority** user right to members of the Administrators group is the default configuration.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/index.md b/windows/keep-secure/index.md
index f2a2ac4b8c..5b1c59fb81 100644
--- a/windows/keep-secure/index.md
+++ b/windows/keep-secure/index.md
@@ -5,96 +5,33 @@ ms.assetid: EA559BA8-734F-41DB-A74A-D8DBF36BE920
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
-
# Keep Windows 10 secure
-
Learn about keeping Windows 10 and Windows 10 Mobile secure.
## In this section
-
-
-
-
-
-
-
-
-
-
-
-[Change history for Keep Windows 10 secure](change-history-for-keep-windows-10-secure.md) |
-This topic lists new and updated topics in the Keep Windows 10 secure documentation for [Windows 10 and Windows 10 Mobile](../index.md). |
-
-
-[Block untrusted fonts in an enterprise](block-untrusted-fonts-in-enterprise.md) |
-To help protect your company from attacks which may originate from untrusted or attacker controlled font files, we’ve created the Blocking Untrusted Fonts feature. Using this feature, you can turn on a global setting that stops your employees from loading untrusted fonts processed using the Graphics Device Interface (GDI) onto your network. Untrusted fonts are any font installed outside of the %windir%/Fonts directory. Blocking untrusted fonts helps prevent both remote (web-based or email-based) and local EOP attacks that can happen during the font file-parsing process. |
-
-
-[Device Guard certification and compliance](device-guard-certification-and-compliance.md) |
-Device Guard is a combination of hardware and software security features that, when configured together, will lock a device down so that it can only run trusted applications. If the app isn’t trusted it can’t run, period. It also means that even if an attacker manages to get control of the Windows kernel, he or she will be much less likely to be able to run malicious executable code after the computer restarts because of how decisions are made about what can run and when. |
-
-
-[Manage identity verification using Microsoft Passport](manage-identity-verification-using-microsoft-passport.md) |
-In Windows 10, Microsoft Passport replaces passwords with strong two-factor authentication on PCs and mobile devices. This authentication consists of a new type of user credential that is tied to a device and a Windows Hello (biometric) or PIN. |
-
-
-[Windows Hello biometrics in the enterprise](windows-hello-in-enterprise.md) |
-Windows Hello is the biometric authentication feature that helps strengthen authentication and helps to guard against potential spoofing through fingerprint matching and facial recognition. |
-
-
-[Configure S/MIME for Windows 10 and Windows 10 Mobile](configure-s-mime.md) |
-In Windows 10, S/MIME lets users encrypt outgoing messages and attachments so that only intended recipients who have a digital identification (ID), also known as a certificate, can read them. Users can digitally sign a message, which provides the recipients with a way to verify the identity of the sender and that the message hasn't been tampered with. |
-
-
-[Install digital certificates on Windows 10 Mobile](installing-digital-certificates-on-windows-10-mobile.md) |
-Digital certificates bind the identity of a user or computer to a pair of keys that can be used to encrypt and sign digital information. Certificates are issued by a certification authority (CA) that vouches for the identity of the certificate holder, and they enable secure client communications with websites and services. |
-
-
-[Protect derived domain credentials with Credential Guard](credential-guard.md) |
-Introduced in Windows 10 Enterprise, Credential Guard uses virtualization-based security to isolate secrets so that only privileged system software can access them. Unauthorized access to these secrets can lead to credential theft attacks, such as Pass-the-Hash or Pass-The-Ticket. Credential Guard prevents these attacks by protecting NTLM password hashes and Kerberos Ticket Granting Tickets. |
-
-
-[Protect your enterprise data using enterprise data protection (EDP)](protect-enterprise-data-using-edp.md) |
-With the increase of employee-owned devices in the enterprise, there’s also an increasing risk of accidental data leak through apps and services, like email, social media, and the public cloud, which are outside of the enterprise’s control. For example, when an employee sends the latest engineering pictures from their personal email account, copies and pastes product info into a tweet, or saves an in-progress sales report to their public cloud storage. |
-
-
-[Use Windows Event Forwarding to help with intrusion detection](use-windows-event-forwarding-to-assist-in-instrusion-detection.md) |
-Learn about an approach to collect events from devices in your organization. This article talks about events in both normal operations and when an intrusion is suspected. |
-
-
-[VPN profile options](vpn-profile-options.md) |
-Virtual private networks (VPN) let you give your users secure remote access to your company network. Windows 10 adds useful new VPN profile options to help you manage how users connect. |
-
-
-[Security technologies](security-technologies.md) |
-Learn more about the different security technologies that are available in Windows 10 and Windows 10 Mobile. |
-
-
-[Enterprise security guides](windows-10-enterprise-security-guides.md) |
-Get proven guidance to help you better secure and protect your enterprise by using technologies such as Credential Guard, Device Guard, Microsoft Passport, and Windows Hello. This section offers technology overviews and step-by-step guides. |
-
-
-
-
+| Topic | Description |
+| - | - |
+| [Change history for Keep Windows 10 secure](change-history-for-keep-windows-10-secure.md) | This topic lists new and updated topics in the Keep Windows 10 secure documentation for [Windows 10 and Windows 10 Mobile](../index.md). |
+| [Block untrusted fonts in an enterprise](block-untrusted-fonts-in-enterprise.md) | To help protect your company from attacks which may originate from untrusted or attacker controlled font files, we’ve created the Blocking Untrusted Fonts feature. Using this feature, you can turn on a global setting that stops your employees from loading untrusted fonts processed using the Graphics Device Interface (GDI) onto your network. Untrusted fonts are any font installed outside of the %windir%/Fonts directory. Blocking untrusted fonts helps prevent both remote (web-based or email-based) and local EOP attacks that can happen during the font file-parsing process. |
+| [Device Guard certification and compliance](device-guard-certification-and-compliance.md) | Device Guard is a combination of hardware and software security features that, when configured together, will lock a device down so that it can only run trusted applications. If the app isn’t trusted it can’t run, period. It also means that even if an attacker manages to get control of the Windows kernel, he or she will be much less likely to be able to run malicious executable code after the computer restarts because of how decisions are made about what can run and when. |
+| [Manage identity verification using Microsoft Passport](manage-identity-verification-using-microsoft-passport.md) | In Windows 10, Microsoft Passport replaces passwords with strong two-factor authentication on PCs and mobile devices. This authentication consists of a new type of user credential that is tied to a device and a Windows Hello (biometric) or PIN. |
+| [Windows Hello biometrics in the enterprise](windows-hello-in-enterprise.md) | Windows Hello is the biometric authentication feature that helps strengthen authentication and helps to guard against potential spoofing through fingerprint matching and facial recognition. |
+| [Configure S/MIME for Windows 10 and Windows 10 Mobile](configure-s-mime.md) | In Windows 10, S/MIME lets users encrypt outgoing messages and attachments so that only intended recipients who have a digital identification (ID), also known as a certificate, can read them. Users can digitally sign a message, which provides the recipients with a way to verify the identity of the sender and that the message hasn't been tampered with. |
+| [Install digital certificates on Windows 10 Mobile](installing-digital-certificates-on-windows-10-mobile.md) | Digital certificates bind the identity of a user or computer to a pair of keys that can be used to encrypt and sign digital information. Certificates are issued by a certification authority (CA) that vouches for the identity of the certificate holder, and they enable secure client communications with websites and services. |
+| [Protect derived domain credentials with Credential Guard](credential-guard.md) | Introduced in Windows 10 Enterprise, Credential Guard uses virtualization-based security to isolate secrets so that only privileged system software can access them. Unauthorized access to these secrets can lead to credential theft attacks, such as Pass-the-Hash or Pass-The-Ticket. Credential Guard prevents these attacks by protecting NTLM password hashes and Kerberos Ticket Granting Tickets. |
+| [Protect your enterprise data using enterprise data protection (EDP)](protect-enterprise-data-using-edp.md) | With the increase of employee-owned devices in the enterprise, there’s also an increasing risk of accidental data leak through apps and services, like email, social media, and the public cloud, which are outside of the enterprise’s control. For example, when an employee sends the latest engineering pictures from their personal email account, copies and pastes product info into a tweet, or saves an in-progress sales report to their public cloud storage. |
+| [Use Windows Event Forwarding to help with intrusion detection](use-windows-event-forwarding-to-assist-in-instrusion-detection.md) | Learn about an approach to collect events from devices in your organization. This article talks about events in both normal operations and when an intrusion is suspected. |
+| [VPN profile options](vpn-profile-options.md) | Virtual private networks (VPN) let you give your users secure remote access to your company network. Windows 10 adds useful new VPN profile options to help you manage how users connect. |
+| [Security technologies](security-technologies.md) | Learn more about the different security technologies that are available in Windows 10 and Windows 10 Mobile. |
+| [Enterprise security guides](windows-10-enterprise-security-guides.md) | Get proven guidance to help you better secure and protect your enterprise by using technologies such as Credential Guard, Device Guard, Microsoft Passport, and Windows Hello. This section offers technology overviews and step-by-step guides. |
-
## Related topics
-
[Windows 10 and Windows 10 Mobile](../index.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/initialize-and-configure-ownership-of-the-tpm.md b/windows/keep-secure/initialize-and-configure-ownership-of-the-tpm.md
index 5a4aa84615..4325b85cc9 100644
--- a/windows/keep-secure/initialize-and-configure-ownership-of-the-tpm.md
+++ b/windows/keep-secure/initialize-and-configure-ownership-of-the-tpm.md
@@ -2,125 +2,70 @@
title: Initialize and configure ownership of the TPM (Windows 10)
description: This topic for the IT professional describes how to initialize and set the ownership the Trusted Platform Module (TPM), turn the TPM on and off, and clear TPM keys.
ms.assetid: 1166efaf-7aa3-4420-9279-435d9c6ac6f8
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Initialize and configure ownership of the TPM
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional describes how to initialize and set the ownership the Trusted Platform Module (TPM), turn the TPM on and off, and clear TPM keys. It also explains how to troubleshoot issues that you might encounter as a result of using these procedures.
-
## About TPM initialization and ownership
-
-
The TPM must be initialized and ownership must be taken before it can be used to help secure your computer. The owner of the TPM is the user who possesses the owner password and is able to set it and change it. Only one owner password exists per TPM. The owner of the TPM can make full use of TPM capabilities. Taking ownership of the TPM can be done as part of the initialization process.
-
When you start the TPM Initialization Wizard, which is accessed through the TPM Microsoft Management Console (MMC), you can determine whether the computer's TPM has been initialized. You can also view the TPM properties.
-
This topic contains procedures for the following tasks:
-
- [Initialize the TPM and set ownership](#bkmk-initializetpm)
-
- [Troubleshoot TPM initialization](#bkmk-troubleshootinit)
-
- [Turn on or turn off the TPM](#bkmk-onoff)
-
- [Clear all the keys from the TPM](#bkmk-clear1)
-
- [Use the TPM cmdlets](#bkmk-tpmcmdlets)
-
## Initialize the TPM and set ownership
-
-
Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. In addition, the computer must be equipped with a Trusted Computing Group-compliant BIOS.
-
**To start the TPM Initialization Wizard**
-
1. Open the TPM Management console (tpm.msc). If the **User Account Control** dialog box appears, confirm that the action it displays is what you want, and then click **Yes**.
-
2. On the **Action** menu, click **Initialize TPM** to start the TPM Initialization Wizard.
-
3. If the TPM has never been initialized or is turned off, the TPM Initialization Wizard displays the **Turn on the TPM security hardware** dialog box. This dialog box provides guidance for initializing or turning on the TPM. Follow the instructions in the wizard.
-
**Note**
If the TPM is already turned on, the TPM Initialization Wizard displays the **Create the TPM owner password** dialog box. Skip the remainder of this procedure and continue with the [To set ownership of the TPM](#bkmk-setownership) procedure.
-
-
**Note**
If the TPM Initialization Wizard detects that you do not have a compatible BIOS, you cannot continue with the TPM Initialization Wizard, and you are alerted to consult the computer manufacturer's documentation for instructions to initialize the TPM.
-
-
4. Click **Restart**.
-
5. Follow the BIOS screen prompts. An acceptance prompt is displayed to ensure that a user has physical access to the computer and that no malicious software is attempting to turn on the TPM.
-
**Note**
BIOS screen prompts and the required keystrokes vary by computer manufacturer.
-
-
6. After the computer restarts, sign in to the computer with the same administrative credentials that you used to start this procedure.
-
7. The TPM Initialization Wizard automatically restarts. If the **User Account Control** dialog box appears, confirm that the action it displays is what you want, and then click **Yes**.
-
8. Continue with the next procedure to take ownership of the TPM.
-
To finish initializing the TPM for use, you must set an owner for the TPM. The process of taking ownership includes creating an owner password for the TPM.
-
**To set ownership of the TPM**
-
1. If you are not continuing immediately from the last procedure, start the TPM Initialization Wizard. If you need to review the steps to do so, see the previous procedure [To start the TPM Initialization Wizard](#bkmk-starttpminitwizard).
-
2. In the **Create the TPM owner password** dialog box, click **Automatically create the password (recommended)**.
-
3. In the **Save your TPM owner password** dialog box, click **Save the password**.
-
4. In the **Save As** dialog box, select a location to save the password, and then click **Save**. The password file is saved as *computer\_name.tpm*.
-
**Important**
We highly recommend saving the TPM owner password to a removable storage device and storing it in a safe location.
-
-
5. Click **Print the password** if you want to print a copy of your password.
-
**Important**
We highly recommend printing a copy of your TPM owner password and storing it in a safe location.
-
-
6. Click **Initialize**.
-
**Note**
The process of initializing the TPM might take a few minutes to complete.
-
-
7. Click **Close**.
-
**Caution**
Do not lose your password. If you do, you will be unable to make administrative changes unless you clear the TPM, which can result in data loss.
-
-
## Troubleshoot TPM initialization
-
-
Managing the Trusted Platform Module (TPM) is usually a straightforward procedure. If are unable to complete the initialization procedure, review the following information:
-
- If the TPM is not detected by Windows, verify that your computer hardware contains a Trusted Computing Group-compliant BIOS. Ensure that no BIOS settings have been used to hide the TPM from the operating system.
-
- If you are attempting to initialize the TPM as part of the BitLocker setup, check which TPM driver is installed on the computer. We recommend always using one of the TPM drivers that is provided by Microsoft and is protected with BitLocker. If a non-Microsoft TPM driver is installed, it may prevent the default TPM driver from loading and cause BitLocker to report that a TPM is not present on the computer. If you have a non-Microsoft driver installed, remove it and then try to initialize the TPM. The following table lists the three standard TPM drivers that are provided by Microsoft.
-
@@ -147,134 +92,66 @@ Managing the Trusted Platform Module (TPM) is usually a straightforward procedur
-
-
- If the TPM has been previously initialized and you do not have the owner password, you may have to clear or reset the TPM to the factory default values. For more information, see [Clear all the keys from the TPM](#bkmk-clear1).
-
**Caution**
Clearing the TPM can result in data loss. To avoid data loss, make sure that you have a backup or recovery method for any data that is protected or encrypted by the TPM.
-
-
Because your TPM security hardware is a physical part of your computer, you may want to read the manuals or instructions that came with your computer, or search the manufacturer's website.
-
**Network connection**
-
You cannot complete the initialization of the Trusted Platform Module (TPM) when your computer is disconnected from your organization's network if either of the following conditions exist:
-
- An administrator has configured your computer to require that TPM recovery information be saved in Active Directory Domain Services (AD DS). This requirement can be configured through Group Policy.
-
- A domain controller cannot be reached. This can occur on a computer that is currently disconnected from the network, separated from the domain by a firewall, or experiencing a network component failure (such as an unplugged cable or a faulty network adapter).
-
In either case, an error message appears, and you cannot complete the initialization process. To avoid this issue, initialize the TPM while you are connected to the corporate network and you can contact a domain controller.
-
**Systems with multiple TPMs**
-
Some systems may have multiple TPMs and the active TPM may be toggled in the BIOS. Windows 10 does not support this behavior. If you switch TPMs, functionality that depends on the TPM will not work with the new TPM unless it is cleared and put through provisioning. Performing this clear may cause data loss, in particular of keys and certificates associated with the previous TPM. For example, toggling TPMs will cause Bitlocker to enter recovery mode. It is strongly recommended that, on systems with two TPMs, one TPM is selected to be used and the selection is not changed.
-
## Turn on or turn off the TPM
-
-
Normally, the TPM is turned on as part of the TPM initialization process. You do not normally need to turn the TPM on or off. However, if necessary you can do so by using the TPM MMC.
-
### Turn on the TPM
-
If the TPM has been initialized but has never been used, or if you want to use the TPM after you have turned it off, you can use the following procedure to turn on the TPM.
-
**To turn on the TPM**
-
1. Open the TPM MMC (tpm.msc).
-
2. In the **Action** pane, click **Turn TPM On** to display the **Turn on the TPM Security Hardware** page. Read the instructions on this page.
-
3. Click **Shutdown** (or **Restart**), and then follow the BIOS screen prompts.
-
After the computer restarts, but before you sign in to Windows, you will be prompted to accept the reconfiguration of the TPM. This ensures that the user has physical access to the computer and that malicious software is not attempting to make changes to the TPM.
-
### Turn off the TPM
-
If you want to stop using the services that are provided by the TPM, you can use the TPM MMC to turn off the TPM. If you have the TPM owner password, physical access to the computer is not required to turn off the TPM. If you do not have the TPM owner password, you must have physical access to the computer to turn off the TPM.
-
**To turn off the TPM**
-
1. Open the TPM MMC (tpm.msc).
-
2. In the **Action** pane, click **Turn TPM Off** to display the **Turn off the TPM security hardware** page.
-
3. In the **Turn off the TPM security hardware** dialog box, select a method to enter your owner password and turning off the TPM:
-
- If you saved your TPM owner password on a removable storage device, insert it, and then click **I have the owner password file**. In the **Select backup file with the TPM owner password** dialog box, click **Browse** to locate the .tpm file that is saved on your removable storage device, click **Open**, and then click **Turn TPM Off**.
-
- If you do not have the removable storage device with your saved TPM owner password, click **I want to enter the password**. In the **Type your TPM owner password** dialog box, type your password (including hyphens), and then click **Turn TPM Off**.
-
- If you do not know your TPM owner password, click **I do not have the TPM owner password**, and follow the instructions that are provided in the dialog box and subsequent BIOS screens to turn off the TPM without entering the password.
-
## Clear all the keys from the TPM
-
-
Clearing the TPM resets it to an unowned state. After clearing the TPM, you need to complete the TPM initialization process before using software that relies on the TPM, such as BitLocker Drive Encryption. By default, the TPM is initialized automatically.
-
**Important**
Clearing the TPM can result in data loss. To avoid data loss, make sure that you have a backup or recovery method for any data that is protected or encrypted by the TPM.
-
-
After the TPM is cleared, it is also turned off.
-
To temporarily suspend TPM operations, turn off the TPM instead of clearing it.
-
Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure.
-
**To clear the TPM**
-
1. Open the TPM MMC (tpm.msc).
-
2. If the **User Account Control** dialog box appears, confirm that the action it displays is what you want, and then click **Yes**.
-
3. Under **Actions**, click **Clear TPM**.
-
**Warning**
If the TPM is off, reinitialize it before clearing it.
-
Clearing the TPM resets it to factory defaults and turns it off. You will lose all created keys and data that is protected by those keys.
-
-
4. In the **Clear the TPM security hardware** dialog box, select one of the following methods to enter your password and clear the TPM:
-
- If you have the removable storage device with your saved TPM owner password, insert it, and click **I have the owner password file**. In the **Select backup file with the TPM owner password** dialog box, use **Browse** to navigate to the .tpm file that is saved on your removable storage device. Click **Open**, and then click **Clear TPM**.
-
- If you do not have the removable storage device with your saved password, click **I want to enter the owner password**. In the **Type your TPM owner password** dialog box, type your password (including hyphens), and click **Clear TPM**.
-
- If you do not know your TPM owner password, click **I don't have the TPM owner password**, and follow the instructions that are provided to clear the TPM without entering the password.
-
**Note**
If you have physical access to the computer, you can clear the TPM and perform a limited number of management tasks without entering the TPM owner password.
-
-
The status of your TPM is displayed under **Status** in TPM MMC.
-
## Use the TPM cmdlets
-
-
If you are using Windows PowerShell to manage your computers, you can also manage the TPM by using Windows PowerShell. To install the TPM cmdlets, type the following command:
-
**dism /online /enable-feature /FeatureName:tpm-psh-cmdlets**
-
For details about the individual cmdlets, see [TPM Cmdlets in Windows PowerShell](http://technet.microsoft.com/library/jj603116.aspx).
-
## Additional resources
-
-
For more info about TPM, see [Trusted Platform Module Technology Overview](trusted-platform-module-overview.md#bkmk-additionalresources).
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/installing-digital-certificates-on-windows-10-mobile.md b/windows/keep-secure/installing-digital-certificates-on-windows-10-mobile.md
index 3f2c80a143..8034f861f4 100644
--- a/windows/keep-secure/installing-digital-certificates-on-windows-10-mobile.md
+++ b/windows/keep-secure/installing-digital-certificates-on-windows-10-mobile.md
@@ -2,24 +2,22 @@
title: Install digital certificates on Windows 10 Mobile (Windows 10)
description: Digital certificates bind the identity of a user or computer to a pair of keys that can be used to encrypt and sign digital information.
ms.assetid: FF7B1BE9-41F4-44B0-A442-249B650CEE25
-keywords: ["S/MIME", "PFX", "SCEP"]
+keywords: S/MIME, PFX, SCEP
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: jdeckerMS
---
# Install digital certificates on Windows 10 Mobile
-
**Applies to**
-
- Windows 10 Mobile
Digital certificates bind the identity of a user or computer to a pair of keys that can be used to encrypt and sign digital information. Certificates are issued by a certification authority (CA) that vouches for the identity of the certificate holder, and they enable secure client communications with websites and services.
Certificates in Windows 10 Mobile are primarily used for the following purposes:
-
- To create a secure channel using Secure Sockets Layer (SSL) between a phone and a web server or service.
- To authenticate a user to a reverse proxy server that is used to enable Microsoft Exchange ActiveSync (EAS) for email.
- For installation and licensing of applications (from the Windows Phone Store or a custom company distribution site).
@@ -29,24 +27,17 @@ In Windows 10, Version 1607, if you have multiple certificates provisioned on th
## Install certificates using Internet Explorer
-
A certificate can be posted on a website and made available to users through a device-accessible URL that they can use to download the certificate. When a user accesses the page and taps the certificate, it opens on the device. The user can inspect the certificate, and if they choose to continue, the certificate is installed on the Windows 10 Mobile device.
## Install certificates using email
-
The Windows 10 Mobile certificate installer supports .cer, .p7b, .pem, and .pfx files. To install certificates via email, make sure your mail filters do not block .cer files. Certificates that are sent via email appear as message attachments. When a certificate is received, a user can tap to review the contents and then tap to install the certificate. Typically, when an identity certificate is installed, the user is prompted for the password (or passphrase) that protects it.
## Install certificates using mobile device management (MDM)
-
Windows 10 Mobile supports root, CA, and client certificate to be configured via MDM. Using MDM, an administrator can directly add, delete, or query root and CA certificates, and configure the device to enroll a client certificate with a certificate enrollment server that supports Simple Certificate Enrollment Protocol (SCEP). SCEP enrolled client certificates are used by Wi-Fi, VPN, email, and browser for certificate-based client authentication. An MDM server can also query and delete SCEP enrolled client certificate (including user installed certificates), or trigger a new enrollment request before the current certificate is expired.
-
-**Warning**
-Do not use SCEP for encryption certificates for S/MIME. You must use a PFX certificate profile to support S/MIME on Windows 10 Mobile. For instructions on creating a PFX certificate profile in Microsoft Intune, see [Enable access to company resources using certificate profiles with Microsoft Intune](http://go.microsoft.com/fwlink/p/?LinkID=718216).
-
+> **Warning:** Do not use SCEP for encryption certificates for S/MIME. You must use a PFX certificate profile to support S/MIME on Windows 10 Mobile. For instructions on creating a PFX certificate profile in Microsoft Intune, see [Enable access to company resources using certificate profiles with Microsoft Intune](http://go.microsoft.com/fwlink/p/?LinkID=718216).
-
**Process of installing certificates using MDM**
1. The MDM server generates the initial cert enroll request including challenge password, SCEP server URL, and other enrollment related parameters.
@@ -57,34 +48,16 @@ Do not use SCEP for encryption certificates for S/MIME. You must use a PFX certi
6. The device connects to Internet facing point exposed by MDM server.
7. MDM server creates a certificate that is signed with proper CA certificate and returns it to device.
- **Note**
- The device supports the pending function to allow server side to do additional verification before issuing the cert. In this case, a pending status is sent back to the device. The device will periodically contact the server, based on preconfigured retry count and retry period parameters. Retrying ends when either:
-
+ > **Note:** The device supports the pending function to allow server side to do additional verification before issuing the cert. In this case, a pending status is sent back to the device. The device will periodically contact the server, based on preconfigured retry count and retry period parameters. Retrying ends when either:
A certificate is successfully received from the server
-
The server returns an error
-
The number of retries reaches the preconfigured limit
-
-
8. The cert is installed in the device. Browser, Wi-Fi, VPN, email, and other first party applications have access to this certificate.
- **Note**
- If MDM requested private key being stored in Trusted Process Module (TPM) (configured during enrollment request), the private key will be saved in TPM. Note that SCEP enrolled cert protected by TPM isn’t guarded by a PIN. However, if the certificate is imported to the Passport for Work Key Storage Provider (KSP), it is guarded by the Passport PIN.
-
+ > **Note:** If MDM requested private key being stored in Trusted Process Module (TPM) (configured during enrollment request), the private key will be saved in TPM. Note that SCEP enrolled cert protected by TPM isn’t guarded by a PIN. However, if the certificate is imported to the Passport for Work Key Storage Provider (KSP), it is guarded by the Passport PIN.
-
## Related topics
-
[Configure S/MIME](configure-s-mime.md)
-
-
-
-
-
-
-
-
-
+
\ No newline at end of file
diff --git a/windows/keep-secure/interactive-logon-display-user-information-when-the-session-is-locked.md b/windows/keep-secure/interactive-logon-display-user-information-when-the-session-is-locked.md
index fc7f8995ad..094e59fedf 100644
--- a/windows/keep-secure/interactive-logon-display-user-information-when-the-session-is-locked.md
+++ b/windows/keep-secure/interactive-logon-display-user-information-when-the-session-is-locked.md
@@ -2,56 +2,33 @@
title: Interactive logon Display user information when the session is locked (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Interactive logon Display user information when the session is locked security policy setting.
ms.assetid: 9146aa3d-9b2f-47ba-ac03-ff43efb10530
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Interactive logon: Display user information when the session is locked
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **Interactive logon: Display user information when the session is locked** security policy setting.
-
## Reference
-
-
When a session is locked in a Windows operating system (meaning the user at the computer pressed CTRL+ALT+DEL and the Secure Desktop is displayed), user information is displayed. By default, this information is in the form of **<user name> is logged on**. The displayed user name is the user’s full name as set on the Properties page for that user. These settings do not apply to the logon tiles, which are displayed on the desktop after using the **Switch User** feature. The information that is displayed can be changed to meet your security requirements using the following possible values.
-
### Possible values
-
- **User display name, domain and user names**
-
If this is a local logon, the user’s full name is displayed on the Secure Desktop. If it is a domain logon, the user’s domain and user’s account name is displayed.
-
- **User display name only**
-
The name of the user who locked the session is displayed on the Secure Desktop as the user’s full name.
-
- **Do not display user information**
-
No names are displayed on the Secure Desktop, but user’s full names will be displayed on the **Switch user** desktop.
-
- Blank.
-
Default setting. This translates to “Not defined,” but it will display the user’s full name in the same manner as the **User display name, domain and user names** option. When an option is set, you cannot reset this policy to blank, or not defined.
-
### Best practices
-
Your implementation of this policy depends on your security requirements for displayed logon information. If you have devices that store sensitive data, with monitors displayed in unsecured locations, or if you have computers with sensitive data that are remotely accessed, revealing logged on user’s full names or domain account names might contradict your overall security policy.
-
Depending on your security policy, you might also want to enable the [Interactive logon: Do not display last user name](interactive-logon-do-not-display-last-user-name.md) policy, which will prevent the Windows operating system from displaying the logon name and logon tile of the last user to logon.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
@@ -90,57 +67,26 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Sec
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Policy conflict considerations
-
None
-
### Group Policy
-
This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
When a computer displays the Secure Desktop in an unsecured area, certain user information can be readily available to anyone looking at the monitor, either physically or through a remote connection. The displayed user information could include the domain user account name or the full name of the user who locked the session or who had logged on last.
-
### Countermeasure
-
Enabling this policy setting allows the operating system to hide certain user information from being displayed on the Secure Desktop (after the device has been booted or when the session has been locked by using CTRL+ALT+DEL). However, user information is displayed if the **Switch user** feature is used so that the logon tiles are displayed for each logged on user.
-
You might also want to enable the [Interactive logon: Do not display last user name](interactive-logon-do-not-display-last-user-name.md) policy, which will prevent the Windows operating system from displaying the logon name and logon tile of the last user to logon.
-
### Potential impact
-
If you do not enable this policy, the effect will be the same as enabling the policy and selecting the **User display name, domain and user names** option.
-
If the policy is enabled and set to **Do not display user information**, an observer cannot see who is logged onto the Secure Desktop, but the logon tile is still present if the [Interactive logon: Do not display last user name](interactive-logon-do-not-display-last-user-name.md) policy is not enabled. Depending on how the logon tiles are configured, they could provide visual clues as to who is logged on. In addition, if the Interactive logon: Do not display last user name policy is not enabled, then the **Switch user** feature will show user information.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/interactive-logon-do-not-display-last-user-name.md b/windows/keep-secure/interactive-logon-do-not-display-last-user-name.md
index c8547849bb..65a5067ae3 100644
--- a/windows/keep-secure/interactive-logon-do-not-display-last-user-name.md
+++ b/windows/keep-secure/interactive-logon-do-not-display-last-user-name.md
@@ -2,50 +2,30 @@
title: Interactive logon Do not display last user name (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Interactive logon Do not display last user name security policy setting.
ms.assetid: 98b24b03-95fe-4edc-8e97-cbdaa8e314fd
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Interactive logon: Do not display last user name
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **Interactive logon: Do not display last user name** security policy setting.
-
## Reference
-
-
This security policy setting determines whether the name of the last user to log on to the device is displayed on the Secure Desktop.
-
If this policy is enabled, the full name of the last user to successfully log on is not displayed on the Secure Desktop, nor is the user’s logon tile displayed. Additionally, if the **Switch user** feature is used, the full name and logon tile are not displayed. The logon screen requests a qualified domain account name (or local user name) and password.
-
If this policy is disabled, the full name of the last user to log on is displayed, and the user’s logon tile is displayed. This behavior is the same when the **Switch user** feature is used.
-
### Possible values
-
- Enabled
-
- Disabled
-
- Not defined
-
### Best practices
-
Your implementation of this policy depends on your security requirements for displayed logon information. If you have devices that store sensitive data, with monitors displayed in unsecured locations, or if you have devices with sensitive data that are remotely accessed, revealing logged on user’s full names or domain account names might contradict your overall security policy.
-
Depending on your security policy, you might also want to enable the [Interactive logon: Display user information when the session is locked](interactive-logon-display-user-information-when-the-session-is-locked.md) policy, which will prevent the Windows operating system from displaying the logon name when the session is locked or started.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
@@ -84,53 +64,24 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Sec
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Policy conflict considerations
-
None.
-
### Group Policy
-
This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
An attacker with access to the console (for example, someone with physical access or someone who can connect to the device through Remote Desktop Session Host) could view the name of the last user who logged on. The attacker could then try to guess the password, use a dictionary, or use a brute-force attack to try to log on.
-
### Countermeasure
-
Enable the **Interactive logon: Do not display last user name** setting.
-
### Potential impact
-
Users must always type their user names and passwords when they log on locally or to the domain. The logon tiles of all logged on users are not displayed.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/interactive-logon-do-not-require-ctrl-alt-del.md b/windows/keep-secure/interactive-logon-do-not-require-ctrl-alt-del.md
index daac336396..19bd4de7a1 100644
--- a/windows/keep-secure/interactive-logon-do-not-require-ctrl-alt-del.md
+++ b/windows/keep-secure/interactive-logon-do-not-require-ctrl-alt-del.md
@@ -2,54 +2,32 @@
title: Interactive logon Do not require CTRL+ALT+DEL (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Interactive logon Do not require CTRL+ALT+DEL security policy setting.
ms.assetid: 04e2c000-2eb2-4d4b-8179-1e2cb4793e18
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Interactive logon: Do not require CTRL+ALT+DEL
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **Interactive logon: Do not require CTRL+ALT+DEL** security policy setting.
-
## Reference
-
-
This security setting determines whether pressing CTRL+ALT+DEL is required before a user can log on.
-
If this policy setting is enabled on a device, a user is not required to press CTRL+ALT+DEL to log on. Not having to press CTRL+ALT+DEL leaves users susceptible to attacks that attempt to intercept the users' passwords. Requiring CTRL+ALT+DEL before users log on ensures that users are communicating by means of a trusted path when entering their passwords.
-
If this policy is disabled, any user is required to press CTRL+ALT+DEL before logging on to the Windows operating system (unless they are using a smart card for logon).
-
Microsoft developed this feature to make it easier for users with certain types of physical impairments to log on to device running the Windows operating system; however, not having to press the CTRL+ALT+DELETE key combination leaves users susceptible to attacks that attempt to intercept their passwords. Requiring CTRL+ALT+DELETE before users log on ensures that users are communicating by means of a trusted path when entering their passwords.
-
A malicious user might install malware that looks like the standard logon dialog box for the Windows operating system, and capture a user's password. The attacker can then log on to the compromised account with whatever level of user rights that user has.
-
### Possible values
-
- Enabled
-
- Disabled
-
- Not defined
-
### Best practices
-
- It is advisable to set **Disable CTRL+ALT+DEL requirement for logon** to **Disabled**. Unless they are using a smart card to log on, users will have to simultaneously press three keys before the logon dialog box appears.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -88,55 +66,25 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Policy conflict considerations
-
Beginning with Windows Server 2008 and Windows Vista, the CTRL+ALT+DELETE key combination is required to authenticate if this policy is disabled.
-
### Group Policy
-
This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
This setting makes it easier for users with certain types of physical impairments to log on to devices that run the Windows operating system. However, if users are not required to press CTRL+ALT+DEL, they are susceptible to attacks that attempt to intercept their passwords. If CTRL+ALT+DEL is required before logon, user passwords are communicated by means of a trusted path.
-
If this setting is enabled, an attacker could install malware that looks like the standard logon dialog box in the Windows operating system, and capture the user's password. The attacker would then be able to log on to the compromised account with whatever level of privilege that user has.
-
### Countermeasure
-
Disable the **Interactive logon: Do not require CTRL+ALT+DEL** setting.
-
### Potential impact
-
Unless they use a smart card to log on, users must simultaneously press the three keys before the logon dialog box is displayed.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/interactive-logon-machine-account-lockout-threshold.md b/windows/keep-secure/interactive-logon-machine-account-lockout-threshold.md
index 871200c86d..baa13fc5c0 100644
--- a/windows/keep-secure/interactive-logon-machine-account-lockout-threshold.md
+++ b/windows/keep-secure/interactive-logon-machine-account-lockout-threshold.md
@@ -2,46 +2,28 @@
title: Interactive logon Machine account lockout threshold (Windows 10)
description: Describes the best practices, location, values, management, and security considerations for the Interactive logon Machine account lockout threshold security policy setting.
ms.assetid: ebbd8e22-2611-4ebe-9db9-d49344e631e4
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Interactive logon: Machine account lockout threshold
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, management, and security considerations for the **Interactive logon: Machine account lockout threshold** security policy setting.
-
## Reference
-
-
Beginning with Windows Server 2012 and Windows 8, the **Interactive logon: Machine account threshold** security policy setting enforces the lockout policy on those computers that have BitLocker enabled to protect operating system volumes.
-
The security setting allows you to set a threshold for the number of failed logon attempts that causes the device to be locked by using BitLocker. This means, if the specified maximum number of failed logon attempts is exceeded, the device will invalidate the Trusted Platform Module (TPM) protector and any other protector except the 48-digit recovery password, and then reboot. During Device Lockout mode, the computer or device only boots into the touch-enabled Windows Recovery Environment (WinRE) until an authorized user enters the recovery password to restore full access.
-
Failed password attempts on workstations or member servers that have been locked by using either Ctrl+Alt+Delete or password-protected screen savers count as failed logon attempts.
-
### Possible values
-
You can set the **invalid logon attempts** value between 1 and 999. Values from 1 to 3 are interpreted as 4. If you set the value to 0, or leave blank, the computer or device will never be locked as a result of this policy setting.
-
### Best practices
-
Use this policy setting in conjunction with your other failed account logon attempts policy. For example, if the [Account lockout threshold](account-lockout-threshold.md) policy setting is set at 4, then setting **Interactive logon: Machine account lockout threshold** at 6 allows the user to restore access to resources without having to restore access to the device resulting from a BitLocker lock out.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -80,53 +62,24 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
A restart is required for changes to this policy to become effective when they are saved locally or distributed through Group Policy.
-
### Group Policy
-
Because this policy setting was introduced in Windows Server 2012 and Windows 8, it can only be set locally on those devices that contain this policy setting, but it can be set and distributed through Group Policy to any computer running the Windows operating system that supports Group Policy and is BitLocker-enabled.
-
When setting this policy, consider the [Account lockout threshold](account-lockout-threshold.md) policy setting, which determines the number of failed logon attempts that will cause a user account to be locked out.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
This policy setting helps protect a BitLocker-encrypted device from attackers attempting to brute-force guess the Windows sign-in password. If not set, then attackers can attempt innumerable passwords, if no other account protection mechanisms are in place.
-
### Countermeasure
-
Use this policy setting in conjunction with your other failed account logon attempts policy. For example, if the [Account lockout threshold](account-lockout-threshold.md) policy setting is set at 4, then setting **Interactive logon: Machine account lockout threshold** at 6 allows the user to restore access to resources without having to restore access to the device resulting from a BitLocker lock out.
-
### Potential impact
-
If not set, the device could be compromised by an attacker using brute-force password cracking software.
-
If set too low, productivity might be hindered because users who become locked out will be unable to access the device without providing the 48-digit BitLocker recovery password.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/interactive-logon-machine-inactivity-limit.md b/windows/keep-secure/interactive-logon-machine-inactivity-limit.md
index ac48acba83..969511b2b4 100644
--- a/windows/keep-secure/interactive-logon-machine-inactivity-limit.md
+++ b/windows/keep-secure/interactive-logon-machine-inactivity-limit.md
@@ -2,44 +2,27 @@
title: Interactive logon Machine inactivity limit (Windows 10)
description: Describes the best practices, location, values, management, and security considerations for the Interactive logon Machine inactivity limit security policy setting.
ms.assetid: 7065b4a9-0d52-41d5-afc4-5aedfc4162b5
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Interactive logon: Machine inactivity limit
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, management, and security considerations for the **Interactive logon: Machine inactivity limit** security policy setting.
-
## Reference
-
-
Beginning with Windows Server 2012 and Windows 8, Windows detects user-input inactivity of a sign-in (logon) session by using the security policy setting **Interactive logon: Machine inactivity limit**. If the amount of inactive time exceeds the inactivity limit set by this policy, then the user’s session locks by invoking the screen saver. This policy setting allows you to control the locking time by using Group Policy.
-
### Possible values
-
The automatic lock of the device is set in elapsed seconds of inactivity, which can range from zero (0) to 599,940 seconds (166.65 hours).
-
If no value (blank) or zero (0) is present in the **Machine will be locked after** input field, then the policy setting is disabled and no action is taken on user-input inactivity for the session.
-
### Best practices
-
Set the time for elapsed user-input inactivity based on the device’s usage and location requirements. For example, if the device or device is in a public area, you might want to have the device automatically lock after a short period of inactivity to prevent unauthorized access. However, if the device is used by an individual or group of trusted individuals, such as in a restricted manufacturing area, automatically locking the device might hinder productivity.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -78,49 +61,22 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
Restart is required for changes to this policy to become effective when they are saved locally or distributed through Group Policy.
-
### Group Policy
-
Because this policy setting was introduced in Windows Server 2012 and Windows 8, it can only be set locally on those computers that contain this policy setting, but it can be set and distributed through Group Policy to any computer running the Windows operating system that supports Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
This policy setting helps you prevent unauthorized access to devices under your control when the currently signed-in user leaves without deliberately locking the desktop. In versions earlier than Windows Server 2012 and Windows 8, the desktop-locking mechanism was set on individual computers in Personalization in Control Panel.
-
### Countermeasure
-
Set the time for elapsed user-input inactivity time by using the security policy setting **Interactive logon: Machine inactivity limit** based on the device’s usage and location requirements.
-
### Potential impact
-
This security policy setting can limit unauthorized access to unsecured computers; however, that requirement must be balanced with the productivity requirements of the intended user.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/interactive-logon-message-text-for-users-attempting-to-log-on.md b/windows/keep-secure/interactive-logon-message-text-for-users-attempting-to-log-on.md
index c3ae488699..b8962d626a 100644
--- a/windows/keep-secure/interactive-logon-message-text-for-users-attempting-to-log-on.md
+++ b/windows/keep-secure/interactive-logon-message-text-for-users-attempting-to-log-on.md
@@ -2,59 +2,35 @@
title: Interactive logon Message text for users attempting to log on (Windows 10)
description: Describes the best practices, location, values, management, and security considerations for the Interactive logon Message text for users attempting to log on security policy setting.
ms.assetid: fcfe8a6d-ca65-4403-b9e6-2fa017a31c2e
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Interactive logon: Message text for users attempting to log on
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, management, and security considerations for the **Interactive logon: Message text for users attempting to log on** security policy setting.
-
## Reference
-
-
The **Interactive logon: Message text for users attempting to log on** and [Interactive logon: Message title for users attempting to log on](interactive-logon-message-title-for-users-attempting-to-log-on.md) policy settings are closely related. **Interactive logon: Message text for users attempting to log on** specifies a text message to be displayed to users when they log on. Interactive logon: Message title for users attempting to log on specifies a title to appear in the title bar of the window that contains the text message. This text is often used for legal reasons—for example, to warn users about the ramifications of misusing company information, or to warn them that their actions might be audited.
-
Not using this warning-message policy setting leaves your organization legally vulnerable to trespassers who unlawfully penetrate your network. Legal precedents have established that organizations that display warnings to users who connect to their servers over a network have a higher rate of successfully prosecuting trespassers.
-
When these policy settings are configured, users will see a dialog box before they can log on to the server console.
-
### Possible values
-
The possible values for this setting are:
-
- User-defined text
-
- Not defined
-
### Best practices
-
- It is advisable to set **Interactive logon: Message text for users attempting to log on** to a value similar to one of the following:
-
1. IT IS AN OFFENSE TO CONTINUE WITHOUT PROPER AUTHORIZATION.
-
2. This system is restricted to authorized users. Individuals who attempt unauthorized access will be prosecuted. If you are unauthorized, terminate access now. Click OK to indicate your acceptance of this information.
-
**Important**
Any warning that you display in the title or text should be approved by representatives from your organization's legal and human resources departments.
-
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -93,58 +69,27 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes different requirements to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
There are two policy settings that relate to logon displays:
-
- **Interactive logon: Message text for users attempting to log on**
-
- [Interactive logon: Message title for users attempting to log on](interactive-logon-message-title-for-users-attempting-to-log-on.md)
-
The first policy setting specifies a text message that displays to users when they log on, and the second policy setting specifies a title for the title bar of the text message window. Many organizations use this text for legal purposes; for example, to warn users about the ramifications of misuse of company information, or to warn them that their actions may be audited.
-
### Vulnerability
-
Users often do not understand the importance of security practices. However, the display of a warning message before logon may help prevent an attack by warning malicious or uninformed users about the consequences of their misconduct before it happens. It may also help reinforce corporate policies by notifying employees of appropriate policies during the logon process.
-
### Countermeasure
-
Configure the **Interactive logon: Message text for users attempting to log on** and [Interactive logon: Message title for users attempting to log on](interactive-logon-message-title-for-users-attempting-to-log-on.md) settings to an appropriate value for your organization.
-
**Note**
Any warning message that displays should be approved by your organization's legal and human resources representatives.
-
-
### Potential impact
-
Users see a message in a dialog box before they can log on to the server console.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/interactive-logon-message-title-for-users-attempting-to-log-on.md b/windows/keep-secure/interactive-logon-message-title-for-users-attempting-to-log-on.md
index 7c09c135ab..dcc618ac81 100644
--- a/windows/keep-secure/interactive-logon-message-title-for-users-attempting-to-log-on.md
+++ b/windows/keep-secure/interactive-logon-message-title-for-users-attempting-to-log-on.md
@@ -2,58 +2,34 @@
title: Interactive logon Message title for users attempting to log on (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Interactive logon Message title for users attempting to log on security policy setting.
ms.assetid: f2596470-4cc0-4ef1-849c-bef9dc3533c6
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Interactive logon: Message title for users attempting to log on
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **Interactive logon: Message title for users attempting to log on** security policy setting.
-
## Reference
-
-
This security setting allows you to specify a title that appears in the title bar of the window that contains the **Interactive logon: Message title for users attempting to log on**. This text is often used for legal reasons—for example, to warn users about the ramifications of misusing company information, or to warn them that their actions might be audited.
-
The **Interactive logon: Message title for users attempting to log on** and [Interactive logon: Message text for users attempting to log on](interactive-logon-message-text-for-users-attempting-to-log-on.md) policy settings are closely related. **Interactive logon: Message title for users attempting to log on** specifies a message title to be displayed to users when they log on.
-
Not using this warning-message policy setting leaves your organization legally vulnerable to trespassers who unlawfully penetrate your network. Legal precedents have established that organizations that display warnings to users who connect to their servers over a network have a higher rate of successfully prosecuting trespassers.
-
When these policy settings are configured, users will see a dialog box before they can log on to the server console.
-
### Possible values
-
- *User-defined title*
-
- Not defined
-
### Best practices
-
1. It is advisable to set **Interactive logon: Message title for users attempting to log on** to a value similar to one the following:
-
- RESTRICTED SYSTEM
-
or
-
- WARNING: This system is restricted to authorized users.
-
2. Set the policy [Interactive logon: Message text for users attempting to log on](interactive-logon-message-text-for-users-attempting-to-log-on.md) to reinforce the meaning of the message’s title.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -92,58 +68,27 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
There are two policy settings that relate to logon displays:
-
- [Interactive logon: Message text for users attempting to log on](interactive-logon-message-text-for-users-attempting-to-log-on.md)
-
- **Interactive logon: Message title for users attempting to log on**
-
The first policy setting specifies a text message that displays to users when they log on, and the second policy setting specifies a title for the title bar of the text message window. Many organizations use this text for legal purposes; for example, to warn users about the ramifications of misuse of company information, or to warn them that their actions may be audited.
-
### Vulnerability
-
Users often do not understand the importance of security practices. However, the display of a warning message with an appropriate title before logon may help prevent an attack by warning malicious or uninformed users about the consequences of their misconduct before it happens. It may also help reinforce corporate policies by notifying employees of appropriate policies during the logon process.
-
### Countermeasure
-
Configure the [Interactive logon: Message text for users attempting to log on](interactive-logon-message-text-for-users-attempting-to-log-on.md) and **Interactive logon: Message title for users attempting to log on** settings to an appropriate value for your organization.
-
**Note**
Any warning message that displays should be approved by your organization's legal and human resources representatives.
-
-
### Potential impact
-
Users see a message in a dialog box before they can log on to the server console.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md b/windows/keep-secure/interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md
index 2fa2d1f18d..14605564d2 100644
--- a/windows/keep-secure/interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md
+++ b/windows/keep-secure/interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md
@@ -2,56 +2,33 @@
title: Interactive logon Number of previous logons to cache (in case domain controller is not available) (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Interactive logon Number of previous logons to cache (in case domain controller is not available) security policy setting.
ms.assetid: 660e925e-cc3e-4098-a41e-eb8db8062d8d
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Interactive logon: Number of previous logons to cache (in case domain controller is not available)
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **Interactive logon: Number of previous logons to cache (in case domain controller is not available)** security policy setting.
-
## Reference
-
-
The **Interactive logon: Number of previous logons to cache (in case domain controller is not available**) policy setting determines whether a user can log on to a Windows domain by using cached account information. Logon information for domain accounts can be cached locally so that, if a domain controller cannot be contacted on subsequent logons, a user can still log on. This policy setting determines the number of unique users whose logon information is cached locally.
-
If a domain controller is unavailable and a user's logon information is cached, the user is prompted with the following message:
-
A domain controller for your domain could not be contacted. You have been logged on using cached account information. Changes to your profile since you last logged on might not be available.
-
If a domain controller is unavailable and a user's logon information is not cached, the user is prompted with this message:
-
The system cannot log you on now because the domain *DOMAIN NAME* is not available.
-
The value of this policy setting indicates the number of users whose logon information the server caches locally. If the value is 10, the server caches logon information for 10 users. When an eleventh user logs on to the device, the server overwrites the oldest cached logon session.
-
Users who access the server console will have their logon credentials cached on that server. A malicious user who is able to access the file system of the server can locate this cached information and use a brute-force attack to determine user passwords. Windows mitigates this type of attack by encrypting the information and keeping the cached credentials in the system's registries, which are spread across numerous physical locations.
-
### Possible values
-
- A user-defined number from 0 through 50
-
- Not defined
-
### Best practices
-
It is advisable to set **Interactive logon: Number of previous logons to cache (in case domain controller is not available)** to 0. Setting this value to 0 disables the local caching of logon information. Additional countermeasures include enforcing strong password policies and physically securing the computers. If the value is set to 0, users will be unable to log on to any computers if there is no domain controller available to authenticate them. Organizations might want to set **Interactive logon: Number of previous logons to cache (in case domain controller is not available)** to 2 for end-user systems, especially for mobile users. Setting this value to 2 means that the user's logon information will still be in the cache even if a member of the IT department has recently logged on to their device to perform system maintenance. This way, those users will be able to log on to their devices when they are not connected to the corporate network.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -90,57 +67,26 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a computer restart when they are saved locally or distributed through Group Policy.
-
### Policy conflict considerations
-
None
-
### Group Policy
-
This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
The number that is assigned to this policy setting indicates the number of users whose logon information is cache locally by the servers. If the number is set to 10, the server caches logon information for 10 users. When an eleventh user logs on to the device, the server overwrites the oldest cached logon session.
-
Users who access the server console have their logon credentials cached on that server. An attacker who is able to access the file system of the server could locate this cached information and use a brute force attack to attempt to determine user passwords.
-
To mitigate this type of attack, Windows encrypts the information and obscures its physical location.
-
### Countermeasure
-
Configure the **Interactive logon: Number of previous logons to cache (in case domain controller is not available)** setting to 0, which disables the local caching of logon information. Additional countermeasures include enforcement of strong password policies and physically secure locations for the computers.
-
### Potential impact
-
Users cannot log on to any devices if there is no domain controller available to authenticate them. Organizations can configure this value to 2 for end-user computers, especially for mobile users. A configuration value of 2 means that the user's logon information is still in the cache, even if a member of the IT department has recently logged on to the device to perform system maintenance. This method allows users to log on to their computers when they are not connected to the organization's network.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/interactive-logon-prompt-user-to-change-password-before-expiration.md b/windows/keep-secure/interactive-logon-prompt-user-to-change-password-before-expiration.md
index 55d44d3f87..f499d1b051 100644
--- a/windows/keep-secure/interactive-logon-prompt-user-to-change-password-before-expiration.md
+++ b/windows/keep-secure/interactive-logon-prompt-user-to-change-password-before-expiration.md
@@ -2,48 +2,29 @@
title: Interactive logon Prompt user to change password before expiration (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Interactive logon Prompt user to change password before expiration security policy setting.
ms.assetid: 8fe94781-40f7-4fbe-8cfd-5e116e6833e9
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Interactive logon: Prompt user to change password before expiration
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **Interactive logon: Prompt user to change password before expiration** security policy setting.
-
## Reference
-
-
The **Interactive logon: Prompt user to change password before expiration** policy setting determines how many days in advance users are warned that their passwords are about to expire. With this advance warning, the user has time to construct a password that is sufficiently strong.
-
### Possible values
-
- A user-defined number of days from 0 through 999.
-
- Not defined.
-
### Best practices
-
1. Configure user passwords to expire periodically. Users will need warning that their passwords are going to expire, or they might inadvertently get locked out of the system. This could lead to confusion for users who access the network locally, or make it impossible for users who access the network through dial-up or virtual private network (VPN) connections to log on.
-
2. Set **Interactive logon: Prompt user to change password before expiration** to 5 days. When their password expiration date is 5 or fewer days away, users will see a dialog box each time they log on to the domain.
-
3. Do not set the value to 0, which results in displaying the password expiration warning every time the user logs on.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -82,53 +63,24 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Policy conflict considerations
-
None.
-
### Group Policy
-
This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
If user passwords are configured to expire periodically in your organization, users need to be warned when this is about to happen, or they may be locked out of the device inadvertently when their passwords expire. This condition could lead to confusion for users who access the network locally, or make it impossible for users to access your organization's network through dial-up or virtual private network (VPN) connections.
-
### Countermeasure
-
Configure the **Interactive logon: Prompt user to change password before expiration** setting to 14 days.
-
### Potential impact
-
Users see a dialog-box prompt to change their password each time that they log on to the domain when their password is configured to expire in 14 or fewer days.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/interactive-logon-require-domain-controller-authentication-to-unlock-workstation.md b/windows/keep-secure/interactive-logon-require-domain-controller-authentication-to-unlock-workstation.md
index d32bae622c..97aa85187c 100644
--- a/windows/keep-secure/interactive-logon-require-domain-controller-authentication-to-unlock-workstation.md
+++ b/windows/keep-secure/interactive-logon-require-domain-controller-authentication-to-unlock-workstation.md
@@ -2,52 +2,31 @@
title: Interactive logon Require Domain Controller authentication to unlock workstation (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Interactive logon Require Domain Controller authentication to unlock workstation security policy setting.
ms.assetid: 97618ed3-e946-47db-a212-b5e7a4fc6ffc
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Interactive logon: Require Domain Controller authentication to unlock workstation
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Interactive logon: Require Domain Controller authentication to unlock workstation** security policy setting.
-
## Reference
-
-
Unlocking a locked device requires logon information. For domain accounts, the **Interactive logon: Require Domain Controller authentication to unlock workstation** policy setting determines whether it is necessary to contact a domain controller to unlock a device. Enabling this policy setting requires a domain controller to authenticate the domain account that is being used to unlock the device. Disabling this policy setting allows a user to unlock the device without the computer verifying the logon information with a domain controller. However, if [Interactive logon: Number of previous logons to cache (in case domain controller is not available)](interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md) is set to a value greater than zero, the user's cached credentials will be used to unlock the system.
-
The device caches (locally in memory) the credentials of any users who have been authenticated. The device uses these cached credentials to authenticate anyone who attempts to unlock the console.
-
When cached credentials are used, any changes that have recently been made to the account (such as user rights assignments, account lockout, or the account being disabled) are not considered or applied after this authentication process. This means not only that user rights are not updated, but more importantly that disabled accounts are still able to unlock the console of the system.
-
It is advisable to set **Interactive logon: Require Domain Controller authentication to unlock workstation** to Enabled and set [Interactive logon: Number of previous logons to cache (in case domain controller is not available)](interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md) to 0. When the console of a device is locked by a user or automatically by a screen saver time-out, the console can only be unlocked if the user is able to re-authenticate to the domain controller. If no domain controller is available, users cannot unlock their devices.
-
### Possible values
-
- Enabled
-
- Disabled
-
- Not defined
-
### Best practices
-
- Set **Interactive logon: Require Domain Controller authentication to unlock workstation** to Enabled and set [Interactive logon: Number of previous logons to cache (in case domain controller is not available)](interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md) to 0. When the console of a device is locked by a user or automatically by a screen saver time-out, the console can only be unlocked if the user is able to re-authenticate to the domain controller. If no domain controller is available, users cannot unlock their devices.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -86,53 +65,24 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Policy conflict considerations
-
None
-
### Group Policy
-
This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
By default, the device caches locally in memory the credentials of any users who are authenticated. The device uses these cached credentials to authenticate anyone who attempts to unlock the console. When cached credentials are used, any changes that have recently been made to the account—such as user rights assignments, account lockout, or the account being disabled—are not considered or applied after the account is authenticated. User privileges are not updated, and disabled accounts are still able to unlock the console of the device
-
### Countermeasure
-
Configure the **Interactive logon: Require Domain Controller authentication to unlock workstation** setting to Enabled and configure the [Interactive logon: Number of previous logons to cache (in case domain controller is not available)](interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md) setting to 0.
-
### Potential impact
-
When the console on a device is locked by a user or automatically by a screen-saver timeout, the console can be unlocked only if the user can re-authenticate to the domain controller. If no domain controller is available, users cannot unlock their workstations. If you configure the [Interactive logon: Number of previous logons to cache (in case domain controller is not available)](interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md) setting to 0, users whose domain controllers are unavailable (such as mobile or remote users) cannot log on.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/interactive-logon-require-smart-card.md b/windows/keep-secure/interactive-logon-require-smart-card.md
index 275ffa00b6..417a99a5a3 100644
--- a/windows/keep-secure/interactive-logon-require-smart-card.md
+++ b/windows/keep-secure/interactive-logon-require-smart-card.md
@@ -2,48 +2,29 @@
title: Interactive logon Require smart card (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Interactive logon Require smart card security policy setting.
ms.assetid: c6a8c040-cbc7-472d-8bc5-579ddf3cbd6c
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Interactive logon: Require smart card
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **Interactive logon: Require smart card** security policy setting.
-
## Reference
-
-
The **Interactive logon: Require smart card** policy setting requires users to log on to a device by using a smart card.
-
Requiring users to use long, complex passwords for authentication enhances network security, especially if the users must change their passwords regularly. This reduces the chance that a malicious user will be able to guess a user's password through a brute-force attack. Using smart cards rather than passwords for authentication dramatically increases security because, with today's technology, it is nearly impossible for a malicious user to impersonate another user. Smart cards that require personal identification numbers (PINs) provide two-factor authentication: the user who attempts to log on must possess the smart card and know its PIN. A malicious user who captures the authentication traffic between the user's device and the domain controller will find it extremely difficult to decrypt the traffic: even if they do, the next time the user logs on to the network, a new session key will be generated for encrypting traffic between the user and the domain controller.
-
### Possible values
-
- Enabled
-
- Disabled
-
- Not defined
-
### Best practices
-
- Set **Interactive logon: Require smart card** to Enabled. All users will have to use smart cards to log on to the network. This means that the organization must have a reliable public key infrastructure (PKI) in place, and provide smart cards and smart card readers for all users.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -82,53 +63,24 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Policy conflict considerations
-
None.
-
### Group Policy
-
This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
It can be difficult to make users choose strong passwords, and even strong passwords are vulnerable to brute-force attacks if an attacker has sufficient time and computing resources.
-
### Countermeasure
-
For users with access to computers that contain sensitive data, issue smart cards to users and configure the **Interactive logon: Require smart card** setting to Enabled.
-
### Potential impact
-
All users of a device with this setting enabled must use smart cards to log on locally. This means that the organization must have a reliable public key infrastructure (PKI) as well as smart cards and smart card readers for these users. These requirements are significant challenges because expertise and resources are required to plan for and deploy these technologies. Active Directory Certificate Services (AD CS) can be used to implement and manage certificates. You can use automatic user and device enrollment and renewal on the client.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/interactive-logon-smart-card-removal-behavior.md b/windows/keep-secure/interactive-logon-smart-card-removal-behavior.md
index 59ca4aad03..e7daf35333 100644
--- a/windows/keep-secure/interactive-logon-smart-card-removal-behavior.md
+++ b/windows/keep-secure/interactive-logon-smart-card-removal-behavior.md
@@ -2,60 +2,35 @@
title: Interactive logon Smart card removal behavior (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Interactive logon Smart card removal behavior security policy setting.
ms.assetid: 61487820-9d49-4979-b15d-c7e735999460
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Interactive logon: Smart card removal behavior
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **Interactive logon: Smart card removal behavior** security policy setting.
-
## Reference
-
-
This policy setting determines what happens when the smart card for a logged-on user is removed from the smart card reader.
-
If smart cards are used for authentication, the device should automatically lock itself when the card is removed—that way, if users forget to manually lock their devices when they are away from them, malicious users cannot gain access.
-
If you select **Force Logoff** in the property sheet for this policy setting, the user is automatically logged off when the smart card is removed. Users will have to reinsert their smart cards and reenter their PINs when they return to their workstations.
-
### Possible values
-
- No Action
-
- Lock Workstation
-
If you select this, the workstation is locked when the smart card is removed, allowing users to leave the area, take their smart card with them, and still maintain a protected session.
-
- Force Logoff
-
If you select this, the user is automatically logged off when the smart card is removed.
-
- Disconnect if a remote Remote Desktop Services session
-
If you select this, removal of the smart card disconnects the session without logging the user off. This allows the user to insert the smart card and resume the session later, or at another smart card reader-equipped computer, without having to log on again. If the session is local, this policy functions identically to Lock Workstation.
-
- Not Defined
-
### Best practices
-
- Set **Interactive logon: Smart card removal behavior** to **Lock Workstation**. If you select **Lock Workstation** in the property sheet for this policy setting, the workstation is locked when the smart card is removed. This allows users to leave the area, take their smart card with them, and still maintain a protected session.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -94,57 +69,26 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Policy conflict considerations
-
None
-
### Group Policy
-
This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Users sometimes forget to lock their workstations when they are away from them, allowing the possibility for malicious users to access their devices. If smart cards are used for authentication, the device should automatically lock itself when the card is removed to ensure that only the user with the smart card is accessing resources by using those credentials.
-
### Countermeasure
-
Configure the **Interactive logon: Smart card removal behavior** setting to **Lock Workstation**.
-
If you select **Lock Workstation** for this policy setting, the device locks when the smart card is removed. Users can leave the area, take their smart card with them, and still maintain a protected session. This behavior is similar to the setting that requires users to log on when resuming work on the device after the screen saver has started.
-
If you select **Force Logoff** for this policy setting, the user is automatically logged off when the smart card is removed. This setting is useful when a device is deployed as a public access point, such as a kiosk or other type of shared device
-
### Potential impact
-
If you select **Force Logoff**, users must insert their smart cards and enter their PINs when they return to their workstations.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/kerberos-policy.md b/windows/keep-secure/kerberos-policy.md
index 7462552b9e..7fc388203f 100644
--- a/windows/keep-secure/kerberos-policy.md
+++ b/windows/keep-secure/kerberos-policy.md
@@ -2,30 +2,20 @@
title: Kerberos Policy (Windows 10)
description: Describes the Kerberos Policy settings and provides links to policy setting descriptions.
ms.assetid: 94017dd9-b1a3-4624-af9f-b29161b4bf38
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Kerberos Policy
-
-
**Applies to**
-
- Windows 10
-
Describes the Kerberos Policy settings and provides links to policy setting descriptions.
-
The Kerberos version 5 authentication protocol provides the default mechanism for authentication services and the authorization data necessary for a user to access a resource and perform a task on that resource. By reducing the lifetime of Kerberos tickets, you reduce the risk of a legitimate user's credentials being stolen and successfully used by an attacker. However, this also increases the authorization overhead. In most environments, these settings should not need to be changed.
-
These policy settings are located in **\\Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Kerberos Policy**.
-
The following topics provide a discussion of implementation and best practices considerations, policy location, default values for the server type or GPO, relevant differences in operating system versions, security considerations (including the possible settings vulnerabilities of each setting), countermeasures you can take, and the potential impact for each setting.
-
## In this section
-
-
@@ -60,19 +50,8 @@ The following topics provide a discussion of implementation and best practices c
-
-
## Related topics
-
-
[Configure security policy settings](how-to-configure-security-policy-settings.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/load-and-unload-device-drivers.md b/windows/keep-secure/load-and-unload-device-drivers.md
index b76083e989..fb07375002 100644
--- a/windows/keep-secure/load-and-unload-device-drivers.md
+++ b/windows/keep-secure/load-and-unload-device-drivers.md
@@ -2,54 +2,32 @@
title: Load and unload device drivers (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Load and unload device drivers security policy setting.
ms.assetid: 66262532-c610-470c-9792-35ff4389430f
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Load and unload device drivers
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Load and unload device drivers** security policy setting.
-
## Reference
-
-
This policy setting determines which users can dynamically load and unload device drivers. This user right is not required if a signed driver for the new hardware already exists in the driver.cab file on the device. Device drivers run as highly privileged code.
-
Windows supports the Plug and Play specifications that define how a computer can detect and configure newly added hardware, and then automatically install the device driver. Prior to Plug and Play, users needed to manually configure devices before attaching them to the device. This model allows a user to plug in the hardware, then Windows searches for an appropriate device driver package and automatically configures it to work without interfering with other devices.
-
Because device driver software runs as if it is a part of the operating system with unrestricted access to the entire computer, it is critical that only known and authorized device drivers be permitted.
-
Constant: SeLoadDriverPrivilege
-
### Possible values
-
- User-defined list of accounts
-
- Default values
-
- Not Defined
-
### Best practices
-
- Because of the potential security risk, do not assign this user right to any user, group, or process that you do not want to take over the system.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
By default this setting is Administrators and Print Operators on domain controllers and Administrators on stand-alone servers.
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -90,64 +68,30 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
A restart of the device is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
### Group Policy
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Device drivers run as highly privileged code. A user who has the **Load and unload device drivers** user right could unintentionally install malware that masquerades as a device driver. Administrators should exercise care and install only drivers with verified digital signatures.
-
**Note**
You must have this user right or be a member of the local Administrators group to install a new driver for a local printer or to manage a local printer and configure defaults for options such as duplex printing.
-
-
### Countermeasure
-
Do not assign the **Load and unload device drivers** user right to any user or group other than Administrators on member servers. On domain controllers, do not assign this user right to any user or group other than Domain Admins.
-
### Potential impact
-
If you remove the **Load and unload device drivers** user right from the Print Operators group or other accounts, you could limit the abilities of users who are assigned to specific administrative roles in your environment. You should ensure that delegated tasks are not negatively affected.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/lock-pages-in-memory.md b/windows/keep-secure/lock-pages-in-memory.md
index 6454978bd9..3bf58d8f5e 100644
--- a/windows/keep-secure/lock-pages-in-memory.md
+++ b/windows/keep-secure/lock-pages-in-memory.md
@@ -2,55 +2,33 @@
title: Lock pages in memory (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Lock pages in memory security policy setting.
ms.assetid: cc724979-aec0-496d-be4e-7009aef660a3
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Lock pages in memory
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Lock pages in memory** security policy setting.
-
## Reference
-
-
This policy setting determines which accounts can use a process to keep data in physical memory, which prevents the computer from paging the data to virtual memory on a disk.
-
Normally, an application running on Windows can negotiate for more physical memory, and in response to the request, the application begins to move the data from RAM (such as the data cache) to a disk. When the pageable memory is moved to a disk, more RAM is free for the operating system to use.
-
Enabling this policy setting for a specific account (a user account or a process account for an application) prevents paging of the data. Thereby, the amount of memory that Windows can reclaim under pressure is limited. This could lead to performance degradation.
-
**Note**
By configuring this policy setting, the performance of the Windows operating system will differ depending on if applications are running on 32-bit or 64-bit systems, and if they are virtualized images. Performance will also differ between earlier and later versions of the Windows operating system.
-
-
Constant: SeLockMemoryPrivilege
-
### Possible values
-
- User-defined list of accounts
-
- Not defined
-
### Best practices
-
Best practices are dependent on the platform architecture and the applications running on those platforms.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
-
@@ -89,59 +67,27 @@ The following table lists the actual and effective default policy values for the
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
A restart of the computer is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
### Group Policy
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Users with the **Lock pages in memory** user right could assign physical memory to several processes, which could leave little or no RAM for other processes and result in a denial-of-service condition.
-
### Countermeasure
-
Do not assign the **Lock pages in memory** user right to any accounts.
-
### Potential impact
-
None. Not defined is the default configuration.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/log-on-as-a-batch-job.md b/windows/keep-secure/log-on-as-a-batch-job.md
index d2a27b6c9c..1d61c2f659 100644
--- a/windows/keep-secure/log-on-as-a-batch-job.md
+++ b/windows/keep-secure/log-on-as-a-batch-job.md
@@ -2,50 +2,30 @@
title: Log on as a batch job (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Log on as a batch job security policy setting.
ms.assetid: 4eaddb51-0a18-470e-9d3d-5e7cd7970b41
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Log on as a batch job
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Log on as a batch job** security policy setting.
-
## Reference
-
-
This policy setting determines which accounts can log on by using a batch-queue tool such as the Task Scheduler service. When you use the Add Scheduled Task Wizard to schedule a task to run under a particular user name and password, that user is automatically assigned the **Log on as a batch job** user right. When the scheduled time arrives, the Task Scheduler service logs on the user as a batch job instead of as an interactive user, and the task runs in the user's security context.
-
Constant: SeBatchLogonRight
-
### Possible values
-
- User-defined list of accounts
-
- Default values
-
- Not Defined
-
### Best practices
-
- Use discretion when assigning this right to specific users for security reasons. The default settings are sufficient in most cases.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
By default, this setting is for Administrators, Backup Operators, and Performance Log Users on domain controllers and on stand-alone servers.
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -92,61 +72,28 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
A restart of the computer is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
### Group Policy
-
Task Scheduler automatically grants this right when a user schedules a task. To override this behavior use the [Deny log on as a batch job](deny-log-on-as-a-batch-job.md) User Rights Assignment setting.
-
Group Policy settings are applied in the following order, which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
The **Log on as a batch job** user right presents a low-risk vulnerability. For most organizations, the default settings are sufficient. Members of the local Administrators group have this right by default.
-
### Countermeasure
-
You should allow the computer to manage this user right automatically if you want to allow scheduled tasks to run for specific user accounts. If you do not want to use the Task Scheduler in this manner, configure the **Log on as a batch job** user right for only the Local Service account.
-
For IIS servers, you should configure this policy locally instead of through domain–based Group Policy settings so that you can ensure the local IUSR\_*<ComputerName>* and IWAM\_*<ComputerName>* accounts have this user right.
-
### Potential impact
-
If you configure the **Log on as a batch job** setting by using domain-based Group Policy settings, the computer cannot assign the user right to accounts that are used for scheduled jobs in the Task Scheduler. If you install optional components such as ASP.NET or IIS, you may need to assign this user right to additional accounts that are required by those components. For example, IIS requires assignment of this user right to the IIS\_WPG group and the IUSR\_*<ComputerName>*, ASPNET, and IWAM\_*<ComputerName>* accounts. If this user right is not assigned to this group and these accounts, IIS cannot run some COM objects that are necessary for proper functionality.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/log-on-as-a-service.md b/windows/keep-secure/log-on-as-a-service.md
index ad2eda2c3f..ac574fb9c8 100644
--- a/windows/keep-secure/log-on-as-a-service.md
+++ b/windows/keep-secure/log-on-as-a-service.md
@@ -2,48 +2,29 @@
title: Log on as a service (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Log on as a service security policy setting.
ms.assetid: acc9a9e0-fd88-4cda-ab54-503120ba1f42
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Log on as a service
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Log on as a service** security policy setting.
-
## Reference
-
-
This policy setting determines which service accounts can register a process as a service. Running a process under a service account circumvents the need for human intervention.
-
Constant: SeServiceLogonRight
-
### Possible values
-
- User-defined list of accounts
-
- Not Defined
-
### Best practices
-
- Minimize the number of accounts that are granted this user right.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
By default this setting is Network Service on domain controllers and Network Service on stand-alone servers.
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -82,59 +63,27 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
A restart of the computer is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
### Group Policy
-
The policy setting **Deny logon as a service** supersedes this policy setting if a user account is subject to both policies.
-
Group Policy settings are applied in the following order, which will overwrite settings on the local device at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
The **Log on as a service** user right allows accounts to start network services or services that run continuously on a computer, even when no one is logged on to the console. The risk is reduced by the fact that only users with administrative privileges can install and configure services. An attacker who has already attained that level of access could configure the service to run with the Local System account.
-
### Countermeasure
-
By definition, the Network Service account has the **Log on as a service** user right. This right is not granted through the Group Policy setting. You should minimize the number of other accounts that are granted this user right.
-
### Potential impact
-
On most computers, restricting the **Log on as a service** user right to the Local System, Local Service, and Network Service built-in accounts is the default configuration, and there is no negative impact. However, if you have installed optional components such as ASP.NET or IIS, you may need to assign the **Log on as a service** user right to additional accounts that are required by those components. IIS requires that this user right be explicitly granted to the ASPNET user account.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/maintain-applocker-policies.md b/windows/keep-secure/maintain-applocker-policies.md
index edc7834283..d028b6c454 100644
--- a/windows/keep-secure/maintain-applocker-policies.md
+++ b/windows/keep-secure/maintain-applocker-policies.md
@@ -2,126 +2,64 @@
title: Maintain AppLocker policies (Windows 10)
description: This topic describes how to maintain rules within AppLocker policies.
ms.assetid: b4fbfdfe-ef3d-49e0-a390-f2dfe74602bc
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Maintain AppLocker policies
-
-
**Applies to**
-
- Windows 10
-
This topic describes how to maintain rules within AppLocker policies.
-
Common AppLocker maintenance scenarios include:
-
- A new app is deployed, and you need to update an AppLocker policy.
-
- A new version of an app is deployed, and you need to either update an AppLocker policy or create a new rule to update the policy.
-
- An app is no longer supported by your organization, so you need to prevent it from being used.
-
- An app appears to be blocked but should be allowed.
-
- An app appears to be allowed but should be blocked.
-
- A single user or small subset of users needs to use a specific app that is blocked.
-
There are two methods you can use to maintain AppLocker policies:
-
- [Maintaining AppLocker policies by using Group Policy](#bkmk-applkr-use-gp)
-
- [Maintaining AppLocker policies on the local computer](#bkmk-applkr-use-locsnapin)
-
As new apps are deployed or existing apps are removed by your organization or updated by the software publisher, you might need to make revisions to your rules and update the Group Policy Object (GPO) to ensure that your policy is current.
-
You can edit an AppLocker policy by adding, changing, or removing rules. However, you cannot specify a version for the AppLocker policy by importing additional rules. To ensure version control when modifying an AppLocker policy, use Group Policy management software that allows you to create versions of GPOs.
-
**Caution**
You should not edit an AppLocker rule collection while it is being enforced in Group Policy. Because AppLocker controls what files are allowed to run, making changes to a live policy can create unexpected behavior.
-
-
## Maintaining AppLocker policies by using Group Policy
-
-
For every scenario, the steps to maintain an AppLocker policy distributed by Group Policy include the following tasks.
-
### Step 1: Understand the current behavior of the policy
-
Before modifying a policy, evaluate how the policy is currently implemented. For example, if a new version of the application is deployed, you can use **Test-AppLockerPolicy** to verify the effectiveness of your current policy for that app.
-
### Step 2: Export the AppLocker policy from the GPO
-
Updating an AppLocker policy that is currently enforced in your production environment can have unintended results. Therefore, export the policy from the GPO and update the rule or rules by using AppLocker on your AppLocker reference or test computer. To prepare an AppLocker policy for modification, see [Export an AppLocker policy from a GPO](export-an-applocker-policy-from-a-gpo.md)
-
### Step 3: Update the AppLocker policy by editing the appropriate AppLocker rule
-
After the AppLocker policy has been exported from the GPO into the AppLocker reference or test computer, or has been accessed on the local computer, the specific rules can be modified as required.
-
To modify AppLocker rules, see the following:
-
- [Edit AppLocker rules](edit-applocker-rules.md)
-
- [Merge AppLocker policies by using Set-ApplockerPolicy](merge-applocker-policies-by-using-set-applockerpolicy.md) or [Merge AppLocker policies manually](merge-applocker-policies-manually.md)
-
- [Delete an AppLocker rule](delete-an-applocker-rule.md)
-
- [Enforce AppLocker rules](enforce-applocker-rules.md)
-
### Step 4: Test the AppLocker policy
-
You should test each collection of rules to ensure that the rules perform as intended. (Because AppLocker rules are inherited from linked GPOs, you should deploy all rules for simultaneous testing in all test GPOs.) For steps to perform this testing, see [Test and update an AppLocker policy](test-and-update-an-applocker-policy.md).
-
### Step 5: Import the AppLocker policy into the GPO
-
After testing, import the AppLocker policy back into the GPO for implementation. To update the GPO with a modified AppLocker policy, see [Import an AppLocker policy into a GPO](import-an-applocker-policy-into-a-gpo.md).
-
### Step 6: Monitor the resulting policy behavior
-
After deploying a policy, evaluate the policy's effectiveness.
-
## Maintaining AppLocker policies by using the Local Security Policy snap-in
-
-
For every scenario, the steps to maintain an AppLocker policy by using the Local Group Policy Editor or the Local Security Policy snap-in include the following tasks.
-
### Step 1: Understand the current behavior of the policy
-
Before modifying a policy, evaluate how the policy is currently implemented.
-
### Step 2: Update the AppLocker policy by modifying the appropriate AppLocker rule
-
Rules are grouped into a collection, which can have the policy enforcement setting applied to it. By default, AppLocker rules do not allow users to open or run any files that are not specifically allowed.
-
To modify AppLocker rules, see the appropriate topic listed on [Administer AppLocker](administer-applocker.md).
-
### Step 3: Test the AppLocker policy
-
You should test each collection of rules to ensure that the rules perform as intended. For steps to perform this testing, see [Test and update an AppLocker policy](test-and-update-an-applocker-policy.md).
-
### Step 4: Deploy the policy with the modified rule
-
You can export and then import AppLocker policies to deploy the policy to other computers running Windows 8 or later. To perform this task, see [Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md) and [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md).
-
### Step 5: Monitor the resulting policy behavior
-
After deploying a policy, evaluate the policy's effectiveness.
-
## Additional resources
-
-
- For steps to perform other AppLocker policy tasks, see [Administer AppLocker](administer-applocker.md).
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/manage-auditing-and-security-log.md b/windows/keep-secure/manage-auditing-and-security-log.md
index 8eb5c90fc8..f6bfc0e575 100644
--- a/windows/keep-secure/manage-auditing-and-security-log.md
+++ b/windows/keep-secure/manage-auditing-and-security-log.md
@@ -2,52 +2,31 @@
title: Manage auditing and security log (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Manage auditing and security log security policy setting.
ms.assetid: 4b946c0d-f904-43db-b2d5-7f0917575347
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Manage auditing and security log
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Manage auditing and security log** security policy setting.
-
## Reference
-
-
This policy setting determines which users can specify object access audit options for individual resources such as files, Active Directory objects, and registry keys. These objects specify their system access control lists (SACL). A user who is assigned this user right can also view and clear the Security log in Event Viewer. For more info about the Object Access audit policy, see [Audit object access](basic-audit-object-access.md).
-
Constant: SeSecurityPrivilege
-
### Possible values
-
- User-defined list of accounts
-
- Administrators
-
- Not Defined
-
### Best practices
-
1. Before removing this right from a group, investigate whether applications are dependent on this right.
-
2. Generally, assigning this user right to groups other than Administrators is not necessary.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
By default this setting is Administrators on domain controllers and on stand-alone servers.
-
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
-
@@ -86,68 +65,32 @@ The following table lists the actual and effective default policy values for the
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
A restart of the computer is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
Audits for object access are not performed unless you enable them by using the Local Group Policy Editor, the Group Policy Management Console (GPMC), or the Auditpol command-line tool.
-
For more information about the Object Access audit policy, see [Audit object access](basic-audit-object-access.md).
-
### Group Policy
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Anyone with the **Manage auditing and security log** user right can clear the Security log to erase important evidence of unauthorized activity.
-
### Countermeasure
-
Ensure that only the local Administrators group has the **Manage auditing and security log** user right.
-
### Potential impact
-
Restricting the **Manage auditing and security log** user right to the local Administrators group is the default configuration.
-
**Warning**
If groups other than the local Administrators group have been assigned this user right, removing this user right might cause performance issues with other applications. Before removing this right from a group, investigate whether applications are dependent on this right.
-
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/manage-identity-verification-using-microsoft-passport.md b/windows/keep-secure/manage-identity-verification-using-microsoft-passport.md
index 52200ca0ed..7f4b06da3d 100644
--- a/windows/keep-secure/manage-identity-verification-using-microsoft-passport.md
+++ b/windows/keep-secure/manage-identity-verification-using-microsoft-passport.md
@@ -2,41 +2,31 @@
title: Manage identity verification using Microsoft Passport (Windows 10)
description: In Windows 10, Microsoft Passport replaces passwords with strong two-factor authentication on PCs and mobile devices. This authentication consists of a new type of user credential that is tied to a device and a Windows Hello (biometric) or PIN.
ms.assetid: 5BF09642-8CF5-4FBC-AC9A-5CA51E19387E
-keywords: ["identity", "PIN", "biometric", "Hello"]
+keywords: identity, PIN, biometric, Hello
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: jdeckerMS
---
-
# Manage identity verification using Microsoft Passport
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
In Windows 10, Microsoft Passport replaces passwords with strong two-factor authentication on PCs and mobile devices. This authentication consists of a new type of user credential that is tied to a device and a Windows Hello (biometric) or PIN.
Passport addresses the following problems with passwords:
-
- Passwords can be difficult to remember, and users often reuse passwords on multiple sites.
-
- Server breaches can expose symmetric network credentials.
-
- Passwords can be subject to [replay attacks](http://go.microsoft.com/fwlink/p/?LinkId=615673).
-
- Users can inadvertently expose their passwords due to [phishing attacks](http://go.microsoft.com/fwlink/p/?LinkId=615674).
Passport lets users authenticate to:
-
- a Microsoft account.
-
- an Active Directory account.
-
- a Microsoft Azure Active Directory (AD) account.
-
- Identity Provider Services or Relying Party Services that support [Fast ID Online (FIDO) v2.0](http://go.microsoft.com/fwlink/p/?LinkId=533889) authentication
After an initial two-step verification of the user during Passport enrollment, Passport is set up on the user's device and the user is asked to set a gesture, which can be Windows Hello or a PIN. The user provides the gesture to verify their identity. Windows then uses Passport to authenticate users and help them to access protected resources and services.
@@ -45,9 +35,7 @@ As an administrator in an enterprise or educational organization, you can create
## Benefits of Microsoft Passport
-
Reports of identity theft and large-scale hacking are frequent headlines. Nobody wants to be notified that their user name and password have been exposed.
-
You may wonder [how a PIN can help protect a device better than a password](why-a-pin-is-better-than-a-password.md). Passwords are shared secrets; they are entered on a device and transmitted over the network to the server. An intercepted account name and password can be used by anyone. Because they're stored on the server, a server breach can reveal those stored credentials.
In Windows 10, Passport replaces passwords. The Passport provisioning process creates two cryptographic keys bound to the Trusted Platform Module (TPM), if a device has a TPM, or in software. Access to these keys and obtaining a signature to validate user possession of the private key is enabled only by the PIN or biometric gesture. The two-step verification that takes place during Passport enrollment creates a trusted relationship between the identity provider and the user when the public portion of the public/private key pair is sent to an identity provider and associated with a user account. When a user enters the gesture on the device, the identify provider knows from the combination of Passport keys and gesture that this is a verified identity and provides an authentication token that allows Windows 10 to access resources and services. In addition, during the registration process, the attestation claim is produced for every identity provider to cryptographically prove that the Passport keys are tied to TPM. During registration, when the attestation claim is not presented to the identity provider, the identity provider must assume that the Passport key is created in software.
@@ -55,50 +43,34 @@ In Windows 10, Passport replaces passwords. The Passport provisioning process c
Imagine that someone is looking over your shoulder as you get money from an ATM and sees the PIN that you enter. Having that PIN won't help them access your account because they don't have your ATM card. In the same way, learning your PIN for your device doesn't allow that attacker to access your account because the PIN is local to your specific device and doesn't enable any type of authentication from any other device.
-
Passport helps protect user identities and user credentials. Because no passwords are used, it helps circumvent phishing and brute force attacks. It also helps prevent server breaches because Passport credentials are an asymmetric key pair, which helps prevent replay attacks when these keys are generated within isolated environments of TPMs.
Microsoft Passport also enables Windows 10 Mobile devices to be used as [a remote credential](prepare-people-to-use-microsoft-passport.md#bmk-remote) when signing into Windows 10 PCs. During the sign-in process, the Windows 10 PC can connect using Bluetooth to access Microsoft Passport on the user’s Windows 10 Mobile device. Because users carry their phone with them, Microsoft Passport makes implementing two-factor authentication across the enterprise less costly and complex than other solutions.
-
-**Note** Phone sign-in is currently limited to select Technology Adoption Program (TAP) participants.
-
+> **Note:** Phone sign-in is currently limited to select Technology Adoption Program (TAP) participants.
-
## How Microsoft Passport works: key points
-
- Passport credentials are based on certificate or asymmetrical key pair. Passport credentials are bound to the device, and the token that is obtained using the credential is also bound to the device.
-
- Identify provider (such as Active Directory, Azure AD, or a Microsoft account) validates user identity and maps Microsoft Passport's public key to a user account during the registration step.
-
- Keys can be generated in hardware (TPM 1.2 or 2.0 for enterprises, and TPM 2.0 for consumers) or software, based on the policy.
-
- Authentication is the two-factor authentication with the combination of a key or certificate tied to a device and something that the person knows (a PIN) or something that the person is (Windows Hello). The Passport gesture does not roam between devices and is not shared with the server; it is stored locally on a device.
-
- Private key never leaves a device. The authenticating server has a public key that is mapped to the user account during the registration process.
-
- PIN entry and Hello both trigger Windows 10 to verify the user's identity and authenticate using Passport keys or certificates.
-
- Personal (Microsoft account) and corporate (Active Directory or Azure AD) accounts use separate containers for keys. Non-Microsoft identity providers can generate keys for their users in the same container as the Microsoft account; however, all keys are separated by identity providers' domains to help ensure user privacy.
-
- Certificates are added to the Passport container and are protected by the Passport gesture.
-
- Windows Update behavior: After a reboot is required by Windows Update, the last interactive user is automatically signed on without any user gesture and the session is locked so the user's lock screen apps can run.
## Comparing key-based and certificate-based authentication
-
Passport can use either keys (hardware or software) or certificates with keys in hardware or software to confirm identity. Enterprises that have a public key infrastructure (PKI) for issuing and managing certificates can continue to use PKI in combination with Passport. Enterprises that do not use PKI or want to reduce the effort associated with managing certificates can rely on key-based credentials for Passport.
Hardware-based keys, which are generated by TPM, provide the highest level of assurance. When the TPM is manufactured, an Endorsement Key (EK) certificate is resident in the TPM. This EK certificate creates a root trust for all other keys that are generated on this TPM.
-
EK certification is used to generate an attestation identity key (AIK) certificate issued by a Microsoft certificate authority. This AIK certificate can be used as an attestation claim to prove to identity providers that the Passport keys are generated on the same TPM. The Microsoft certificate authority (CA) generates the AIK certificate per device, per user, and per IDP to help ensure that user privacy is protected.
When identity providers such as Active Directory or Azure AD enroll a certificate in Passport, Windows 10 will support the same set of scenarios as a smart card. When the credential type is a key, only key-based trust and operations will be supported.
## Learn more
-
[Introduction to Windows Hello](http://go.microsoft.com/fwlink/p/?LinkId=786649), video presentation on Microsoft Virtual Academy
[What's new in Active Directory Domain Services (AD DS) in Windows Server Technical Preview](http://go.microsoft.com/fwlink/p/?LinkId=708533)
@@ -117,7 +89,6 @@ When identity providers such as Active Directory or Azure AD enroll a certificat
## Related topics
-
[Implement Microsoft Passport in your organization](implement-microsoft-passport-in-your-organization.md)
[Why a PIN is better than a password](why-a-pin-is-better-than-a-password.md)
@@ -129,12 +100,4 @@ When identity providers such as Active Directory or Azure AD enroll a certificat
[Microsoft Passport errors during PIN creation](microsoft-passport-errors-during-pin-creation.md)
[Event ID 300 - Passport successfully created](passport-event-300.md)
-
-
-
-
-
-
-
-
-
+
\ No newline at end of file
diff --git a/windows/keep-secure/manage-packaged-apps-with-applocker.md b/windows/keep-secure/manage-packaged-apps-with-applocker.md
index 0db2b96b96..33641e9491 100644
--- a/windows/keep-secure/manage-packaged-apps-with-applocker.md
+++ b/windows/keep-secure/manage-packaged-apps-with-applocker.md
@@ -2,91 +2,47 @@
title: Manage packaged apps with AppLocker (Windows 10)
description: This topic for IT professionals describes concepts and lists procedures to help you manage Packaged apps with AppLocker as part of your overall application control strategy.
ms.assetid: 6d0c99e7-0284-4547-a30a-0685a9916650
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Manage packaged apps with AppLocker
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals describes concepts and lists procedures to help you manage Packaged apps with AppLocker as part of your overall application control strategy.
-
## Understanding Packaged apps and Packaged app installers for AppLocker
-
-
Packaged apps, also known as Universal Windows apps, are based on a model that ensures all the files within an app package share the same identity. With classic Windows apps, each file within the app could have a unique identity. With packaged apps, it is possible to control the entire app by using a single AppLocker rule.
-
**Note**
AppLocker supports only publisher rules for packaged apps. All packaged apps must be signed by the software publisher because Windows does not support unsigned packaged apps.
-
-
Typically, an app consists of multiple components: the installer that is used to install the app, and one or more exes, dlls, or scripts. With classic Windows apps, not all these components always share common attributes such as the software’s publisher name, product name, and product version. Therefore, AppLocker controls each of these components separately through different rule collections, such as exe, dll, script, and Windows Installer rules. In contrast, all the components of a packaged app share the same publisher name, package name, and package version attributes. Therefore, you can control an entire app with a single rule.
-
### Comparing classic Windows apps and packaged apps
-
AppLocker policies for packaged apps can only be applied to apps installed on computers running at least Windows Server 2012 or Windows 8, but classic Windows apps can be controlled on devices running at least Windows Server 2008 R2 or Windows 7. The rules for classic Windows apps and packaged apps can be enforced in tandem. The differences between packaged apps and classic Windows apps that you should consider include:
-
- **Installing the apps** All packaged apps can be installed by a standard user, whereas a number of classic Windows apps require administrative privileges to install. In an environment where most of the users are standard users, you might not have numerous exe rules (because classic Windows apps require administrative privileges to install), but you might want to have more explicit policies for packaged apps.
-
- **Changing the system state** Classic Windows apps can be written to change the system state if they are run with administrative privileges. Most packaged apps cannot change the system state because they run with limited privileges. When you design your AppLocker policies, it is important to understand whether an app that you are allowing can make system-wide changes.
-
- **Acquiring the apps** Packaged apps can be acquired through the Store, or by loading using Windows PowerShell cmdlets (which requires a special enterprise license). Classic Windows apps can be acquired through traditional means.
-
AppLocker uses different rule collections to control packaged apps and classic Windows apps. You have the choice to control one type, the other type, or both.
-
For info about controlling classic Windows apps, see [Administer AppLocker](administer-applocker.md).
-
For more info about packaged apps, see [Packaged apps and packaged app installer rules in AppLocker](packaged-apps-and-packaged-app-installer-rules-in-applocker.md).
-
## Design and deployment decisions
-
-
You can use two methods to create an inventory of packaged apps on a computer: the AppLocker console or the **Get-AppxPackage** Windows PowerShell cmdlet.
-
**Note**
Not all packaged apps are listed in AppLocker’s application inventory wizard. Certain app packages are framework packages that are leveraged by other apps. By themselves, these packages cannot do anything, but blocking such packages can inadvertently cause failure for apps that you want to allow. Instead, you can create Allow or Deny rules for the packaged apps that use these framework packages. The AppLocker user interface deliberately filters out all the packages that are registered as framework packages. For info about how to create an inventory list, see [Create list of apps deployed to each business group](create-list-of-applications-deployed-to-each-business-group.md).
-
-
For info about how to use the **Get-AppxPackage** Windows PowerShell cmdlet, see the [AppLocker PowerShell Command Reference](http://technet.microsoft.com/library/hh847210.aspx).
-
For info about creating rules for Packaged apps, see [Create a rule for packaged apps](create-a-rule-for-packaged-apps.md).
-
Consider the following info when you are designing and deploying apps:
-
- Because AppLocker supports only publisher rules for packaged apps, collecting the installation path information for packaged apps is not necessary.
-
- You cannot create hash- or path-based rules for packaged apps because all packaged apps and packaged app installers are signed by the software publisher of the package. Classic Windows apps were not always consistently signed; therefore, AppLocker has to support hash- or path-based rules.
-
- By default, if there are no rules in a particular rule collection, AppLocker allows every file that is included in that rule collection. For example, if there are no Windows Installer rules, AppLocker allows all .msi, .msp, and .mst files to run. An existing AppLocker policy that was targeted at computers running Windows Server 2008 R2 and Windows 7 would not have rules for Packaged apps. Therefore, when a computer running at least Windows Server 2012 or Windows 8 joins a domain where an AppLocker policy is already configured, users would be allowed to run any packaged app. This might be contrary to your design.
-
To prevent all packaged apps from running on a newly domain-joined computer, by default AppLocker blocks all packaged apps on a computer running at least Windows Server 2012 or Windows 8 if the existing domain policy has rules configured in the exe rule collection. You must take explicit action to allow packaged apps in your enterprise. You can allow only a select set of packaged apps. Or if you want to allow all packaged apps, you can create a default rule for the packaged apps collection.
-
## Using AppLocker to manage packaged apps
-
-
Just as there are differences in managing each rule collection, you need to manage the packaged apps with the following strategy:
-
1. Gather information about which Packaged apps are running in your environment. For information about how to do this, see [Create list of apps deployed to each business group](create-list-of-applications-deployed-to-each-business-group.md).
-
2. Create AppLocker rules for specific packaged apps based on your policy strategies. For more information, see [Create a rule for packaged apps](create-a-rule-for-packaged-apps.md) and [Packaged Apps Default Rules in AppLocker](http://technet.microsoft.com/library/ee460941(WS.10).aspx).
-
3. Continue to update the AppLocker policies as new package apps are introduced into your environment. To do this, see [Add rules for packaged apps to existing AppLocker rule-set](add-rules-for-packaged-apps-to-existing-applocker-rule-set.md).
-
4. Continue to monitor your environment to verify the effectiveness of the rules that are deployed in AppLocker policies. To do this, see [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md).
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/manage-tpm-commands.md b/windows/keep-secure/manage-tpm-commands.md
index 1d9de633fa..0683127abc 100644
--- a/windows/keep-secure/manage-tpm-commands.md
+++ b/windows/keep-secure/manage-tpm-commands.md
@@ -2,105 +2,54 @@
title: Manage TPM commands (Windows 10)
description: This topic for the IT professional describes how to manage which Trusted Platform Module (TPM) commands are available to domain users and to local users.
ms.assetid: a78e751a-2806-43ae-9c20-2e7ca466b765
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Manage TPM commands
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional describes how to manage which Trusted Platform Module (TPM) commands are available to domain users and to local users.
-
##
-
-
After a computer user takes ownership of the TPM, the TPM owner can limit which TPM commands can be run by creating a list of blocked TPM commands. The list can be created and applied to all computers in a domain by using Group Policy, or a list can be created for individual computers by using the TPM MMC. Because some hardware vendors might provide additional commands or the Trusted Computing Group may decide to add commands in the future, the TPM MMC also supports the ability to block new commands.
-
Domain administrators can configure a list of blocked TPM commands by using Group Policy. Local administrators cannot allow TPM commands that are blocked through Group Policy. For more information about this Group Policy setting, see [TPM Group Policy settings](trusted-platform-module-services-group-policy-settings.md#bkmk-tpmgp-clbtc).
-
Local administrators can block commands by using the TPM MMC, and commands on the default block list are also blocked unless the Group Policy settings are changed from the default settings.
-
Two policy settings control the enforcement which allows TPM commands to run. For more information about these policy settings, see [TPM Group Policy settings](trusted-platform-module-services-group-policy-settings.md#bkmk-tpmgp-idlb).
-
The following procedures describe how to manage the TPM command lists. You must be a member of the local Administrators group.
-
**To block TPM commands by using the Local Group Policy Editor**
-
1. Open the Local Group Policy Editor (gpedit.msc). If the **User Account Control** dialog box appears, confirm that the action it displays is what you want, and then click **Yes**.
-
**Note**
Administrators with appropriate rights in a domain can configure a Group Policy Object (GPO) that can be applied through Active Directory Domain Services (AD DS).
-
-
2. In the console tree, under **Computer Configuration**, expand **Administrative Templates**, and then expand **System**.
-
3. Under **System**, click **Trusted Platform Module Services**.
-
4. In the details pane, double-click **Configure the list of blocked TPM commands**.
-
5. Click **Enabled**, and then click **Show**.
-
6. For each command that you want to block, click **Add**, enter the command number, and then click **OK**.
-
**Note**
For a list of commands, see the [Trusted Platform Module (TPM) Specifications](http://go.microsoft.com/fwlink/p/?linkid=139770).
-
-
7. After you have added numbers for each command that you want to block, click **OK** twice.
-
8. Close the Local Group Policy Editor.
-
**To block or allow TPM commands by using the TPM MMC**
-
1. Open the TPM MMC (tpm.msc)
-
2. If the **User Account Control** dialog box appears, confirm that the action it displays is what you want, and then click **Yes**.
-
3. In the console tree, click **Command Management**. A list of TPM commands is displayed.
-
4. In the list, select a command that you want to block or allow.
-
5. Under **Actions**, click **Block Selected Command** or **Allow Selected Command** as needed. If **Allow Selected Command** is unavailable, that command is currently blocked by Group Policy.
-
**To block new commands**
-
1. Open the TPM MMC (tpm.msc).
-
If the **User Account Control** dialog box appears, confirm that the action it displays is what you want, and then click **Yes**.
-
2. In the console tree, click **Command Management**. A list of TPM commands is displayed.
-
3. In the **Action** pane, click **Block New Command**. The **Block New Command** dialog box is displayed.
-
4. In the **Command Number** text box, type the number of the new command that you want to block, and then click **OK**. The command number you entered is added to the blocked list.
-
## Use the TPM cmdlets
-
-
If you are using Windows PowerShell to manage your computers, you can also manage the TPM by using Windows PowerShell. To install the TPM cmdlets, type the following command:
-
**dism /online /enable-feature /FeatureName:tpm-psh-cmdlets**
-
For details about the individual cmdlets, see [TPM Cmdlets in Windows PowerShell](http://technet.microsoft.com/library/jj603116.aspx)
-
## Additional resources
-
-
For more info about TPM, see [Trusted Platform Module technology overview](trusted-platform-module-overview.md#bkmk-additionalresources).
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/manage-tpm-lockout.md b/windows/keep-secure/manage-tpm-lockout.md
index 2753d3dffc..efe696a11e 100644
--- a/windows/keep-secure/manage-tpm-lockout.md
+++ b/windows/keep-secure/manage-tpm-lockout.md
@@ -2,96 +2,48 @@
title: Manage TPM lockout (Windows 10)
description: This topic for the IT professional describes how to manage the lockout feature for the Trusted Platform Module (TPM) in Windows.
ms.assetid: bf27adbe-404c-4691-a644-29ec722a3f7b
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Manage TPM lockout
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional describes how to manage the lockout feature for the Trusted Platform Module (TPM) in Windows.
-
## About TPM lockout
-
-
The TPM will lock itself to prevent tampering or malicious attacks. TPM lockout often lasts for a variable amount of time or until the computer is turned off. While the TPM is in lockout mode, it generally returns an error message when it receives commands that require an authorization value. One exception is that the TPM always allows the owner at least one attempt to reset the TPM lockout when it is in lockout mode.
-
TPM ownership is commonly taken the first time BitLocker Drive Encryption is turned on for the computer. In this case, the TPM owner authorization password is saved with the BitLocker recovery key. When the BitLocker recovery key is saved to a file, BitLocker also saves a TPM owner password file (.tpm) with the TPM owner password hash value. When the BitLocker recovery key is printed, the TPM owner password is printed at the same time. You can also save your TPM owner password hash value to Active Directory Domain Services (AD DS) if your organization's Group Policy settings are configured to do so.
-
In some cases, encryption keys are protected by a TPM by requiring a valid authorization value to access the key. A common example is configuring BitLocker Drive Encryption to use the TPM plus PIN key protector. In this scenario, the user must type the correct PIN during the boot process to access the volume encryption key protected by the TPM. To prevent malicious users or software from discovering authorization values, TPMs implement protection logic. The protection logic is designed to slow or stop responses from the TPM if it detects that an entity might be trying to guess authorization values.
-
The industry standards from the Trusted Computing Group (TCG) specify that TPM manufacturers must implement some form of protection logic in TPM 1.2 and TPM 2.0 chips. TPM manufacturers implement different protection mechanisms and behavior. The general guidance is for the TPM chip to take exponentially longer to respond if incorrect authorization values are sent to the TPM. Some TPM chips may not store failed attempts over time. Other TPM chips may store every failed attempt indefinitely. Therefore, some users may experience increasingly longer delays when they mistype an authorization value that is sent to the TPM. This can prevent them from using the TPM for a period of time.
-
If your TPM has entered lockout mode or is responding slowly to commands, you can reset the lockout value by using the following procedures. Resetting the TPM lockout requires the TPM owner’s authorization.
-
## Reset the TPM lockout by using the TPM MMC
-
-
The following procedure explains the steps to reset the TPM lockout by using the TPM MMC.
-
**To reset the TPM lockout**
-
1. Open the TPM MMC (tpm.msc).
-
2. In the **Action** pane, click **Reset TPM Lockout** to start the Reset TPM Lockout Wizard.
-
3. Choose one of the following methods to enter the TPM owner password:
-
- If you saved your TPM owner password to a .tpm file, click **I have the owner password file**, and then type the path to the file, or click **Browse** to navigate to the file location.
-
- If you want to manually enter your TPM owner password, click **I want to enter the owner password**, and then type the password in the text box provided.
-
**Note**
If you enabled BitLocker and your TPM at the same time, and you printed your BitLocker recovery password when you turned on BitLocker, your TPM owner password may have printed with it.
-
-
## Use Group Policy to manage TPM lockout settings
-
-
The TPM Group Policy settings in the following list are located at:
-
**Computer Configuration\\Administrative Templates\\System\\Trusted Platform Module Services\\**
-
- [Standard User Lockout Duration](trusted-platform-module-services-group-policy-settings.md#bkmk-individual)
-
This policy setting allows you to manage the duration in minutes for counting standard user authorization failures for TPM commands that require authorization. An authorization failure occurs each time a user sends a command to the TPM and receives an error message that indicates an authorization failure occurred. Authorization failures that are older than the duration you set are ignored. If the number of TPM commands with an authorization failure within the lockout duration equals a threshold, the user is prevented from sending commands to the TPM that require authorization.
-
- [Standard User Individual Lockout Threshold](trusted-platform-module-services-group-policy-settings.md#bkmk-tpmgp-suld)
-
This policy setting allows you to manage the maximum number of authorization failures for the TPM for each user. This value is the maximum number of authorization failures that each user can have before the user is not allowed to send commands to the TPM that require authorization. If the number of authorization failures equals the duration that is set for the policy setting, the user is prevented from sending commands to the TPM that require authorization.
-
- [Standard User Total Lockout Threshold](trusted-platform-module-services-group-policy-settings.md#bkmk-total)
-
This policy setting allows you to manage the maximum number of authorization failures for the TPM for all standard users. If the total number of authorization failures for all users equals the duration that is set for the policy, all users are prevented from sending commands to the TPM that require authorization.
-
For information about mitigating dictionary attacks that use the lockout settings, see [TPM fundamentals](tpm-fundamentals.md#bkmk-howtpmmitigates).
-
## Use the TPM cmdlets
-
-
If you are using Windows PowerShell to manage your computers, you can also manage the TPM by using Windows PowerShell. To install the TPM cmdlets, type the following command:
-
**dism /online /enable-feature /FeatureName:tpm-psh-cmdlets**
-
For details about the individual cmdlets, see [TPM Cmdlets in Windows PowerShell](http://technet.microsoft.com/library/jj603116.aspx).
-
## Additional resources
-
-
For more info about TPM, see [TPM technology overview](trusted-platform-module-overview.md#bkmk-additionalresources).
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/maximum-lifetime-for-service-ticket.md b/windows/keep-secure/maximum-lifetime-for-service-ticket.md
index d1ddb01b51..35118cc805 100644
--- a/windows/keep-secure/maximum-lifetime-for-service-ticket.md
+++ b/windows/keep-secure/maximum-lifetime-for-service-ticket.md
@@ -2,48 +2,29 @@
title: Maximum lifetime for service ticket (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Maximum lifetime for service ticket security policy setting.
ms.assetid: 484bf05a-3858-47fc-bc02-6599ca860247
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Maximum lifetime for service ticket
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Maximum lifetime for service ticket** security policy setting.
-
## Reference
-
-
The **Maximum lifetime for service ticket** policy setting determines the maximum number of minutes that a granted session ticket can be used to access a particular service. The value must be 10 minutes or greater, and it must be less than or equal to the value of the **Maximum lifetime for service ticket** policy setting.
-
The possible values for this Group Policy setting are:
-
- A user-defined number of minutes from 10 through 99,999, or 0 (in which case service tickets do not expire).
-
- Not defined.
-
If a client presents an expired session ticket when it requests a connection to a server, the server returns an error message. The client must request a new session ticket from the Kerberos V5 KDC. After a connection is authenticated, however, it no longer matters whether the session ticket remains valid. Session tickets are used only to authenticate new connections with servers. Ongoing operations are not interrupted if the session ticket that authenticated the connection expires during the connection.
-
If the value for this policy setting is too high, users might be able to access network resources outside of their logon hours. In addition, users whose accounts have been disabled might be able to continue accessing network services by using valid service tickets that were issued before their account was disabled. If the value is set to 0, service tickets never expire.
-
### Best practices
-
- It is advisable to set **Maximum lifetime for service ticket** to **600** minutes.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Kerberos Policy
-
### Default values
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -82,61 +63,28 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
A restart of the device is not required for this policy setting to be effective.
-
This policy setting is configured on the domain controller.
-
### Group Policy
-
Client computers will get the new setting during the next scheduled and successful Group Policy refresh. But for domain controllers to assign these new settings immediately, a gpupdate.exe /force is required. On the local device, the Security Configuration Engine will refresh this setting in about five minutes.
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
If you configure the value for the **Maximum lifetime for service ticket** setting too high, users might be able to access network resources outside of their logon hours. Also, users whose accounts were disabled might continue to have access to network services with valid service tickets that were issued before their accounts were disabled.
-
### Countermeasure
-
Configure the **Maximum lifetime for service ticket** setting to 600 minutes.
-
### Potential impact
-
None. This is the default configuration.
-
## Related topics
-
-
[Kerberos Policy](kerberos-policy.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/maximum-lifetime-for-user-ticket-renewal.md b/windows/keep-secure/maximum-lifetime-for-user-ticket-renewal.md
index 2a1b0a18e3..bcb1a344e6 100644
--- a/windows/keep-secure/maximum-lifetime-for-user-ticket-renewal.md
+++ b/windows/keep-secure/maximum-lifetime-for-user-ticket-renewal.md
@@ -2,46 +2,28 @@
title: Maximum lifetime for user ticket renewal (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Maximum lifetime for user ticket renewal security policy setting.
ms.assetid: f88cd819-3dd1-4e38-b560-13fe6881b609
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Maximum lifetime for user ticket renewal
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Maximum lifetime for user ticket renewal** security policy setting.
-
## Reference
-
-
The **Maximum lifetime for user ticket renewal** policy setting determines the period of time (in days) during which a user’s ticket-granting ticket can be renewed.
-
The possible values for this Group Policy setting are:
-
- A user-defined number of days from 0 through 99,999
-
- Not defined
-
### Best practices
-
- If the value for this policy setting is too high, users may be able to renew very old user ticket-granting tickets. If the value is 0, ticket-granting tickets never expire.
-
It is advisable to set **Maximum lifetime for user ticket renewal** to **7** days.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Kerberos Policy
-
### Default values
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -80,60 +62,28 @@ The following table lists the actual and effective default policy values. Defaul
-
-
### Policy management
-
This section describes features, tools, and guidance to help you manage this policy.
-
A restart of the device is not required for this policy setting to be effective.
-
This policy setting is configured on the domain controller.
-
### Group Policy
-
Client devices will get the new setting during the next scheduled and successful Group Policy refresh. But for domain controllers to assign these new settings immediately, a gpupdate.exe /force is required. On the local device, the Security Configuration Engine will refresh this setting in about five minutes.
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
If the value for the **Maximum lifetime for user ticket renewal** setting is too high, users might be able to renew very old user tickets.
-
### Countermeasure
-
Configure the **Maximum lifetime for user ticket renewal** setting to 7 days.
-
### Potential impact
-
None. This is the default configuration.
-
## Related topics
-
-
[Kerberos Policy](kerberos-policy.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/maximum-lifetime-for-user-ticket.md b/windows/keep-secure/maximum-lifetime-for-user-ticket.md
index 7301401239..4d15d5cbd8 100644
--- a/windows/keep-secure/maximum-lifetime-for-user-ticket.md
+++ b/windows/keep-secure/maximum-lifetime-for-user-ticket.md
@@ -2,46 +2,28 @@
title: Maximum lifetime for user ticket (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Maximum lifetime for user ticket policy setting.
ms.assetid: bcb4ff59-334d-4c2f-99af-eca2b64011dc
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Maximum lifetime for user ticket
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Maximum lifetime for user ticket** policy setting.
-
## Reference
-
-
The **Maximum lifetime for user ticket** policy setting determines the maximum amount of time (in hours) that a user’s ticket-granting ticket can be used. When a user’s ticket-granting ticket expires, a new one must be requested or the existing one must be renewed.
-
The possible values for this Group Policy setting are:
-
- A user-defined number of hours from 0 through 99,999
-
- Not defined
-
If the value for this policy setting is too high, users might be able to access network resources outside of their logon hours, or users whose accounts have been disabled might be able to continue to access network services by using valid service tickets that were issued before their account was disabled. If the value is set to 0, ticket-granting tickets never expire.
-
### Best practices
-
- It is advisable to set **Maximum lifetime for user ticket** to 10 hours.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Kerberos Policy
-
### Default Values
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -80,61 +62,28 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
A restart of the computer is not required for this policy setting to be effective.
-
This policy setting is configured on the domain controller.
-
### Group Policy
-
Client devices will get the new setting during the next scheduled and successful Group Policy refresh. But for domain controllers to assign these new settings immediately, a gpupdate.exe /force is required. On the local computer, the Security Configuration Engine will refresh this setting in about five minutes.
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
If you configure the value for the **Maximum lifetime for user ticket** setting too high, users might be able to access network resources outside of their logon hours. Also, users whose accounts were disabled might continue to have access to network services with valid user tickets that were issued before their accounts were disabled. If you configure this value too low, ticket requests to the KDC may affect the performance of your KDC and present an opportunity for a DoS attack.
-
### Countermeasure
-
Configure the **Maximum lifetime for user ticket** setting with a value between 4 and 10 hours.
-
### Potential impact
-
Reducing this setting from the default value reduces the likelihood that the ticket-granting ticket will be used to access resources that the user does not have rights to. However, it requires more frequent requests to the KDC for ticket-granting tickets on behalf of users. Most KDCs can support a value of four hours without too much additional burden.
-
## Related topics
-
-
[Kerberos Policy](kerberos-policy.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/maximum-password-age.md b/windows/keep-secure/maximum-password-age.md
index b80a337270..2c384dcf41 100644
--- a/windows/keep-secure/maximum-password-age.md
+++ b/windows/keep-secure/maximum-password-age.md
@@ -2,49 +2,30 @@
title: Maximum password age (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Maximum password age security policy setting.
ms.assetid: 2d6e70e7-c8b0-44fb-8113-870c6120871d
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Maximum password age
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Maximum password age** security policy setting.
-
## Reference
-
-
The **Maximum password age** policy setting determines the period of time (in days) that a password can be used before the system requires the user to change it. You can set passwords to expire after a number of days between 1 and 999, or you can specify that passwords never expire by setting the number of days to 0. If **Maximum password age** is between 1 and 999 days, the minimum password age must be less than the maximum password age. If **Maximum password age** is set to 0, [Minimum password age](minimum-password-age.md) can be any value between 0 and 998 days.
-
**Note**
Setting **Maximum password age** to -1 is equivalent to 0, which means it never expires. Setting it to any other negative number is equivalent to setting it to **Not Defined**.
-
-
### Possible values
-
- User-specified number of days between 0 and 999
-
- Not defined
-
### Best practices
-
Set **Maximum password age** to a value between 30 and 90 days, depending on your environment. This way, an attacker has a limited amount of time in which to compromise a user's password and have access to your network resources.
-
### Location
-
**Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Password Policy**
-
### Default values
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -83,45 +64,20 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a computer restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
The longer a password exists, the higher the likelihood that it will be compromised by a brute force attack, by an attacker gaining general knowledge about the user, or by the user sharing the password. Configuring the **Maximum password age** policy setting to 0 so that users are never required to change their passwords is a major security risk because that allows a compromised password to be used by the malicious user for as long as the valid user is authorized access.
-
### Countermeasure
-
Configure the **Maximum password age** policy setting to a value that is suitable for your organization's business requirements.
-
### Potential impact
-
If the **Maximum password age** policy setting is too low, users are required to change their passwords very often. Such a configuration can reduce security in the organization because users might keep their passwords in an unsecured location or lose them. If the value for this policy setting is too high, the level of security within an organization is reduced because it allows potential attackers more time in which to discover user passwords or to use compromised accounts.
-
## Related topics
-
-
[Password Policy](password-policy.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/maximum-tolerance-for-computer-clock-synchronization.md b/windows/keep-secure/maximum-tolerance-for-computer-clock-synchronization.md
index 9fc39fe52d..5923108470 100644
--- a/windows/keep-secure/maximum-tolerance-for-computer-clock-synchronization.md
+++ b/windows/keep-secure/maximum-tolerance-for-computer-clock-synchronization.md
@@ -2,46 +2,28 @@
title: Maximum tolerance for computer clock synchronization (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Maximum tolerance for computer clock synchronization security policy setting.
ms.assetid: ba2cf59e-d69d-469e-95e3-8e6a0ba643af
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Maximum tolerance for computer clock synchronization
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Maximum tolerance for computer clock synchronization** security policy setting.
-
## Reference
-
-
This security setting determines the maximum time difference (in minutes) that Kerberos V5 tolerates between the time on the client clock and the time on the domain controller that provides Kerberos authentication.
-
To prevent "replay attacks," the Kerberos v5 protocol uses time stamps as part of its protocol definition. For time stamps to work properly, the clocks of the client and the domain controller need to be in sync as much as possible. In other words, both devices must be set to the same time and date. Because the clocks of two computers are often out of sync, you can use this policy setting to establish the maximum acceptable difference to the Kerberos protocol between a client clock and domain controller clock. If the difference between a client computer clock and the domain controller clock is less than the maximum time difference that is specified in this policy, any time stamp that is used in a session between the two devices is considered to be authentic.
-
The possible values for this Group Policy setting are:
-
- A user-defined number of minutes from 1 through 99,999
-
- Not defined
-
### Best practices
-
- It is advisable to set **Maximum tolerance for computer clock synchronization** to a value of 5 minutes.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Kerberos Policy
-
### Default values
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -80,61 +62,28 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
A restart of the device is not required for this policy setting to be effective.
-
This policy setting is configured on the domain controller.
-
### Group Policy
-
Client devices will get the new setting during the next scheduled and successful Group Policy refresh. But for domain controllers to assign these new settings immediately, a gpupdate.exe /force is required. On the local device, the Security Configuration Engine will refresh this setting in about five minutes.
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
To prevent "replay attacks" (which are attacks in which an authentication credential is resubmitted by a malicious user or program to gain access to a protected resource), the Kerberos protocol uses time stamps as part of its definition. For time stamps to work properly, the clocks of the client computer and the domain controller need to be closely synchronized. Because the clocks of two computers are often not synchronized, administrators can use this policy to establish the maximum acceptable difference to the Kerberos protocol between a client computer clock and a domain controller clock. If the difference between the client computer clock and the domain controller clock is less than the maximum time difference specified in this setting, any time stamp that is used in a session between the two computers is considered to be authentic.
-
### Countermeasure
-
Configure the **Maximum tolerance for computer clock synchronization** setting to 5 minutes.
-
### Potential impact
-
None. This is the default configuration.
-
## Related topics
-
-
[Kerberos Policy](kerberos-policy.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/merge-applocker-policies-by-using-set-applockerpolicy.md b/windows/keep-secure/merge-applocker-policies-by-using-set-applockerpolicy.md
index 746254c18e..3b95f2b434 100644
--- a/windows/keep-secure/merge-applocker-policies-by-using-set-applockerpolicy.md
+++ b/windows/keep-secure/merge-applocker-policies-by-using-set-applockerpolicy.md
@@ -2,49 +2,27 @@
title: Merge AppLocker policies by using Set-ApplockerPolicy (Windows 10)
description: This topic for IT professionals describes the steps to merge AppLocker policies by using Windows PowerShell.
ms.assetid: f1c7d5c0-463e-4fe2-a410-844a404f18d0
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Merge AppLocker policies by using Set-ApplockerPolicy
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals describes the steps to merge AppLocker policies by using Windows PowerShell.
-
The **Set-AppLockerPolicy** cmdlet sets the specified Group Policy Object (GPO) to contain the specified AppLocker policy. If no Lightweight Directory Access Protocol (LDAP) is specified, the local GPO is the default. When the Merge parameter is used, rules in the specified AppLocker policy will be merged with the AppLocker rules in the target GPO specified in the LDAP path. The merging of policies will remove rules with duplicate rule IDs, and the enforcement setting specified by the AppLocker policy in the target GPO will be preserved. If the Merge parameter is not specified, then the new policy will overwrite the existing policy.
-
For info about using **Set-AppLockerPolicy**, including syntax descriptions and parameters, see [Set-AppLockerPolicy](http://technet.microsoft.com/library/hh847212.aspx).
-
For info about using Windows PowerShell for AppLocker, including how to import the AppLocker cmdlets into Windows PowerShell, see [Use the AppLocker Windows PowerShell cmdlets](use-the-applocker-windows-powershell-cmdlets.md).
-
You can also manually merge AppLocker policies. For the procedure to do this, see [Merge AppLocker policies manually](merge-applocker-policies-manually.md).
-
**To merge a local AppLocker policy with another AppLocker policy by using LDAP paths**
-
1. Open the PowerShell command window. For info about performing Windows PowerShell commands for AppLocker, see [Use the AppLocker Windows PowerShell cmdlets](use-the-applocker-windows-powershell-cmdlets.md).
-
2. At the command prompt, type **C:\\PS>Get-AppLockerPolicy -Local | Set-AppLockerPolicy -LDAP "LDAP: //***<string>***"** **-Merge** where *<string>* specifies the LDAP path of the unique GPO.
-
## Example
-
-
Gets the local AppLocker policy, and then merges the policy with the existing AppLocker policy in the GPO specified in the LDAP path.
-
``` syntax
C:\PS>Get-AppLockerPolicy -Local | Set-AppLockerPolicy -LDAP "LDAP://DC13.Contoso.com/CN={31B2F340-016D-11D2-945F-00C044FB984F9},CN=Policies,CN=System,DC=Contoso,DC=com" -Merge
```
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/merge-applocker-policies-manually.md b/windows/keep-secure/merge-applocker-policies-manually.md
index dc7b2e2f7c..160ae52209 100644
--- a/windows/keep-secure/merge-applocker-policies-manually.md
+++ b/windows/keep-secure/merge-applocker-policies-manually.md
@@ -2,25 +2,18 @@
title: Merge AppLocker policies manually (Windows 10)
description: This topic for IT professionals describes the steps to manually merge AppLocker policies to update the Group Policy Object (GPO).
ms.assetid: 3605f293-e5f2-481d-8efd-775f9f23c30f
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Merge AppLocker policies manually
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals describes the steps to manually merge AppLocker policies to update the Group Policy Object (GPO).
-
If you have created multiple AppLocker policies and need to merge them to create one AppLocker policy, you can either manually merge the policies or use the Windows PowerShell cmdlets for AppLocker. You cannot automatically merge policies by using the AppLocker console. You must create one rule collection from two or more policies. For info about merging policies by using the cmdlet, see [Merge AppLocker policies by using Set-ApplockerPolicy](merge-applocker-policies-by-using-set-applockerpolicy.md).
-
The AppLocker policy is saved in XML format, and the exported policy can be edited with any text or XML editor. Rule collections are specified within the **RuleCollection Type** element. The XML schema includes five attributes for the different rule collections, as shown in the following table:
-
@@ -55,11 +48,8 @@ The AppLocker policy is saved in XML format, and the exported policy can be edit
-
-
Rule enforcement is specified with the **EnforcementMode** element. The three enforcement modes in the XML correspond to the three enforcement modes in the AppLocker console, as shown in the following table:
-
@@ -86,34 +76,16 @@ Rule enforcement is specified with the **EnforcementMode** element. The three en
-
-
Each of the three condition types use specific elements. For XML examples of the different rule types, see Merge AppLocker policies manually.
-
Membership in the local **Administrators** group, or equivalent, is the minimum required to complete this procedure.
-
**To merge two or more AppLocker policies**
-
1. Open an XML policy file in a text editor or XML editor, such as Notepad.
-
2. Select the rule collection where you want to copy rules from.
-
3. Select the rules that you want to add to another policy file, and then copy the text.
-
4. Open the policy where you want to add the copied rules.
-
5. Select and expand the rule collection where you want to add the rules.
-
6. At the bottom of the rule list for the collection, after the closing element, paste the rules that you copied from the first policy file. Verify that the opening and closing elements are intact, and then save the policy.
-
7. Upload the policy to a reference computer to ensure that it is functioning properly within the GPO.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/microsoft-network-client-digitally-sign-communications-always.md b/windows/keep-secure/microsoft-network-client-digitally-sign-communications-always.md
index 5eed7b34b9..ae89b2c502 100644
--- a/windows/keep-secure/microsoft-network-client-digitally-sign-communications-always.md
+++ b/windows/keep-secure/microsoft-network-client-digitally-sign-communications-always.md
@@ -2,72 +2,41 @@
title: Microsoft network client Digitally sign communications (always) (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Microsoft network client Digitally sign communications (always) security policy setting.
ms.assetid: 4b7b0298-b130-40f8-960d-60418ba85f76
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Microsoft network client: Digitally sign communications (always)
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **Microsoft network client: Digitally sign communications (always)** security policy setting.
-
## Reference
-
-
The Server Message Block (SMB) protocol provides the basis for file and print sharing and many other networking operations, such as remote Windows administration. To prevent man-in-the-middle attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets. This policy setting determines whether SMB packet signing must be negotiated before further communication with the Server service is permitted.
-
Implementation of digital signatures in high-security networks helps prevent the impersonation of client computers and servers, which is known as "session hijacking." But misuse of these policy settings is a common error that can cause data loss or problems with data access or security.
-
If server-side SMB signing is required, a client device will not be able to establish a session with that server, unless it has client-side SMB signing enabled. By default, client-side SMB signing is enabled on workstations, servers, and domain controllers. Similarly, if client-side SMB signing is required, that client device will not be able to establish a session with servers that do not have packet signing enabled. By default, server-side SMB signing is enabled only on domain controllers.
-
If server-side SMB signing is enabled, SMB packet signing will be negotiated with client computers that have SMB signing enabled.
-
Using SMB packet signing can impose up to a 15 percent performance degradation on file service transactions.
-
There are three other policy settings that relate to packet-signing requirements for Server Message Block (SMB) communications:
-
- [Microsoft network server: Digitally sign communications (always)](microsoft-network-server-digitally-sign-communications-always.md)
-
- [Microsoft network client: Digitally sign communications (if server agrees)](microsoft-network-client-digitally-sign-communications-if-server-agrees.md)
-
- [Microsoft network server: Digitally sign communications (if client agrees)](microsoft-network-server-digitally-sign-communications-if-client-agrees.md)
-
### Possible values
-
- Enabled
-
- Disabled
-
- Not defined
-
### Best practices
-
1. Configure the following security policy settings as follows:
-
- Disable **Microsoft network client: Digitally sign communications (always)**.
-
- Disable [Microsoft network server: Digitally sign communications (always)](microsoft-network-server-digitally-sign-communications-always.md).
-
- Enable [Microsoft network client: Digitally sign communications (if server agrees)](microsoft-network-client-digitally-sign-communications-if-server-agrees.md).
-
- Enable [Microsoft network server: Digitally sign communications (if client agrees)](microsoft-network-server-digitally-sign-communications-if-client-agrees.md).
-
2. Alternately, you can set all of these policy settings to Enabled, but enabling them can cause slower performance on client devices and prevent them from communicating with legacy SMB applications and operating systems.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -106,64 +75,30 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Session hijacking uses tools that allow attackers who have access to the same network as the client device or server to interrupt, end, or steal a session in progress. Attackers can potentially intercept and modify unsigned Server Message Block (SMB) packets and then modify the traffic and forward it so that the server might perform objectionable actions. Alternatively, the attacker could pose as the server or client computer after legitimate authentication, and gain unauthorized access to data.
-
SMB is the resource-sharing protocol that is supported by many Windows operating systems. It is the basis of NetBIOS and many other protocols. SMB signatures authenticate users and the servers that host the data. If either side fails the authentication process, data transmission does not take place.
-
### Countermeasure
-
Configure the settings as follows:
-
- Disable **Microsoft network client: Digitally sign communications (always)**.
-
- Disable [Microsoft network server: Digitally sign communications (always)](microsoft-network-server-digitally-sign-communications-always.md).
-
- Enable [Microsoft network client: Digitally sign communications (if server agrees)](microsoft-network-client-digitally-sign-communications-if-server-agrees.md).
-
- Enable [Microsoft network server: Digitally sign communications (if client agrees)](microsoft-network-server-digitally-sign-communications-if-client-agrees.md).
-
In highly secure environments, we recommend that you configure all of these settings to Enabled. However, that configuration may cause slower performance on client devices and prevent communications with earlier SMB applications and operating systems.
-
**Note**
An alternative countermeasure that could protect all network traffic is to implement digital signatures with IPsec. There are hardware-based accelerators for IPsec encryption and signing that could be used to minimize the performance impact on the servers' CPUs. No such accelerators are available for SMB signing.
-
-
### Potential impact
-
Implementations of the SMB file and print-sharing protocol support mutual authentication. This prevents session hijacking attacks and supports message authentication to prevent man-in-the-middle attacks. SMB signing provides this authentication by placing a digital signature into each SMB, which is then verified by the client and the server.
-
Implementation of SMB signing may negatively affect performance because each packet must be signed and verified. If these settings are enabled on a server that is performing multiple roles, such as a small business server that is serving as a domain controller, file server, print server, and application server, performance may be substantially slowed. Additionally, if you configure devices to ignore all unsigned SMB communications, older applications and operating systems cannot connect. However, if you completely disable all SMB signing, computers are vulnerable to session-hijacking attacks.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/microsoft-network-client-digitally-sign-communications-if-server-agrees.md b/windows/keep-secure/microsoft-network-client-digitally-sign-communications-if-server-agrees.md
index d9567dee32..287afc0542 100644
--- a/windows/keep-secure/microsoft-network-client-digitally-sign-communications-if-server-agrees.md
+++ b/windows/keep-secure/microsoft-network-client-digitally-sign-communications-if-server-agrees.md
@@ -2,72 +2,41 @@
title: Microsoft network client Digitally sign communications (if server agrees) (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Microsoft network client Digitally sign communications (if server agrees) security policy setting.
ms.assetid: e553f700-aae5-425c-8650-f251c90ba5dd
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Microsoft network client: Digitally sign communications (if server agrees)
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **Microsoft network client: Digitally sign communications (if server agrees)** security policy setting.
-
## Reference
-
-
The Server Message Block (SMB) protocol provides the basis for Microsoft file and print sharing and many other networking operations, such as remote Windows administration. To prevent man-in-the-middle attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets. This policy setting determines whether SMB packet signing must be negotiated before further communication with the Server service is permitted.
-
Implementation of digital signatures in high-security networks helps to prevent the impersonation of client computers and servers, which is known as "session hijacking." But misuse of these policy settings is a common error that can cause data loss or problems with data access or security.
-
If server-side SMB signing is required, a client computer will not be able to establish a session with that server, unless it has client-side SMB signing enabled. By default, client-side SMB signing is enabled on workstations, servers, and domain controllers. Similarly, if client-side SMB signing is required, that client device will not be able to establish a session with servers that do not have packet signing enabled. By default, server-side SMB signing is enabled only on domain controllers.
-
If server-side SMB signing is enabled, SMB packet signing will be negotiated with client computers that have SMB signing enabled.
-
Using SMB packet signing can impose up to a 15 percent performance degradation on file service transactions.
-
There are three other policy settings that relate to packet-signing requirements for Server Message Block (SMB) communications:
-
- [Microsoft network server: Digitally sign communications (always)](microsoft-network-server-digitally-sign-communications-always.md)
-
- [Microsoft network client: Digitally sign communications (always)](microsoft-network-client-digitally-sign-communications-always.md)
-
- [Microsoft network server: Digitally sign communications (if client agrees)](microsoft-network-server-digitally-sign-communications-if-client-agrees.md)
-
### Possible values
-
- Enabled
-
- Disabled
-
- Not defined
-
### Best practices
-
1. Configure the following security policy settings as follows:
-
- Disable [Microsoft network client: Digitally sign communications (always)](microsoft-network-client-digitally-sign-communications-always.md).
-
- Disable [Microsoft network server: Digitally sign communications (always)](microsoft-network-server-digitally-sign-communications-always.md).
-
- Enable **Microsoft Network Client: Digitally Sign Communications (If Server Agrees)**.
-
- Enable [Microsoft network server: Digitally sign communications (if client agrees)](microsoft-network-server-digitally-sign-communications-if-client-agrees.md).
-
2. Alternately, you can set all of these policy settings to Enabled, but enabling them can cause slower performance on client devices and prevent them from communicating with legacy SMB applications and operating systems.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -106,64 +75,30 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Session hijacking uses tools that allow attackers who have access to the same network as the client or server to interrupt, end, or steal a session in progress. Attackers can potentially intercept and modify unsigned Server Message Block (SMB) packets and then modify the traffic and forward it so that the server might perform objectionable actions. Alternatively, the attacker could pose as the server or client device after legitimate authentication and gain unauthorized access to data.
-
SMB is the resource-sharing protocol that is supported by many Windows operating systems. It is the basis of NetBIOS and many other protocols. SMB signatures authenticate users and the servers that host the data. If either side fails the authentication process, data transmission does not take place.
-
### Countermeasure
-
Configure the settings as follows:
-
- Disable [Microsoft network client: Digitally sign communications (always)](microsoft-network-client-digitally-sign-communications-always.md).
-
- Disable [Microsoft network server: Digitally sign communications (always)](microsoft-network-server-digitally-sign-communications-always.md).
-
- Enable **Microsoft network client: Digitally sign communications (if server agrees)**.
-
- Enable [Microsoft network server: Digitally sign communications (if client agrees)](microsoft-network-server-digitally-sign-communications-if-client-agrees.md).
-
In highly secure environments we recommend that you configure all of these settings to Enabled. However, that configuration may cause slower performance on client devices and prevent communications with earlier SMB applications and operating systems.
-
**Note**
An alternative countermeasure that could protect all network traffic is to implement digital signatures with IPsec. There are hardware-based accelerators for IPsec encryption and signing that could be used to minimize the performance impact on the servers' CPUs. No such accelerators are available for SMB signing.
-
-
### Potential impact
-
Implementations of the SMB file and print-sharing protocol support mutual authentication. This prevents session hijacking attacks and supports message authentication to prevent man-in-the-middle attacks. SMB signing provides this authentication by placing a digital signature into each SMB, which is then verified by the client and the server.
-
Implementation of SMB signing may negatively affect performance because each packet must be signed and verified. If these settings are enabled on a server that is performing multiple roles, such as a small business server that is serving as a domain controller, file server, print server, and application server, performance may be substantially slowed. Additionally, if you configure devices to ignore all unsigned SMB communications, older applications and operating systems cannot connect. However, if you completely disable all SMB signing, devices are vulnerable to session-hijacking attacks.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/microsoft-network-client-send-unencrypted-password-to-third-party-smb-servers.md b/windows/keep-secure/microsoft-network-client-send-unencrypted-password-to-third-party-smb-servers.md
index d65dfe9610..c14351f372 100644
--- a/windows/keep-secure/microsoft-network-client-send-unencrypted-password-to-third-party-smb-servers.md
+++ b/windows/keep-secure/microsoft-network-client-send-unencrypted-password-to-third-party-smb-servers.md
@@ -2,50 +2,30 @@
title: Microsoft network client Send unencrypted password to third-party SMB servers (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Microsoft network client Send unencrypted password to third-party SMB servers security policy setting.
ms.assetid: 97a76b93-afa7-4dd9-bb52-7c9e289b6017
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Microsoft network client: Send unencrypted password to third-party SMB servers
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **Microsoft network client: Send unencrypted password to third-party SMB servers** security policy setting.
-
## Reference
-
-
The Server Message Block (SMB) protocol provides the basis for file and print sharing and many other networking operations, such as remote Windows administration. This policy setting allows or prevents the SMB redirector to send plaintext passwords to a non-Microsoft server service that does not support password encryption during authentication.
-
### Possible values
-
- Enabled
-
The Server Message Block (SMB) redirector is allowed to send plaintext passwords to a non-Microsoft server service that does not support password encryption during authentication.
-
- Disabled
-
The Server Message Block (SMB) redirector only sends encrypted passwords to non-Microsoft SMB server services. If those server services do not support password encryption, the authentication request will fail.
-
- Not defined
-
### Best practices
-
- It is advisable to set **Microsoft network client: Send unencrypted password to connect to third-party SMB servers** to Disabled.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -84,45 +64,20 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
If you enable this policy setting, the server can transmit plaintext passwords across the network to other computers that offer SMB services. These other devices might not use any of the SMB security mechanisms that are included with Windows Server 2003 or later.
-
### Countermeasure
-
Disable the **Microsoft network client: Send unencrypted password to connect to third-party SMB servers** setting.
-
### Potential impact
-
Some older applications may not be able to communicate with the servers in your organization by means of the SMB protocol.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/microsoft-network-server-amount-of-idle-time-required-before-suspending-session.md b/windows/keep-secure/microsoft-network-server-amount-of-idle-time-required-before-suspending-session.md
index 4b1e5d32b1..754051399a 100644
--- a/windows/keep-secure/microsoft-network-server-amount-of-idle-time-required-before-suspending-session.md
+++ b/windows/keep-secure/microsoft-network-server-amount-of-idle-time-required-before-suspending-session.md
@@ -2,48 +2,29 @@
title: Microsoft network server Amount of idle time required before suspending session (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Microsoft network server Amount of idle time required before suspending session security policy setting.
ms.assetid: 8227842a-569d-480f-b43c-43450bbaa722
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Microsoft network server: Amount of idle time required before suspending session
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **Microsoft network server: Amount of idle time required before suspending session** security policy setting.
-
## Reference
-
-
Each Server Message Block (SMB) session consumes server resources. Establishing numerous null sessions will cause the server to slow down or possibly fail. A malicious user might repeatedly establish SMB sessions until the server stops responding; at this point, SMB services will become slow or unresponsive.
-
The **Microsoft network server: Amount of idle time required before suspending session** policy setting determines the amount of continuous idle time that must pass in an SMB session before the session is suspended due to inactivity. You can use this policy setting to control when a device suspends an inactive SMB session. The session is automatically reestablished when client device activity resumes.
-
### Possible values
-
- A user-defined number of minutes from 0 through 99,999
-
For this policy setting, a value of 0 means to disconnect an idle session as quickly as is reasonably possible. The maximum value is 99999, which is 208 days. In effect, this value disables the policy.
-
- Not defined
-
### Best practices
-
- It is advisable to set this policy to 15 minutes. There will be little impact because SMB sessions will be reestablished automatically if the client resumes activity.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -82,45 +63,20 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Each SMB session consumes server resources, and numerous null sessions slow the server or possibly cause it to fail. An attacker could repeatedly establish SMB sessions until the server's SMB services become slow or unresponsive.
-
### Countermeasure
-
The default behavior on a server mitigates this threat by design.
-
### Potential impact
-
There is little impact because SMB sessions are reestablished automatically if the client computer resumes activity.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/microsoft-network-server-attempt-s4u2self-to-obtain-claim-information.md b/windows/keep-secure/microsoft-network-server-attempt-s4u2self-to-obtain-claim-information.md
index ce20b1229e..5a59300d6c 100644
--- a/windows/keep-secure/microsoft-network-server-attempt-s4u2self-to-obtain-claim-information.md
+++ b/windows/keep-secure/microsoft-network-server-attempt-s4u2self-to-obtain-claim-information.md
@@ -2,58 +2,34 @@
title: Microsoft network server Attempt S4U2Self to obtain claim information (Windows 10)
description: Describes the best practices, location, values, management, and security considerations for the Microsoft network server Attempt S4U2Self to obtain claim information security policy setting.
ms.assetid: e4508387-35ed-4a3f-a47c-27f8396adbba
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Microsoft network server: Attempt S4U2Self to obtain claim information
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, management, and security considerations for the **Microsoft network server: Attempt S4U2Self to obtain claim information** security policy setting.
-
## Reference
-
-
This security setting supports client devices running a version of Windows prior to Windows 8 that are trying to access a file share that requires user claims. This setting determines whether the local file server will attempt to use Kerberos Service-for-User-to-Self (S4U2Self) functionality to obtain a network client principal’s claims from the client’s account domain. This setting should only be enabled if the file server is using user claims to control access to files, and if the file server will support client principals whose accounts might be in a domain that has client computers and domain controllers running a version of Windows prior to Windows 8 or Windows Server 2012.
-
When enabled, this security setting causes the Windows file server to examine the access token of an authenticated network client principal and determines if claim information is present. If claims are not present, the file server will then use the Kerberos S4U2Self feature to attempt to contact a Windows Server 2012 domain controller in the client’s account domain and obtain a claims-enabled access token for the client principal. A claims-enabled token might be needed to access files or folders that have claim-based access control policy applied.
-
If this setting is disabled, the Windows file server will not attempt to obtain a claim-enabled access token for the client principal.
-
### Possible values
-
- **Default**
-
The Windows file server will examine the access token of an authenticated network client principal and determine if claim information is present.
-
- **Enabled**
-
Same as **Default**.
-
- **Disabled**
-
- **Not defined**
-
Same as **Disabled**.
-
### Best practices
-
This setting should be set to **Default** so that the file server can automatically evaluate whether claims are needed for the user. You should explicitly configure this setting to **Enabled** only if there are local file access policies that include user claims.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -92,49 +68,22 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Group Policy
-
This setting should only be enabled if the file server is using user claims to control access to files, and if the file server will support client principals whose accounts might be in a domain that has client computers and domain controllers running a version of Windows prior to Windows 8 or Windows Server 2012.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
None. Enabling this policy setting allows you take advantage of features in Windows Server 2012 and Windows 8 for specific scenarios to use claims-enabled tokens to access files or folders that have claim-based access control policy applied on Windows operating systems prior to Windows Server 2012 and Windows 8.
-
### Countermeasure
-
Not applicable.
-
### Potential impact
-
None.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/microsoft-network-server-digitally-sign-communications-always.md b/windows/keep-secure/microsoft-network-server-digitally-sign-communications-always.md
index 91004a814c..224f74984a 100644
--- a/windows/keep-secure/microsoft-network-server-digitally-sign-communications-always.md
+++ b/windows/keep-secure/microsoft-network-server-digitally-sign-communications-always.md
@@ -2,74 +2,42 @@
title: Microsoft network server Digitally sign communications (always) (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Microsoft network server Digitally sign communications (always) security policy setting.
ms.assetid: 2007b622-7bc2-44e8-9cf1-d34b62117ea8
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Microsoft network server: Digitally sign communications (always)
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **Microsoft network server: Digitally sign communications (always)** security policy setting.
-
## Reference
-
-
The Server Message Block (SMB) protocol provides the basis for file and print sharing and many other networking operations, such as remote Windows administration. To prevent man-in-the-middle attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets. This policy setting determines whether SMB packet signing must be negotiated before further communication with the Server service is permitted.
-
Implementation of digital signatures in high-security networks helps to prevent the impersonation of client computers and servers, which is known as "session hijacking." But misuse of these policy settings is a common error that can cause data loss or problems with data access or security.
-
For this policy to take effect on computers running Windows 2000, client-side packet signing must also be enabled. To enable client-side SMB packet signing, set [Microsoft network client: Digitally sign communications (if server agrees)](microsoft-network-client-digitally-sign-communications-if-server-agrees.md). Devices that have this policy set will not be able to communicate with devices that do not have server-side packet signing enabled. By default, server-side packet signing is enabled only on domain controllers. Server-side packet signing can be enabled on devices by setting [Microsoft network server: Digitally sign communications (if client agrees)](microsoft-network-server-digitally-sign-communications-if-client-agrees.md).
-
If server-side SMB signing is required, a client device will not be able to establish a session with that server, unless it has client-side SMB signing enabled. By default, client-side SMB signing is enabled on workstations, servers, and domain controllers. Similarly, if client-side SMB signing is required, that client device will not be able to establish a session with servers that do not have packet signing enabled. By default, server-side SMB signing is enabled only on domain controllers.
-
If server-side SMB signing is enabled, SMB packet signing will be negotiated with client devices that have SMB signing enabled.
-
Using SMB packet signing can impose up to a 15 percent performance degradation on file service transactions.
-
There are three other policy settings that relate to packet-signing requirements for Server Message Block (SMB) communications:
-
- [Microsoft network client: Digitally sign communications (always)](microsoft-network-client-digitally-sign-communications-always.md)
-
- [Microsoft network client: Digitally sign communications (if server agrees)](microsoft-network-client-digitally-sign-communications-if-server-agrees.md)
-
- [Microsoft network server: Digitally sign communications (if client agrees)](microsoft-network-server-digitally-sign-communications-if-client-agrees.md)
-
### Possible values
-
- Enabled
-
- Disabled
-
- Not defined
-
### Best practices
-
1. Configure the following security policy settings as follows:
-
- Disable [Microsoft network client: Digitally sign communications (always)](microsoft-network-client-digitally-sign-communications-always.md).
-
- Disable **Microsoft network server: Digitally sign communications (always)**.
-
- Enable [Microsoft network client: Digitally sign communications (if server agrees)](microsoft-network-client-digitally-sign-communications-if-server-agrees.md).
-
- Enable [Microsoft network server: Digitally sign communications (if client agrees)](microsoft-network-server-digitally-sign-communications-if-client-agrees.md).
-
2. Alternately, you can set all of these policy settings to Enabled, but enabling them can cause slower performance on client devices and prevent them from communicating with legacy SMB applications and operating systems.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -108,64 +76,30 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Session hijacking uses tools that allow attackers who have access to the same network as the client device or server to interrupt, end, or steal a session in progress. Attackers can potentially intercept and modify unsigned Server Message Block (SMB) packets and then modify the traffic and forward it so that the server might perform objectionable actions. Alternatively, the attacker could pose as the server or client device after legitimate authentication and gain unauthorized access to data.
-
SMB is the resource-sharing protocol that is supported by many Windows operating systems. It is the basis of NetBIOS and many other protocols. SMB signatures authenticate users and the servers that host the data. If either side fails the authentication process, data transmission does not take place.
-
### Countermeasure
-
Configure the settings as follows:
-
- Disable [Microsoft network client: Digitally sign communications (always)](microsoft-network-client-digitally-sign-communications-always.md).
-
- Disable **Microsoft network server: Digitally sign communications (always)**.
-
- Enable [Microsoft network client: Digitally sign communications (if server agrees)](microsoft-network-client-digitally-sign-communications-if-server-agrees.md).
-
- Enable [Microsoft network server: Digitally sign communications (if client agrees)](microsoft-network-server-digitally-sign-communications-if-client-agrees.md).
-
In highly secure environments we recommend that you configure all of these settings to Enabled. However, that configuration may cause slower performance on client devices and prevent communications with earlier SMB applications and operating systems.
-
**Note**
An alternative countermeasure that could protect all network traffic is to implement digital signatures with IPsec. There are hardware-based accelerators for IPsec encryption and signing that could be used to minimize the performance impact on the servers' CPUs. No such accelerators are available for SMB signing.
-
-
### Potential impact
-
Implementations of the SMB file and print-sharing protocol support mutual authentication. This prevents session hijacking attacks and supports message authentication to prevent man-in-the-middle attacks. SMB signing provides this authentication by placing a digital signature into each SMB, which is then verified by the client and the server.
-
Implementation of SMB signing may negatively affect performance because each packet must be signed and verified. If these settings are enabled on a server that is performing multiple roles, such as a small business server that is serving as a domain controller, file server, print server, and application server, performance may be substantially slowed. Additionally, if you configure computers to ignore all unsigned SMB communications, older applications and operating systems cannot connect. However, if you completely disable all SMB signing, devices are vulnerable to session-hijacking attacks.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/microsoft-network-server-digitally-sign-communications-if-client-agrees.md b/windows/keep-secure/microsoft-network-server-digitally-sign-communications-if-client-agrees.md
index 2a46117e2c..d63b5a83c1 100644
--- a/windows/keep-secure/microsoft-network-server-digitally-sign-communications-if-client-agrees.md
+++ b/windows/keep-secure/microsoft-network-server-digitally-sign-communications-if-client-agrees.md
@@ -2,72 +2,41 @@
title: Microsoft network server Digitally sign communications (if client agrees) (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Microsoft network server Digitally sign communications (if client agrees) security policy setting.
ms.assetid: c92b2e3d-1dbf-4337-a145-b17a585f4fc1
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Microsoft network server: Digitally sign communications (if client agrees)
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **Microsoft network server: Digitally sign communications (if client agrees)** security policy setting.
-
## Reference
-
-
The Server Message Block (SMB) protocol provides the basis for file and print sharing and many other networking operations, such as remote Windows administration. To prevent man-in-the-middle attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets. This policy setting determines whether SMB packet signing must be negotiated before further communication with the Server service is permitted.
-
Implementation of digital signatures in high-security networks helps to prevent the impersonation of client computers and servers, which is known as "session hijacking." But misuse of these policy settings is a common error that can cause data loss or problems with data access or security.
-
If server-side SMB signing is required, a client device will not be able to establish a session with that server, unless it has client-side SMB signing enabled. By default, client-side SMB signing is enabled on workstations, servers, and domain controllers. Similarly, if client-side SMB signing is required, that client device will not be able to establish a session with servers that do not have packet signing enabled. By default, server-side SMB signing is enabled only on domain controllers.
-
If server-side SMB signing is enabled, SMB packet signing will be negotiated with client computers that have SMB signing enabled.
-
Using SMB packet signing can impose up to a 15 percent performance degradation on file service transactions.
-
There are three other policy settings that relate to packet-signing requirements for Server Message Block (SMB) communications:
-
- [Microsoft network server: Digitally sign communications (always)](microsoft-network-server-digitally-sign-communications-always.md)
-
- [Microsoft network client: Digitally sign communications (if server agrees)](microsoft-network-client-digitally-sign-communications-if-server-agrees.md)
-
- [Microsoft network client: Digitally sign communications (always)](microsoft-network-client-digitally-sign-communications-always.md)
-
### Possible values
-
- Enabled
-
- Disabled
-
- Not defined
-
### Best practices
-
1. Configure the following security policy settings as follows:
-
- Disable [Microsoft network client: Digitally sign communications (always)](microsoft-network-client-digitally-sign-communications-always.md).
-
- Disable [Microsoft network server: Digitally sign communications (always)](microsoft-network-server-digitally-sign-communications-always.md).
-
- Enable [Microsoft network server: Digitally sign communications (always)](microsoft-network-server-digitally-sign-communications-always.md).
-
- Enable **Microsoft Network Server: Digitally Sign Communications (If Client Agrees)**.
-
2. Alternately, you can set all of these policy settings to Enabled, but enabling them can cause slower performance on client devices and prevent them from communicating with legacy SMB applications and operating systems.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -106,64 +75,30 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a computer restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Session hijacking uses tools that allow attackers who have access to the same network as the client device or server to interrupt, end, or steal a session in progress. Attackers can potentially intercept and modify unsigned Server Message Block (SMB) packets and then modify the traffic and forward it so that the server might perform objectionable actions. Alternatively, the attacker could pose as the server or client computer after legitimate authentication and gain unauthorized access to data.
-
SMB is the resource-sharing protocol that is supported by many Windows operating systems. It is the basis of NetBIOS and many other protocols. SMB signatures authenticate users and the servers that host the data. If either side fails the authentication process, data transmission does not take place.
-
### Countermeasure
-
Configure the settings as follows:
-
- Disable [Microsoft network client: Digitally sign communications (always)](microsoft-network-client-digitally-sign-communications-always.md).
-
- Disable [Microsoft network server: Digitally sign communications (always)](microsoft-network-server-digitally-sign-communications-always.md).
-
- Enable [Microsoft network client: Digitally sign communications (if server agrees)](microsoft-network-client-digitally-sign-communications-if-server-agrees.md).
-
- Enable **Microsoft network server: Digitally sign communications (if client agrees)**.
-
In highly secure environments we recommend that you configure all of these settings to Enabled. However, that configuration may cause slower performance on client devices and prevent communications with earlier SMB applications and operating systems.
-
**Note**
An alternative countermeasure that could protect all network traffic is to implement digital signatures with IPsec. There are hardware-based accelerators for IPsec encryption and signing that could be used to minimize the performance impact on the servers' CPUs. No such accelerators are available for SMB signing.
-
-
### Potential impact
-
SMB file and print-sharing protocol support mutual authentication. This prevents session hijacking attacks and supports message authentication to prevent man-in-the-middle attacks. SMB signing provides this authentication by placing a digital signature into each SMB, which is then verified by the client and the server.
-
Implementation of SMB signing may negatively affect performance because each packet must be signed and verified. If these settings are enabled on a server that is performing multiple roles, such as a small business server that is serving as a domain controller, file server, print server, and application server, performance may be substantially slowed. Additionally, if you configure computers to ignore all unsigned SMB communications, older applications and operating systems cannot connect. However, if you completely disable all SMB signing, computers are vulnerable to session-hijacking attacks.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/microsoft-network-server-disconnect-clients-when-logon-hours-expire.md b/windows/keep-secure/microsoft-network-server-disconnect-clients-when-logon-hours-expire.md
index 18b1bba108..054c5a3be3 100644
--- a/windows/keep-secure/microsoft-network-server-disconnect-clients-when-logon-hours-expire.md
+++ b/windows/keep-secure/microsoft-network-server-disconnect-clients-when-logon-hours-expire.md
@@ -2,50 +2,30 @@
title: Microsoft network server Disconnect clients when logon hours expire (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Microsoft network server Disconnect clients when logon hours expire security policy setting.
ms.assetid: 48b5c424-9ba8-416d-be7d-ccaabb3f49af
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Microsoft network server: Disconnect clients when logon hours expire
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **Microsoft network server: Disconnect clients when logon hours expire** security policy setting.
-
## Reference
-
-
This policy setting enables or disables the forced disconnection of users who are connected to the local device outside their user account's valid logon hours. It affects the SMB component. If you enable this policy setting, client computer sessions with the SMB service are forcibly disconnected when the client's logon hours expire. If you disable this policy setting, established client device sessions are maintained after the client device's logon hours expire.
-
### Possible values
-
- Enabled
-
Client device sessions with the SMB service are forcibly disconnected when the client device's logon hours expire. If logon hours are not used in your organization, enabling this policy setting will have no impact.
-
- Disabled
-
The system maintains an established client device session after the client device's logon hours have expired.
-
- Not defined
-
### Best practices
-
- If you enable this policy setting, you should also enable [Network security: Force logoff when logon hours expire](network-security-force-logoff-when-logon-hours-expire.md).
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -84,49 +64,22 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Group Policy
-
This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
If your organization configures logon hours for users, it makes sense to enable this policy setting. Otherwise, users who should not have access to network resources outside of their logon hours can continue to use those resources with sessions that were established during allowed hours.
-
### Countermeasure
-
Enable the **Microsoft network server: Disconnect clients when logon hours expire** setting.
-
### Potential impact
-
If logon hours are not used in your organization, this policy setting has no impact. If logon hours are used, existing user sessions are forcibly terminated when their logon hours expire.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/microsoft-network-server-server-spn-target-name-validation-level.md b/windows/keep-secure/microsoft-network-server-server-spn-target-name-validation-level.md
index b53e9c7660..1cd20cf6fd 100644
--- a/windows/keep-secure/microsoft-network-server-server-spn-target-name-validation-level.md
+++ b/windows/keep-secure/microsoft-network-server-server-spn-target-name-validation-level.md
@@ -2,63 +2,37 @@
title: Microsoft network server Server SPN target name validation level (Windows 10)
description: Describes the best practices, location, and values, policy management and security considerations for the Microsoft network server Server SPN target name validation level security policy setting.
ms.assetid: 18337f78-eb45-42fd-bdbd-f8cd02c3e154
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Microsoft network server: Server SPN target name validation level
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, and values, policy management and security considerations for the **Microsoft network server: Server SPN target name validation level** security policy setting.
-
## Reference
-
-
This policy setting controls the level of validation that a server with shared folders or printers performs on the service principal name (SPN) that is provided by the client device when the client device establishes a session by using the Server Message Block (SMB) protocol. The level of validation can help prevent a class of attacks against SMB services (referred to as SMB relay attacks). This setting affects both SMB1 and SMB2.
-
Servers that use SMB provide availability to their file systems and other resources, such as printers, to networked client devices. Most servers that use SMB validate user access to resources by using NT Domain authentication (NTLMv1 and NTLMv2) and the Kerberos protocol.
-
### Possible values
-
The options for validation levels are:
-
- **Off**
-
The SPN from a SMB client is not required or validated by the SMB server.
-
- **Accept if provided by client**
-
The SMB server will accept and validate the SPN provided by the SMB client and allow a session to be established if it matches the SMB server’s list of SPN’s. If the SPN does not match, the session request for that SMB client will be denied.
-
- **Required from client**
-
The SMB client must send a SPN name in session setup, and the SPN name provided must match the SMB server that is being requested to establish a connection. If no SPN is provided by the client device, or the SPN provided does not match, the session is denied.
-
The default setting is Off.
-
### Best practices
-
This setting affects the server SMB behavior, and its implementation should be carefully evaluated and tested to prevent disruptions to file and print serving capabilities.
-
**Note**
All Windows operating systems support a client-side SMB component and a server-side SMB component.
-
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -97,55 +71,25 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Policy conflict considerations
-
None.
-
### Group Policy
-
This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
This policy setting controls the level of validation that a server with shared folders or printers performs on the service principal name (SPN) that is provided by the client device when the client device establishes a session by using the SMB protocol. The level of validation can help prevent a class of attacks against SMB servers (referred to as SMB relay attacks). This setting will affect both SMB1 and SMB2.
-
### Countermeasure
-
For countermeasures that are appropriate to your environment, see **Possible values** above.
-
### Potential impact
-
All Windows operating systems support a client-side SMB component and a server-side SMB component. This setting affects the server SMB behavior, and its implementation should be carefully evaluated and tested to prevent disruptions to file and print serving capabilities.
-
Because the SMB protocol is widely deployed, setting the options to **Accept if provided by client** or **Required from client** will prevent some clients from successfully authenticating to some servers in your environment.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/microsoft-passport-and-password-changes.md b/windows/keep-secure/microsoft-passport-and-password-changes.md
index f099cdf2ac..4325261928 100644
--- a/windows/keep-secure/microsoft-passport-and-password-changes.md
+++ b/windows/keep-secure/microsoft-passport-and-password-changes.md
@@ -5,14 +5,12 @@ ms.assetid: 83005FE4-8899-47A6-BEA9-C17CCA0B6B55
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: jdeckerMS
---
-
# Microsoft Passport and password changes
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
@@ -20,36 +18,23 @@ When you set up Microsoft Passport, the PIN or biometric (Windows Hello) gesture
## Example
-
Let's suppose that you have set up a PIN for your Microsoft account on **Device A**. You use your PIN to sign in on **Device A** and then change the password for your Microsoft account.
-
Because you were using **Device A** when you changed your password, the PIN on **Device A** will continue to work with no other action on your part.
Suppose instead that you sign in on **Device B** and change your password for your Microsoft account. The next time that you try to sign in on **Device A** using your PIN, sign-in will fail because the account credentials that Passport on **Device A** knows will be outdated.
-
-**Note**
-This example also applies to an Active Directory account when [Passport for Work is not implemented](implement-microsoft-passport-in-your-organization.md).
-
+> **Note:** This example also applies to an Active Directory account when [Passport for Work is not implemented](implement-microsoft-passport-in-your-organization.md).
-
## How to update Passport after you change your password on another device
-
1. When you try to sign in using your PIN or biometric, you will see the following message: **Your password was changed on a different device. You must sign in to this device once with your new password, and then you can sign in with your PIN.**
-
2. Click **OK.**
-
3. Click **Sign-in options**.
-
4. Click the **Password** button.
-
5. Sign in with new password.
-
6. The next time that you sign in, you can select **Sign-in options** and then select **PIN** to resume using your PIN.
## Related topics
-
[Manage identity verification using Microsoft Passport](manage-identity-verification-using-microsoft-passport.md)
[Implement Microsoft Passport in your organization](implement-microsoft-passport-in-your-organization.md)
@@ -60,13 +45,6 @@ This example also applies to an Active Directory account when [Passport for Work
[Microsoft Passport errors during PIN creation](microsoft-passport-errors-during-pin-creation.md)
+
[Event ID 300 - Passport successfully created](passport-event-300.md)
-
-
-
-
-
-
-
-
-
+
\ No newline at end of file
diff --git a/windows/keep-secure/microsoft-passport-errors-during-pin-creation.md b/windows/keep-secure/microsoft-passport-errors-during-pin-creation.md
index ec41aa5d9a..a9483a0b56 100644
--- a/windows/keep-secure/microsoft-passport-errors-during-pin-creation.md
+++ b/windows/keep-secure/microsoft-passport-errors-during-pin-creation.md
@@ -2,18 +2,17 @@
title: Microsoft Passport errors during PIN creation (Windows 10)
description: When you set up Microsoft Passport in Windows 10, you may get an error during the Create a work PIN step.
ms.assetid: DFEFE22C-4FEF-4FD9-BFC4-9B419C339502
-keywords: ["PIN", "error", "create a work PIN"]
+keywords: PIN, error, create a work PIN
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: jdeckerMS
---
# Microsoft Passport errors during PIN creation
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
@@ -21,26 +20,18 @@ When you set up Microsoft Passport in Windows 10, you may get an error during t
## Where is the error code?
-
The following image shows an example of an error during **Create a work PIN**.
## Error mitigations
-
When a user encounters an error when creating the work PIN, advise the user to try the following steps. Many errors can be mitigated by one of these steps.
-
1. Try to create the PIN again. Some errors are transient and resolve themselves.
-
2. Sign out, sign in, and try to create the PIN again.
-
3. Reboot the device and then try to create the PIN again.
-
4. Unjoin the device from Azure Active Directory (Azure AD), rejoin, and then try to create the PIN again. To unjoin a desktop PC, go to **Settings** > **System** > **About** and select **Disconnect from organization**. To unjoin a device running Windows 10 Mobile, you must [reset the device](http://go.microsoft.com/fwlink/p/?LinkId=715697).
-
5. On mobile devices, if you are unable to setup a PIN after multiple attempts, reset your device and start over. For help on how to reset your phone go to [Reset my phone](http://go.microsoft.com/fwlink/p/?LinkId=715697).
-
If the error occurs again, check the error code against the following table to see if there is another mitigation for that error. When no mitigation is listed in the table, contact Microsoft Support for assistance.
@@ -201,12 +192,8 @@ If the error occurs again, check the error code against the following table to s
-
-
## Errors with unknown mitigation
-
-
For errors listed in this table, contact Microsoft Support for assistance.
| Hex | Cause |
@@ -230,12 +217,10 @@ For errors listed in this table, contact Microsoft Support for assistance.
| 0x801C03F0 | There is no key registered for the user |
| 0x801C03F1 | There is no UPN in the token |
| 0x801C044C | There is no core window for the current thread |
-
## Related topics
-
[Manage identity verification using Microsoft Passport](manage-identity-verification-using-microsoft-passport.md)
[Implement Microsoft Passport in your organization](implement-microsoft-passport-in-your-organization.md)
@@ -247,12 +232,3 @@ For errors listed in this table, contact Microsoft Support for assistance.
[Microsoft Passport and password changes](microsoft-passport-and-password-changes.md)
[Event ID 300 - Passport successfully created](passport-event-300.md)
-
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/microsoft-passport-guide.md b/windows/keep-secure/microsoft-passport-guide.md
index ab603ccb7a..70f6296988 100644
--- a/windows/keep-secure/microsoft-passport-guide.md
+++ b/windows/keep-secure/microsoft-passport-guide.md
@@ -2,19 +2,18 @@
title: Microsoft Passport guide (Windows 10)
description: This guide describes the new Windows Hello and Microsoft Passport technologies that are part of the Windows 10 operating system.
ms.assetid: 11EA7826-DA6B-4E5C-99FB-142CC6BD9E84
-keywords: ["security", "credential", "password", "authentication"]
+keywords: security, credential, password, authentication
ms.prod: W10
ms.pagetype: security
ms.mktglfcycl: plan
ms.sitesec: library
+ms.pagetype: security
author: challum
---
# Microsoft Passport guide
-
**Applies to**
-
- Windows 10
This guide describes the new Windows Hello and Microsoft Passport technologies that are part of the Windows 10 operating system. It highlights specific capabilities of these technologies that help mitigate threats from conventional credentials and provides guidance about how to design and deploy these technologies as part of your Windows 10 rollout.
@@ -23,7 +22,6 @@ A fundamental assumption about information security is that a system can identif
## Problems with traditional credentials
-
Ever since the mid-1960s, when Fernando Corbató and his team at the Massachusetts Institute of Technology championed the introduction of the password, users and administrators have had to deal with the use of passwords for user authentication and authorization. Over time, the state of the art for password storage and use has advanced somewhat (with password hashing and salt being the two most noticeable improvements), but we’re still faced with two serious problems: passwords are easy to clone and easy to steal. Implementation faults may render them insecure, and users have a hard time balancing convenience and security.
**Credential theft**
@@ -31,19 +29,15 @@ Ever since the mid-1960s, when Fernando Corbató and his team at the Massachuset
The biggest risk of passwords is simple: an attacker can steal them easily. Every place a password is entered, processed, or stored is vulnerable. For example, an attacker can steal a collection of passwords or hashes from an authentication server by eavesdropping on network traffic to an application server, by implanting malware in an application or on a device, by logging user keystrokes on a device, or by watching to see which characters a user types — and those are just the most common attack methods. One can enact more exotic attacks to steal one or many passwords.
The risk of theft is driven by the fact that the authentication factor the password represents is the password. Without additional authentication factors, the system assumes that anyone who knows the password is the authorized user.
-
Another, related risk is that of credential replay, in which an attacker captures a valid credential by eavesdropping on an insecure network, and then replays it later to impersonate a valid user. Most authentication protocols (including Kerberos and OAuth) protect against replay attacks by including a time stamp in the credential exchange process, but that protects the token that the authentication system issues, not the password that the user provides to get the ticket in the first place.
**Credential reuse**
-
-
The common approach of using an email address as the user name makes a bad problem worse. An attacker who successfully recovers a user name–password pair from a compromised system can then try that same pair on other systems. Surprisingly often, this tactic works to allow attackers to springboard from a compromised system into other systems. The use of email addresses as user names leads to other problems, too, which we’ll explore later in this guide.
###
**Trading convenience for complexity**
-
Most security is a tradeoff between convenience and security: the more secure a system is, the less convenient it will typically be for users. Although system designers and implementers have a broad range of tools to make their systems more secure, users get a vote, too. When users perceive that a security mechanism gets in the way of what they want to do, they often look for ways to circumvent it. This behavior leads to an arms race of sorts, with users adopting strategies to minimize the effort required to comply with their organization’s password policies as those policies evolve.
**Password complexity**
@@ -53,9 +47,7 @@ If the major risk to passwords is that an attacker might guess them through brut
**Password expiration**
Because a reusable password is the only authentication factor in password-based systems, designers have attempted to reduce the risk of credential theft and reuse. One common method for doing so is the use of limited-lifetime passwords. Some systems allow for passwords that can be used only once, but by far the more common approach is to make passwords expire after a certain period. Limiting the useful lifetime of a password puts a cap on how long a stolen password will be useful to an attacker. This practice helps protect against cases where a long-lived password is stolen, held, and used for a long time, but it also harkens back to the time when password cracking was impractical for everyone except nation state-level attackers. A smart attacker would attempt to steal passwords rather than crack them because of the time penalty associated with password cracking.
-
The widespread availability of commodity password-cracking tools and the massive computing power available through mechanisms such as GPU-powered crackers or distributed cloud-based cracking tools has reversed this equation so that it is often more effective for an attacker to crack a password than to try to steal it. In addition, the widespread availability of self-service [password-reset mechanisms](#password-reset) means that an attacker needs only a short window of time during which the password is valid to change the password and thus reset the validity period. Relatively few enterprise networks provide self-service password-reset mechanisms, but they are common for Internet services. In addition, many users use the secure credential store on Windows and Mac OS X systems to store valuable passwords for Internet services, so an attacker who can compromise the operating system password may be able to obtain a treasure trove of other service passwords at no cost.
-
Finally, overly short timelines for password expiration can tempt users to make small changes in their passwords at each expiration period — for example, moving from password123 to password456 to password789. This approach reduces the work necessary to crack the password, especially if the attacker knows any of the old passwords.
###
@@ -71,54 +63,38 @@ An insidious problem makes these design and implementation weaknesses worse: som
**Mitigate credential risks**
Given the issues described so far, it might seem obvious that reusable passwords are a security hazard. The argument is simple: adding authentication factors reduces the value of the passwords themselves, because even a successful password theft won’t let an attacker log on to a system unless he or she also has the associated additional factors. Unfortunately, this simple argument has many practical complications. Security and operating system vendors have tried to solve the problems that reusable credentials pose for decades — with limited success.
-
The most obvious mitigation to the risks reusable passwords pose is to add one or more authentication factors. At different times over the past 30 years, different vendors have attempted to solve this problem by calling for the use of biometric identifiers (including fingerprints, iris and retina scans, and hand geometry), software-based and hardware-based tokens, physical and virtual smart cards, and voice or Short Message Service (SMS) authentication through the user’s mobile phone. A detailed description of each of these authenticators and its pros and cons is outside the scope of this guide, but no matter which authentication method you choose, core challenges have limited adoption of all Multi-Factor Authentication (MFA) solutions, including:
-
- **Infrastructure complexity and cost.** Any system that requires the user to provide an additional authentication factor at the point of access has to have a way to collect that information. Although it’s possible to retrofit fielded hardware by adding fingerprint readers, eye scanners, smart card readers, and so on, few enterprises have been willing to take on the cost and support burden required to do so.
-
- **Lack of standardization.** Although Microsoft included operating system–level smart card support as part of the Windows Vista operating system, smart card and reader vendors were free to continue to ship their own drivers, as were manufacturers of other authentication devices. Lack of standardization led to both application and support fragmentation, which means that it wasn’t always possible to mix and match solutions within an enterprise, even when the manufacturers of those solutions advertised them as being compatible.
-
- **Backward compatibility.** Retrofitting already-deployed operating systems and applications to use MFA has proven an extremely difficult task. Nearly three years after its release, Microsoft Office 2013 is finally getting support for MFA. The vast majority of both commercial and custom line-of-business (LOB) applications will never be retrofitted to take advantage of any authentication system other than what the underlying operating system provides.
-
- **User inconvenience.** Solutions that require users to obtain, keep track of, and use physical tokens are often unpopular. If users have to have a particular token for remote access or other scenarios that are supposed to make things more convenient, they tend to become quickly dissatisfied with the burden of keeping up with an additional device. This pushback is multiplied for solutions that have to be attached to computers (such as smart card readers) because such solutions introduce problems of portability, driver support, and operating system and application integration.
-
-- **Device compatibility.** Not every hardware form factor supports every authentication method. For example, despite occasional feeble efforts from vendors, no market for mobile phone-compatible smart card readers ever emerged. So when Microsoft first implemented smart cards as an authenticator for remote network access, one key limitation was that employees could log on only from desktop or laptop computers that had smart card readers. Any authentication method that relies on additional hardware or software may run into this problem. For example, several popular “soft token” systems rely on mobile apps that run on a limited number of mobile hardware platforms.
-
+- **Device compatibility.** Not every hardware form factor supports every authentication method. For example, despite occasional feeble efforts from vendors, no market for mobile phone-compatible smart card readers ever emerged.
+So when Microsoft first implemented smart cards as an authenticator for remote network access, one key limitation was that employees could log on only from desktop or laptop computers that had smart card readers. Any authentication method that relies on additional hardware or software may run into this problem. For example, several popular “soft token” systems rely on mobile apps that run on a limited number of mobile hardware platforms.
Another pesky problem has to do with institutional knowledge and maturity. Strong authentication systems are complex. They have lots of components, and they can be expensive to design, maintain, and operate. For some enterprises, the additional cost and overhead of maintaining an in-house public key infrastructure (PKI) to issue smart cards or the burden of managing add-on devices exceeds the value they perceive in having stronger authentication. This is a special case of the common problem that financial institutions face: if the cost of fraud reduction is higher than the cost of the fraud itself, it’s hard to justify the economics of better fraud-prevention measures.
## Solve credential problems
-
Solving the problems that passwords pose is tricky. Tightening password policies alone won’t do it: users may just recycle, share, or write down passwords. Although user education is critical for authentication security, education alone doesn’t eliminate the problem, either.
As you’ve seen, additional authenticators won’t necessarily help if the new authentication systems add complexity, cost, or fragility. In Windows 10, Microsoft addresses these problems with two new technologies: Windows Hello and Microsoft Passport. Working together, these technologies help increase both security and user convenience:
-
- Microsoft Passport replaces passwords with strong two-factor authentication (2FA) by verifying existing credentials and by creating a device-specific credential that a user gesture (either biometric or PIN-based) protects. This combination effectively replaces physical and virtual smart cards as well as reusable passwords for logon and access control.
-
- Windows Hello provides reliable, fully integrated biometric authentication based on facial recognition or fingerprint matching. Windows Hello uses a combination of special infrared (IR) cameras and software to increase accuracy and guard against spoofing. Major hardware vendors are shipping devices that have integrated Windows Hello-compatible cameras, and fingerprint reader hardware can be used or added to devices that don’t currently have it. On devices that support Windows Hello, an easy biometric gesture unlocks users’ Microsoft Passport credentials.
## What is Windows Hello?
-
Windows Hello is the name Microsoft has given to the new biometric sign-in system built into Windows 10. Because it is built directly into the operating system, Windows Hello allows face or fingerprint identification to unlock users’ devices. Authentication happens when the user supplies his or her unique biometric identifier to access the device-specific Microsoft Passport credentials, which means that an attacker who steals the device can’t log on to it unless that attacker has the PIN. The Windows secure credential store protects biometric data on the device. By using Windows Hello to unlock a device, the authorized user gains access to all of his or her Windows experience, apps, data, websites, and services.
The Windows Hello authenticator is known as a Hello. A Hello is unique to the combination of an individual device and a specific user; it doesn’t roam among devices, isn’t shared with a server, and cannot easily be extracted from a device. If multiple users share a device, each user gets a unique Hello for that device. You can think of a Hello as a token you can use to unlock (or release) a stored credential: the Hello itself doesn’t authenticate you to an app or service, but it releases credentials that can.
At the launch of Windows 10, the operating system supported three Hello types:
-
- **PIN.** Before you can use Windows Hello to enable biometrics on a device, you must choose a PIN as your initial Hello gesture. After you’ve set a PIN, you can add biometric gestures if you want to. You can always use the PIN gesture to release your credentials, so you can still unlock and use your device even if you can’t use your preferred biometric because of an injury or because the sensor is unavailable or not working properly.
-
- **Facial recognition.** This type uses special cameras that see in IR light, which allows them to reliably tell the difference between a photograph or scan and a living person. Several vendors are shipping external cameras that incorporate this technology, and major laptop manufacturers are incorporating it into their devices, as well.
-
- **Fingerprint recognition.** This type uses a capacitive fingerprint sensor to scan your fingerprint. Fingerprint readers have been available for Windows computers for years, but the current generation of sensors is significantly more reliable and less error-prone. Most existing fingerprint readers (whether external or integrated into laptops or USB keyboards) work with Windows 10.
-
Biometric data used to implement these Hello gestures is stored securely on the local device only. It doesn’t roam and is never sent to external devices or servers. Because Windows Hello only stores biometric identification data on the device, there’s no single collection point an attacker can compromise to steal biometric data. Breaches that expose biometrics collected and stored for other uses (such as fingerprints collected and stored for law enforcement or background check purposes) don’t pose a significant threat: an attacker who steals biometrics literally has only a template of the identifier, and that template cannot easily be converted to a form that the attacker can present to a biometric sensor. The data path for Windows Hello-compatible sensors is resistant to tampering, too, which further reduces the chance that an attacker will be able to successfully inject faked biometric data. In addition, before an attacker can even attempt to inject data into the sensor pipeline, that attacker must gain physical access to the device — and an attacker who can do that can mount several other, less difficult attacks.
-
Windows Hello offers several major benefits. First, when combined with Microsoft Passport, it effectively solves the problems of credential theft and sharing. Because an attacker must obtain both the device and the selected biometric, it is much more difficult to gain access without the user’s knowledge. Second, the use of biometrics means that users benefit from having a simple authenticator that’s always with them: there’s nothing to forget, lose, or leave behind. Instead of worrying about memorizing long, complex passwords, users can take advantage of a convenient, secure method for signing in to all their Windows devices. Finally, in many cases, there’s nothing additional to deploy or manage to use Windows Hello (although Microsoft Passport may require additional deployment, as described later in this guide). Windows Hello support is built directly into the operating system, and users or enterprises can add compatible biometric devices to provide biometric gesture recognition, either as part of a coordinated rollout or as individual users or groups decide to add the necessary sensors. Windows Hello is part of Windows, so no additional deployment is required to start using it.
## What is Microsoft Passport?
-
Windows Hello provides a robust way for a device to recognize an individual user; that addresses the first part of the path between a user and a requested service or data item. After the device has recognized the user, however, it still must authenticate the user before deciding whether to grant access to a requested resource. Microsoft Passport provides strong 2FA, fully integrated into Windows, that replaces reusable passwords with the combination of a specific device and a Hello or PIN. Microsoft Passport isn’t just a replacement for traditional 2FA systems, though. It’s conceptually similar to smart cards: authentication is performed by using cryptographic primitives instead of string comparisons, and the user’s key material is secure inside tamper-resistant hardware. Microsoft Passport doesn’t require the extra infrastructure components required for smart card deployment, either. In particular, you don’t need a PKI if you don’t currently have one. Microsoft Passport combines the major advantage of smart cards — deployment flexibility for virtual smart cards and robust security for physical smart cards — without any of their drawbacks.
Microsoft Passport offers four significant advantages over the current state of Windows authentication: it’s more flexible, it’s based on industry standards, it’s an effective risk mitigator, and it’s ready for the enterprise. Let’s look at each of these advantages in more detail.
@@ -126,7 +102,6 @@ Microsoft Passport offers four significant advantages over the current state of
**It’s flexible**
Microsoft Passport offers unprecedented flexibility. Although the format and use of reusable passwords are fixed, Microsoft Passport gives both administrators and users options to manage authentication. First and foremost, Microsoft Passport works with both biometric identifiers and PINs, so users’ credentials are protected even on devices that don’t support biometrics. Users can even use their phone to release their credentials instead of a PIN or biometric gesture on the main device. Microsoft Passport seamlessly takes advantage of the hardware of the devices in use; as users upgrade to newer devices, Microsoft Passport is ready to use them, and organizations can upgrade existing devices by adding biometric sensors where appropriate.
-
Microsoft Passport offers flexibility in the datacenter, too. To deploy it, in some modes you must add Windows Server 2016 Technical Preview domain controllers to your Active Directory environment, but you don’t have to replace or remove your existing Active Directory servers — the servers required for Microsoft Passport build on and add capability to your existing infrastructure. You don’t have to change the domain or forest functional level, and you can either add on-premises servers or use Microsoft Azure Active Directory to deploy Microsoft Passport on your network. The choice of which users you should enable for Microsoft Passport use is completely up to you: you choose the policies and devices to support and which authentication factors you want users to have access to. This makes it easy to use Microsoft Passport to supplement existing smart card or token deployments by adding strong credential protection to users who don’t currently have it or to deploy Microsoft Passport in scenarios that call for extra protection for sensitive resources or systems (described in the [Design a Microsoft Passport deployment](#design) section).
**It’s standardized**
@@ -138,7 +113,6 @@ In 2013, Microsoft joined the FIDO Alliance. FIDO standards enable a universal f
**It’s effective**
Microsoft Passport effectively mitigates two major security risks. First, by eliminating the use of reusable passwords for logon, it reduces the risk that a user’s credential will be copied or reused. On devices that support the Trusted Platform Module (TPM) standard, user key material can be stored in the user device’s TPM, which makes it more difficult for an attacker to capture the key material and reuse it. For devices that lack TPM, Microsoft Passport can encrypt and store credential data in software, but administrators can disable this feature to force a “TPM or nothing” deployment.
-
Second, because Microsoft Passport doesn’t depend on a single, centralized server, the risk of compromise from a breach of that server is removed. Although an attacker could theoretically compromise a single device, there’s no single point of attack that an intruder can leverage to gain widespread access to the environment.
**It’s enterprise-ready**
@@ -147,48 +121,35 @@ Every edition of Windows 10 includes Microsoft Passport functionality for indiv
## How Microsoft Passport works
-
To use Microsoft Passport to sign in with an identity provider (IDP), a user needs a configured device, which means that the Microsoft Passport life cycle starts when you configure a device for Microsoft Passport use. When the device is set up, its user can use the device to authenticate to services. In this section, we explore how device registration works, what happens when a user requests authentication, how key material is stored and processed, and which servers and infrastructure components are involved in different parts of this process.
**Register a new user or device**
A goal of Microsoft Passport is to allow a user to open a brand-new device, securely join an organizational network to download and manage organizational data, and create a new Hello gesture to secure the device. Microsoft refers to the process of setting up a device for use with Microsoft Passport as registration.
-
-**Note**
-This is separate from the organizational configuration required to use Microsoft Passport with Active Directory or Azure AD; that configuration is discussed later in this guide. This configuration must be completed before users can begin to register.
-
+> **Note:** This is separate from the organizational configuration required to use Microsoft Passport with Active Directory or Azure AD; that configuration is discussed later in this guide. This configuration must be completed before users can begin to register.
-
The registration process works like this:
-
1. The user configures an account on the device.
-
This account can be a local account on the device, a domain account stored in the on-premises Active Directory domain, a Microsoft account, or an Azure AD account. For a new device, this step may be as simple as logging on with a Microsoft account. Logging on with a Microsoft account on a Windows 10 device automatically sets up Microsoft Passport on the device; users don’t have to do anything extra to enable it.
-
2. To log on using that account, the user has to enter the existing credentials for it.
-
The IDP that “owns” the account receives the credentials and authenticates the user. This IDP authentication may include the use of an existing second authentication factor, or proof. For example, a user who registers a new device by using an Azure AD account will have to provide an SMS-based proof that Azure AD sends.
-
3. When the user has provided the proof to the IDP, the user enables PIN authentication (Figure 1).
-
The PIN will be associated with this particular credential.
-
+
-
+
Figure 1. Set up a PIN in the **Account Settings** control panel item
-
+
When the user sets the PIN, it becomes usable immediately (Figure 2).
-
+
-
+
Figure 2. When set, the PIN is immediately usable
-
+
Remember that Microsoft Passport depends on pairing a device and a credential, so the PIN chosen is associated only with the combination of the active account and that specific device. The PIN must comply with whatever length and complexity policy the account administrator has configured; this policy is enforced on the device side. Other registration scenarios that Microsoft Passport supports are:
- A user who upgrades from the Windows 8.1 operating system will log on by using his or her existing enterprise password. That triggers MFA from the IDP side; after receiving and returning a proof, such as a text message or voice code, the IDP authenticates the user to the upgraded Windows 10 device, and the user can set his or her PIN.
-
- A user who typically uses a smart card to log on will be prompted to set up a PIN the first time he or she logs on to a Windows 10 device the user has not previously logged on to.
-
- A user who typically uses a virtual smart card to log on will be prompted to set up a PIN the first time he or she logs on to a Windows 10 device the user has not previously logged on to.
When the user has completed this process, Microsoft Passport generates a new public–private key pair on the device. The TPM generates and stores this private key; if the device doesn’t have a TPM, the private key is encrypted and stored in software. This initial key is referred to as the protector key. It’s associated only with a single gesture; in other words, if a user registers a PIN, a fingerprint, and a face on the same device, each of those gestures will have a unique protector key. The protector key securely wraps the authentication key for a specific container. Each container has only one authentication key, but there can be multiple copies of that key wrapped with different unique protector keys (each of which is associated with a unique gesture). Microsoft Passport also generates an administrative key that the user or administrator can use to reset credentials, when necessary. In addition to the protector key, TPM-enabled devices generate a block of data that contains attestations from the TPM.
@@ -200,7 +161,6 @@ At this point, the user has a PIN gesture defined on the device and an associate
You’ll often hear the term *container* used in reference to MDM solutions. Microsoft Passport uses the term, too, but in a slightly different way. Container in this context is shorthand for a logical grouping of key material or data. Windows 10 supports two containers: the default container holds user key material for personal accounts, including key material associated with the user’s Microsoft account or with other consumer identity providers, and the enterprise container holds credentials associated with a workplace or school account.
The enterprise container exists only on devices that have been registered with an organization; it contains key material for the enterprise IDP, such as on-premises Active Directory or Azure AD. The enterprise container contains only key data for Active Directory or Azure AD. If the enterprise container is present on a device, it’s unlocked separately from the default container, which maintains separation of data and access across personal and enterprise credentials and services. For example, a user who uses a biometric gesture to log on to a managed computer can separately unlock his or her personal container by entering a PIN when logging on to make a purchase from a website.
-
These containers are logically separate. Organizations don’t have any control over the credentials users store in the default container, and applications that authenticate against services in the default container can’t use credentials from the enterprise container. However, individual Windows applications can use the Microsoft Passport application programming interfaces (APIs) to request access to credentials as appropriate, so that both consumer and LOB applications can be enhanced to take advantage of Microsoft Passport.
It’s important to keep in mind that there are no physical containers on disk, in the registry, or elsewhere. Containers are logical units used to group related items. The keys, certificates, and credentials Microsoft Passport stores are protected without the creation of actual containers or folders.
@@ -214,17 +174,11 @@ Figure 3. Each logical container holds one or more sets of keys
Containers can contain several types of key material:
- An *authentication key*, which is always an asymmetric public–private key pair. This key pair is generated during registration. It must be unlocked each time it’s accessed, by using either the user’s PIN or a previously generated biometric gesture. The authentication key exists until the user resets the PIN, at which time a new key will be generated. When the new key is generated, all the key material that the old key previously protected must be decrypted and re-encrypted using the new key.
-
- *Virtual smart card keys* are generated when a virtual smart card is generated and stored securely in the container. They’re available whenever the user’s container is unlocked.
-
- *Secure/Multipurpose Internet Mail Extensions (S/MIME) keys and certificates*, which a certification authority (CA) generates. The keys associated with the user’s S/MIME certificate can be stored in a Microsoft Passport container so they’re available to the user whenever the container is unlocked.
-
- The *IDP key*. These keys can be either symmetric or asymmetric, depending on which IDP you use. A single container may contain zero or more IDP keys, with some restrictions (for example, the enterprise container can contain zero or one IDP keys). IDP keys are stored in the container as illustrated in Figure 3. For certificate-based Microsoft Passport for Work, when the container is unlocked, applications that require access to the IDP key or key pair can request access. IDP keys are used to sign or encrypt authentication requests or tokens sent from this machine to the IDP. IDP keys are typically long lived but could have a shorter lifetime than the authentication key.
-
Microsoft accounts, Active Directory accounts, and Azure AD accounts all require the use of asymmetric key pairs. The device generates public and private keys, registers the public key with the IDP (which stores it for later verification), and securely stores the private key. For enterprises, the IDP keys can be generated in two ways:
-
- The IDP key pair can be associated with an enterprise CA through the Windows Network Device Enrollment Service (NDES), described more fully in [Network Device Enrollment Service Guidance](http://go.microsoft.com/fwlink/p/?LinkId=733947). In this case, Microsoft Passport requests a new certificate with the same key as the certificate from the existing PKI. This option lets organizations that have an existing PKI continue to use it where appropriate. Given that many applications, such as popular virtual private network systems, require the use of certificates, when you deploy Microsoft Passport in this mode, it allows a faster transition away from user passwords while still preserving certificate-based functionality. This option also allows the enterprise to store additional certificates in the protected container.
-
- The IDP can generate the IDP key pair directly, which allows quick, lower-overhead deployment of Microsoft Passport in environments that don’t have or need a PKI.
**How keys are protected**
@@ -236,7 +190,6 @@ Whenever possible, Microsoft recommends the use of TPM hardware. The TPM protect
**Authentication**
When a user wants to access protected key material — perhaps to use an Internet site that requires a logon or to access protected resources on a corporate intranet — the authentication process begins with the user entering a PIN or biometric gesture to unlock the device, a process sometimes called *releasing the key*. Think of it like using a physical key to unlock a door: before you can unlock the door, you need to remove the key from your pocket or purse. On a personal device that’s connected to an organizational network, users will use their personal PIN or biometric to release the key; on a device joined to an on-premises or Azure AD domain, they will use the organizational PIN.
-
This process unlocks the protector key for the primary container on the device. When that container is unlocked, applications (and thus the user) can use whatever IDP keys reside inside the container.
These keys are used to sign requests that are sent to the IDP, requesting access to specified resources. It’s important to understand that although the keys are unlocked, applications cannot use them at will. Applications can use specific APIs to request operations that require key material for particular actions (for example, decrypt an email message or log on to a website). Access through these APIs doesn’t require explicit validation through a user gesture, and the key material isn’t exposed to the requesting application. Rather, the application asks for authentication, encryption, or decryption, and the Microsoft Passport layer handles the actual work and returns the results. Where appropriate, an application can request a forced authentication even on an unlocked device. Windows prompts the user to reenter the PIN or perform an authentication gesture, which adds an extra level of protection for sensitive data or actions. For example, you can configure the Windows Store to require reauthentication any time a user purchases an application, even though the same account and PIN or gesture were already used to unlock the device.
@@ -244,19 +197,12 @@ These keys are used to sign requests that are sent to the IDP, requesting access
The actual authentication process works like this:
1. The client sends an empty authentication request to the IDP. (This is merely for the handshake process.)
-
2. The IDP returns a challenge, known as a *nonce*.
-
3. The device signs the nonce with the appropriate private key.
-
4. The device returns the original nonce, the signed nonce, and the ID of the key used to sign the nonce.
-
5. The IDP fetches the public key that the key ID specified, uses it to verify the signature on the nonce, and verifies that the nonce the device returned matches the original.
-
6. If all the checks in step 5 succeed, the IDP returns two data items: a symmetric key, which is encrypted with the device’s public key, and a security token, which is encrypted with the symmetric key.
-
7. The device uses its private key to decrypt the symmetric key, and then uses that symmetric key to decrypt the token.
-
8. The device makes a normal authentication request for the original resource, presenting the token from the IDP as its proof of authentication.
When the IDP validates the signature, it is verifying that the request came from the specified user and device. The private key specific to the device signs the nonce, which allows the IDP to determine the identity of the requesting user and device so that it can apply policies for content access based on user, device type, or both together. For example, an IDP could allow access to one set of resources only from mobile devices and a different set from desktop devices.
@@ -266,20 +212,14 @@ Remote unlock, which is planned for a future release of Windows 10, builds on t
**The infrastructure**
Microsoft Passport depends on having compatible IDPs available to it. As of this writing, that means you have four deployment possibilities:
-
- Use an existing Windows-based PKI centered around Active Directory Certificate Services. This option requires additional infrastructure, including a way to issue certificates to devices. You can use NDES to register devices directly, Microsoft System Center Configuration Manager Technical Preview or later for on-premises environments, or Microsoft Intune where it’s available to manage mobile device participation in Microsoft Passport.
-
- You can configure Windows Server 2016 Technical Preview domain controllers to act as IDPs for Microsoft Passport. In this mode, the Windows Server 2016 Technical Preview domain controllers act as IDPs alongside any existing Windows Server 2008 R2 or later domain controllers. There is no requirement to replace all existing domain controllers, merely to introduce at least one Windows Server 2016 Technical Preview domain controller per Active Directory site and update the forest Active Directory Domain Services (AD DS) schema to Windows Server 2016 Technical Preview.
-
- The normal discovery mechanism that clients use to find domain controllers and global catalogs relies on Domain Name System (DNS) SRV records, but those records don’t contain version data. Windows 10 computers will query DNS for SRV records to find all available Active Directory servers, and then query each server to identify those that can act as Microsoft Passport IDPs. The number of authentication requests your users generate, where your users are located, and the design of your network all drive the number of Windows Server 2016 Technical Preview domain controllers required.
-
- Azure AD can act as an IDP either by itself or alongside an on-premises AD DS forest. Organizations that use Azure AD can register devices directly without having to join them to a local domain by using the capabilities the Azure AD Device Registration service provides.
-
In addition to the IDP, Microsoft Passport requires an MDM system. This system can be the cloud-based Intune if you use Azure AD, or an on-premises System Center Configuration Manager deployment that meets the system requirements described in the [Deployment requirements](#deployreq) section of this document.
## Design a Microsoft Passport for Work deployment
-
Microsoft Passport for Work is designed for integration with your existing and future directory infrastructure and device deployments, but this flexibility means there are many considerations to think about when you design your deployment. Some of these decisions are technical, while others are organizational or even political. In this section, we examine the key points where you have to make decisions about how to implement Microsoft Passport for Work. Remember, individual devices can use the individual version of Microsoft Passport without any infrastructure changes on your part. Microsoft Passport for Work allows you to control and centrally manage user authentication and device registration. To use the initial version of Microsoft Passport for Work, each device must have an Azure AD identity, so automatic registration of devices provides a means both to register new devices and to apply optional policies to manage Microsoft Passport for Work.
**One deployment strategy**
@@ -287,20 +227,15 @@ Microsoft Passport for Work is designed for integration with your existing and f
Different organizations will necessarily take different approaches to the deployment of Microsoft Passport depending on their capabilities and needs, but there is only one strategy: deploy Microsoft Passport for Work throughout the organization to get maximum protection for the maximum number of devices and resources. Organizations can take one of three basic routes to accomplish that strategy:
- Deploy Microsoft Passport for Work everywhere according to whatever device or user deployment strategy works best for the organization.
-
- Deploy Microsoft Passport for Work first to high-value or high-risk targets, by using conditional access policies to restrict access to key resources only to users who hold strong authentication credentials.
-
- Blend Microsoft Passport for Work into an existing multi-factor environment, using it as an additional form of strong authentication alongside physical or virtual smart cards.
**Deploy Microsoft Passport for Work everywhere**
In this approach, you deploy Microsoft Passport throughout the organization in a coordinated rollout. In some ways, this method is similar to any other desktop deployment project; the only real difference is that you must already have the Microsoft Passport infrastructure in place to support device registration before you can start using Microsoft Passport on Windows 10 devices.
-**Note**
-You can still upgrade to Windows 10 or add new Windows 10 devices without changing your infrastructure. You just can’t use Microsoft Passport for Work on a device until the device joins Azure AD and receives the appropriate policy.
-
+> **Note:** You can still upgrade to Windows 10 or add new Windows 10 devices without changing your infrastructure. You just can’t use Microsoft Passport for Work on a device until the device joins Azure AD and receives the appropriate policy.
-
The major benefit of this approach is that it provides uniform protection for all parts of the organization. Sophisticated attackers have shown a great deal of skill in breaching large organizations by identifying weak points in their security, including users and systems that don’t have high-value information but that can be exploited to get it. Applying consistent protection across every device that an attacker could use to access enterprise data is excellent protection against these types of attacks.
The downside to this approach is its complexity. Smaller organizations may find that managing the rollout of a new operating system across all devices is beyond the scope of their experience and capability. For these organizations, users can self-upgrade, and new users may end up with Windows 10 because they get new devices when they join. Larger organizations, especially those that are highly decentralized or have operations across many physical sites, may have more deployment knowledge and resources but face the challenge of coordinating rollout efforts across a larger user base and footprint.
@@ -320,7 +255,6 @@ One of the key design capabilities of Microsoft Passport for Work is that it sup
**Blend Microsoft Passport with your infrastructure**
Organizations that have already invested in smart cards, virtual smart cards, or token-based systems can still benefit from Microsoft Passport. Of those organizations, many use physical tokens and smart cards to protect only critical assets because of the expense and complexity of their deployment. Microsoft Passport offers a valuable complement to these systems because it protects users who currently rely on reusable credentials; protection of all users’ credentials is an important step toward blunting attacks that seek to leverage compromise of any credential into a widespread breach. This approach also gives you a great deal of flexibility in scheduling and deployment.
-
Some enterprises have deployed multi-use smart cards that provide building-access control, access to copiers or other office equipment, stored value for lunchroom purchases, remote network access, and other services. Deployment of Microsoft Passport in such environments doesn’t prevent you from continuing to use smart cards for these services. You can leave the existing smart card infrastructure in place for its existing use cases, and then register desktop and mobile devices in Microsoft Passport and use Microsoft Passport to secure access to network and Internet resources. This approach requires a more complicated infrastructure and a greater degree of organizational maturity because it requires you to link your existing PKI with an enrollment service and Microsoft Passport itself.
Smart cards can act as a useful complement to Microsoft Passport in another important way: to bootstrap the initial logon for Microsoft Passport registration. When a user registers with Microsoft Passport on a device, part of that registration process requires a conventional logon. Rather than using a traditional password, organizations that have previously deployed the necessary infrastructure for smart cards or virtual smart cards can allow their users to register new devices by logging on with a smart card or virtual smart card. After the user has proved his or her identity to the organizational IDP with the smart card, the user can set up a PIN and proceed to use Microsoft Passport for future logons.
@@ -330,13 +264,9 @@ Smart cards can act as a useful complement to Microsoft Passport in another impo
Which rollout method you choose depends on several factors:
- **How many devices you need to deploy.** This number has a huge influence on your overall deployment. A global rollout for 75,000 users has different requirements than a phased rollout for groups of 200–300 users in different cities.
-
- **How quickly you want to deploy Microsoft Passport for Work protection.** This is a classic cost–benefit tradeoff. You have to balance the security benefits of Microsoft Passport for Work against the cost and time required to deploy it broadly, and different organizations may make entirely different decisions depending on how they rate the costs and benefits involved. Getting the broadest possible Microsoft Passport coverage in the shortest time possible maximizes security benefits.
-
- **The type of devices you want to deploy.** Windows device manufacturers are aggressively introducing new devices optimized for Windows 10, leading to the possibility that you might deploy Microsoft Passport first on newly purchased tablets and portable devices, and then deploy it on the desktop as part of your normal refresh cycle.
-
- **What your current infrastructure looks like.** The individual version of Microsoft Passport doesn’t require changes to your Active Directory environment, but to support Microsoft Passport for Work, you may need a compatible MDM system. Depending on the size and composition of your network, mobile enrollment and management services deployment may be a major project in its own right.
-
- **Your plans for the cloud.** If you’re already planning a move to the cloud, Azure AD eases the process of Microsoft Passport for Work deployment, because you can use Azure AD as an IDP alongside your existing on-premises AD DS setup without making significant changes to your on-premises environment. Future versions of Microsoft Passport for Work will support the ability to simultaneously register devices that are already members of an on-premises AD DS domain in an Azure AD partition so that they use Microsoft Passport for Work from the cloud. Hybrid deployments that combine AD DS with Azure AD give you the ability to keep machine authentication and policy management against your local AD DS domain while providing the full set of Microsoft Passport for Work services (and Microsoft Office 365 integration) for your users. If you plan to use on-premises AD DS only, then the design and configuration of your on-premises environment will dictate what kind of changes you may need to make.
###
@@ -348,13 +278,9 @@ Table 1 lists six scenarios for deployment of Microsoft Passport for Work in the
Depending on the scenario you choose, Microsoft Passport for Work deployment may require four elements:
- An organizational IDP that supports Microsoft Passport. This can be Azure AD or a set of on-premises Windows Server 2016 Technical Preview domain controllers in an existing AD DS forest. Using Azure AD means that you can establish hybrid identity management, with Azure AD acting as a Microsoft Passport IDP and your on-premises AD DS environment handling older authentication requests. This approach provides all the flexibility of Azure AD with the ability to manage computer accounts and devices running older versions of Windows and on-premises applications such as Microsoft Exchange Server or Microsoft SharePoint.
-
- If you use certificates, an MDM system is required to allow policy management of Microsoft Passport for Work. Domain-joined devices in on-premises or hybrid deployments require Configuration Manager Technical Preview or later. Deployments with Azure AD must use either Intune or a compatible non-Microsoft MDM solution.
-
- On-premises deployments require the forthcoming Active Directory Federation Services (AD FS) version included in Windows Server 2016 Technical Preview to support provisioning of Microsoft Passport credentials to devices. In this scenario, AD FS takes the place of the provisioning that Azure AD performs in cloud-based deployments.
-
- Certificate-based Microsoft Passport deployments require a PKI, including CAs that are accessible to all devices that need to register. If you deploy certificate-based Microsoft Passport on premises, you don’t actually need Windows Server 2016 Technical Preview domain controllers. On-premises deployments do need to apply the Windows Server 2016 Technical Preview AD DS schema and have the Windows Server 2016 Technical Preview version of AD FS installed.
-
Table 1. Deployment requirements for Microsoft Passport
@@ -403,9 +329,7 @@ Table 1. Deployment requirements for Microsoft Passport
-
-
Note that the current release of Windows 10 supports the Azure AD–only (RTM) and hybrid scenarios (RTM + November Update). Microsoft provides the forward-looking guidance in Table 1 to help organizations prepare their environments for planned future releases of Microsoft Passport for Work capabilities.
**Select policy settings**
@@ -414,58 +338,50 @@ Another key aspect of Microsoft Passport for Work deployment involves the choice
## Implement Microsoft Passport
-
No configuration is necessary to use Windows Hello or Microsoft Passport on individual user devices if those users just want to protect their personal credentials. Unless the enterprise disables the feature, users have the option to use Microsoft Passport for their personal credentials, even on devices that are registered with an organizational IDP. However, when you make Microsoft Passport for Work available for users, you must add the necessary components to your infrastructure, as described earlier in the [Deployment requirements](#deployreq) section.
**How to use Azure AD**
There are three scenarios for using Microsoft Passport for Work in Azure AD–only organizations:
-
- **Organizations that use the version of Azure AD included with Office 365.** For these organizations, no additional work is necessary. When Windows 10 was released to general availability, Microsoft changed the behavior of the Office 365 Azure AD stack. When a user selects the option to join a work or school network (Figure 4), the device is automatically joined to the Office 365 tenant’s directory partition, a certificate is issued for the device, and it becomes eligible for Office 365 MDM if the tenant has subscribed to that feature. In addition, the user will be prompted to log on and, if MFA is enabled, to enter an MFA proof that Azure AD sends to his or her phone.
-
- **Organizations that use the free tier of Azure AD.** For these organizations, Microsoft has not enabled automatic domain join to Azure AD. Organizations that have signed up for the free tier have the option to enable or disable this feature, so automatic domain join won’t be enabled unless and until the organization’s administrators decide to enable it. When that feature is enabled, devices that join the Azure AD domain by using the **Connect to work or school** dialog box shown in Figure 4 will be automatically registered with Microsoft Passport for Work support, but previously joined devices will not be registered.
-
- **Organizations that have subscribed to Azure AD Premium have access to the full set of Azure AD MDM features.** These features include controls to manage Microsoft Passport for Work. You can set policies to disable or force the use of Microsoft Passport for Work, require the use of a TPM, and control the length and strength of PINs set on the device.
-
+
Figure 4: Joining an Office 365 organization automatically registers the device in Azure AD
-
+
**Enable device registration**
If you want to use Microsoft Passport at Work with certificates, you’ll need a device registration system. That means that you set up Configuration Manager Technical Preview, Intune, or a compatible non-Microsoft MDM system and enable it to enroll devices. This is a prerequisite step to use Microsoft Passport for Work with certificates, no matter the IDP, because the enrollment system is responsible for provisioning the devices with the necessary certificates.
-
**Set Microsoft Passport policies**
As of the initial release of Windows 10, you can control the following settings for the use of Microsoft Passport for Work:
-
- You can require that Microsoft Passport be available only on devices that have TPM security hardware, which means the device uses TPM 1.2 or TPM 2.0.
-
- You can enable Microsoft Passport with a hardware-preferred option, which means that keys will be generated on TPM 1.2 or TPM 2.0 when available and by software when TPM is not available.
-
- You can configure whether certificate-based Microsoft Passport is available to users. You do this as part of the device deployment process, not through a separately applied policy.
-
- You can define the complexity and length of the PIN that users generate at registration.
-
- You can control whether Windows Hello use is enabled in your organization.
These settings can be implemented through GPOs or through configuration service providers (CSPs) in MDM systems, so you have a familiar and flexible set of tools you can use to apply them to exactly the users you want. (For details about the Microsoft Passport for Work CSP, see [PassportForWork CSP)](http://go.microsoft.com/fwlink/p/?LinkId=733876).
## Roadmap
-
The speed at which Universal Windows apps and services evolve means that the traditional design-build-test-release cycle for Windows is too slow to meet customers’ needs. As part of the release of Windows 10, Microsoft is changing how it engineers, tests, and distributes Windows. Rather than large, monolithic releases every 3–5 years, the Windows engineering team is committed to smaller, more frequent releases to get new features and services into the marketplace more rapidly without sacrificing security, quality, or usability. This model has worked well in Office 365 and the Xbox ecosystem.
In the Windows 10 initial release, Microsoft supports the following Microsoft Passport and Windows Hello features:
- Biometric authentication, with fingerprint readers that use the Windows fingerprint reader framework
-
- Facial-recognition capability on devices that have compatible IR-capable cameras
-
- Microsoft Passport for personal credentials on individually owned and corporate-managed devices
-
- Microsoft Passport for Work support for organizations that have cloud-only Azure AD deployments
+- Group Policy settings to control Microsoft Passport PIN length and complexity
+In future releases of Windows 10, we plan to add support for additional features:
+- Additional biometric identifier types, including iris recognition
+- Key-based Microsoft Passport for Work credentials for on-premises Azure AD deployments and hybrid on-premises/Azure AD deployments
+- Microsoft Passport for Work certificates issued by a trusted PKI, including smart card and virtual smart card certificates
+- TPM attestation to protect keys so that a malicious user or program can’t create keys in software (because those keys won’t be TPM attested and can thus be identified as fake)
- Group Policy and MDM settings to control Microsoft Passport PIN length and complexity
In the November 2015 release, Microsoft supports the following Microsoft Passport and Windows Hello features:
@@ -481,12 +397,5 @@ In future releases of Windows 10, we plan to add support for additional feature
- TPM attestation to protect keys so that a malicious user or program can’t create keys in software (because those keys won’t be TPM attested and can thus be identified as fake)
In the longer term, Microsoft will continue to improve on and expand the features of both Microsoft Passport and Windows Hello to cover additional customer requirements for manageability and security. We also are working with the FIDO Alliance and a variety of third parties to encourage adoption of Microsoft Passport by both web and LOB application developers.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/minimum-password-age.md b/windows/keep-secure/minimum-password-age.md
index e3b03a77c1..e132b39e0f 100644
--- a/windows/keep-secure/minimum-password-age.md
+++ b/windows/keep-secure/minimum-password-age.md
@@ -2,46 +2,28 @@
title: Minimum password age (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Minimum password age security policy setting.
ms.assetid: 91915cb2-1b3f-4fb7-afa0-d03df95e8161
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Minimum password age
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Minimum password age** security policy setting.
-
## Reference
-
-
The **Minimum password age** policy setting determines the period of time (in days) that a password can be used before the system requires the user to change it. You can set passwords to expire after a number of days between 1 and 999, or you can specify that passwords never expire by setting the number of days to 0. If [Maximum password age](maximum-password-age.md) is between 1 and 999 days, the minimum password age must be less than the maximum password age. If Maximum password age is set to 0, **Minimum password age** can be any value between 0 and 998 days.
-
### Possible values
-
- User-specified number of days between 0 and 998
-
- Not defined
-
### Best practices
-
Set **Minimum password age** to a value of 2 days. Setting the number of days to 0 allows immediate password changes, which is not recommended.
-
If you set a password for a user and you want that user to change the administrator-defined password, you must select the **User must change password at next logon** check box. Otherwise, the user will not be able to change the password until the number of days specified by **Minimum password age**.
-
### Location
-
**Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Password Policy**
-
### Default values
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -80,47 +62,21 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a computer restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Users may have favorite passwords that they like to use because they are easy to remember and they believe that their password choice is secure from compromise. Unfortunately, passwords can be compromised and if an attacker is targeting a specific individual user account, with knowledge of data about that user, reuse of old passwords can cause a security breach.
-
To address password reuse, you must use a combination of security settings. Using this policy setting with the [Enforce password history](enforce-password-history.md) policy setting prevents the easy reuse of old passwords. For example, if you configure the Enforce password history policy setting to ensure that users cannot reuse any of their last 12 passwords, but you do not configure the **Minimum password age** policy setting to a number that is greater than 0, users could change their password 13 times in a few minutes and reuse their original password. You must configure this policy setting to a number that is greater than 0 for the Enforce password history policy setting to be effective.
-
### Countermeasure
-
Configure the **Minimum password age** policy setting to a value of at least 2 days. Users should know about this limitation and contact the Help Desk if they need to change their password during that two-day period. If you configure the number of days to 0, immediate password changes would be allowed, which we do not recommend.
-
### Potential impact
-
If you set a password for a user but wants that user to change the password when the user first logs on, the administrator must select the **User must change password at next logon** check box, or the user cannot change the password until the next day.
-
## Related topics
-
-
[Password Policy](password-policy.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/minimum-password-length.md b/windows/keep-secure/minimum-password-length.md
index 903f9b16ae..30bd818de2 100644
--- a/windows/keep-secure/minimum-password-length.md
+++ b/windows/keep-secure/minimum-password-length.md
@@ -2,48 +2,29 @@
title: Minimum password length (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Minimum password length security policy setting.
ms.assetid: 3d22eb9a-859a-4b6f-82f5-c270c427e17e
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Minimum password length
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Minimum password length** security policy setting.
-
## Reference
-
-
The **Minimum password length** policy setting determines the least number of characters that can make up a password for a user account. You can set a value of between 1 and 14 characters, or you can establish that no password is required by setting the number of characters to 0.
-
### Possible values
-
- User-specified number of characters between 0 and 14
-
- Not defined
-
### Best practices
-
Set Minimum password length to at least a value of 8. If the number of characters is set to 0, no password is required. In most environments, an eight-character password is recommended because it is long enough to provide adequate security and still short enough for users to easily remember. This value will help provide adequate defense against a brute force attack. Adding complexity requirements will help reduce the possibility of a dictionary attack. For more info, see [Password must meet complexity requirements](password-must-meet-complexity-requirements.md).
-
Permitting short passwords reduces security because short passwords can be easily broken with tools that perform dictionary or brute force attacks against the passwords. Requiring very long passwords can result in mistyped passwords that might cause an account lockout and subsequently increase the volume of Help Desk calls.
-
In addition, requiring extremely long passwords can actually decrease the security of an organization because users might be more likely to write down their passwords to avoid forgetting them. However, if users are taught that they can use passphrases (sentences such as "I want to drink a $5 milkshake"), they should be much more likely to remember.
-
### Location
-
**Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Password Policy**
-
### Default values
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -82,52 +63,24 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Types of password attacks include dictionary attacks (which attempt to use common words and phrases) and brute force attacks (which try every possible combination of characters). Also, attackers sometimes try to obtain the account database so they can use tools to discover the accounts and passwords.
-
### Countermeasure
-
Configure the **** policy setting to a value of 8 or more. If the number of characters is set to 0, no password will be required.
-
In most environments, we recommend an eight-character password because it is long enough to provide adequate security, but not too difficult for users to easily remember. This configuration provides adequate defense against a brute force attack. Using the [Password must meet complexity requirements](password-must-meet-complexity-requirements.md) policy setting in addition to the **Minimum password length** setting helps reduce the possibility of a dictionary attack.
-
**Note**
Some jurisdictions have established legal requirements for password length as part of establishing security regulations.
-
-
### Potential impact
-
Requirements for extremely long passwords can actually decrease the security of an organization because users might leave the information in an unsecured location or lose it. If very long passwords are required, mistyped passwords could cause account lockouts and increase the volume of Help Desk calls. If your organization has issues with forgotten passwords due to password length requirements, consider teaching your users about passphrases, which are often easier to remember and, due to the larger number of character combinations, much harder to discover.
-
## Related topics
-
-
[Password Policy](password-policy.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/modify-an-object-label.md b/windows/keep-secure/modify-an-object-label.md
index 4fbd65119c..4f06c8a9e8 100644
--- a/windows/keep-secure/modify-an-object-label.md
+++ b/windows/keep-secure/modify-an-object-label.md
@@ -2,62 +2,36 @@
title: Modify an object label (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Modify an object label security policy setting.
ms.assetid: 3e5a97dd-d363-43a8-ae80-452e866ebfd5
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Modify an object label
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Modify an object label** security policy setting.
-
## Reference
-
-
This privilege determines which user accounts can modify the integrity label of objects, such as files, registry keys, or processes owned by other users. Processes running under a user account can modify the label of an object owned by that user to a lower level without this privilege.
-
The integrity label is used by the Windows Integrity Controls (WIC) feature, which was introduced in Windows Server 2008 and Windows Vista. WIC keeps lower integrity processes from modifying higher integrity processes by assigning one of six possible labels to objects on the system. Although similar to NTFS file and folder permissions, which are discretionary controls on objects, the WIC integrity levels are mandatory controls that are put in place and enforced by the operating system. The following list describes the integrity levels from lowest to highest:
-
- **Untrusted** Default assignment for processes that are logged on anonymously.
-
- **Low** Default assignment for processes that interact with the Internet.
-
- **Medium** Default assignment for standard user accounts and any object that is not explicitly designated with a lower or higher integrity level.
-
- **High** Default assignment for administrator accounts and processes that request to run using administrative rights.
-
- **System** Default assignment for Windows kernel and core services.
-
- **Installer** Used by setup programs to install software. It is important that only trusted software is installed on computers because objects that are assigned the Installer integrity level can install, modify, and uninstall all other objects.
-
Constant: SeRelabelPrivilege
-
### Possible values
-
- User-defined list of accounts
-
- Not Defined
-
### Best practices
-
- Do not give any group this user right.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
By default this setting is Not defined on domain controllers and on stand-alone servers.
-
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
-
@@ -96,61 +70,28 @@ The following table lists the actual and effective default policy values for the
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
A restart of the computer is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
### Group Policy
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Anyone with the **Modify an object label** user right can change the integrity level of a file or process so that it becomes elevated or decreased to a point where it can be deleted by lower integrity processes. Either of these states effectively circumvents the protection that is offered by Windows Integrity Controls and makes your system vulnerable to attacks by malicious software.
-
If malicious software is set with an elevated integrity level such as Trusted Installer or System, administrator accounts do not have sufficient integrity levels to delete the program from the system. In that case, use of the **Modify an object label** right is mandated so that the object can be re-labeled. However, the re-labeling must occur by using a process that is at the same or a higher level of integrity than the object that you are attempting to re-label.
-
### Countermeasure
-
Do not give any group this right. If necessary, implement it for a constrained period of time to a trusted individual to respond to a specific organizational need.
-
### Potential impact
-
None. Not defined is the default configuration.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/modify-firmware-environment-values.md b/windows/keep-secure/modify-firmware-environment-values.md
index b3679b1056..8662f8166e 100644
--- a/windows/keep-secure/modify-firmware-environment-values.md
+++ b/windows/keep-secure/modify-firmware-environment-values.md
@@ -2,58 +2,34 @@
title: Modify firmware environment values (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Modify firmware environment values security policy setting.
ms.assetid: 80bad5c4-d9eb-4e3a-a5dc-dcb742b83fca
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Modify firmware environment values
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Modify firmware environment values** security policy setting.
-
## Reference
-
-
This security setting determines who can modify firmware environment values. Firmware environment values are settings that are stored in the nonvolatile RAM of non-x86-based computers. The effect of the setting depends on the processor.
-
On x86-based computers, the only firmware environment value that can be modified by assigning this user right is the **Last Known Good Configuration** setting, which should only be modified by the system.
-
On Itanium-based computers, boot information is stored in nonvolatile RAM. Users must be assigned this user right to run bootcfg.exe and to change the **Default Operating System** setting using the **Startup and Recovery** feature on the **Advanced** tab of **System Properties**.
-
The exact setting for firmware environment values is determined by the boot firmware. The location of these values is also specified by the firmware. For example, on a UEFI-based system, NVRAM contains firmware environment values that specify system boot settings.
-
On all computers, this user right is required to install or upgrade Windows.
-
Constant: SeSystemEnvironmentPrivilege
-
### Possible values
-
- User-defined list of accounts
-
- Administrators
-
- Not Defined
-
### Best practices
-
- Ensure that only the local Administrators group is assigned the **Modify firmware environment values** user right.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
By default this setting is Administrators on domain controllers and on stand-alone servers.
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -92,61 +68,28 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
A restart of the device is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
This security setting does not affect who can modify the system environment values and user environment values that are displayed on the **Advanced** tab of **System Properties**.
-
### Group Policy
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Anyone who is assigned the **Modify firmware environment values** user right could configure the settings of a hardware component to cause it to fail, which could lead to data corruption or a denial-of-service condition.
-
### Countermeasure
-
Ensure that only the local Administrators group is assigned the **Modify firmware environment values** user right.
-
### Potential impact
-
None. Restricting the **Modify firmware environment values** user right to the members of the local Administrators group is the default configuration.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/monitor-application-usage-with-applocker.md b/windows/keep-secure/monitor-application-usage-with-applocker.md
index 2343d692f3..4a0e489d50 100644
--- a/windows/keep-secure/monitor-application-usage-with-applocker.md
+++ b/windows/keep-secure/monitor-application-usage-with-applocker.md
@@ -2,98 +2,51 @@
title: Monitor app usage with AppLocker (Windows 10)
description: This topic for IT professionals describes how to monitor app usage when AppLocker policies are applied.
ms.assetid: 0516da6e-ebe4-45b4-a97b-31daba96d1cf
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Monitor app usage with AppLocker
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals describes how to monitor app usage when AppLocker policies are applied.
-
Once you set rules and deploy the AppLocker policies, it is good practice to determine if the policy implementation is what you expected.
-
### Discover the effect of an AppLocker policy
-
You can evaluate how the AppLocker policy is currently implemented for documentation or audit purposes, or before you modify the policy. Updating your AppLocker Policy Deployment Planning document will help you track your findings. For information about creating this document, see [Create your AppLocker planning document](create-your-applocker-planning-document.md). You can perform one or more of the following steps to understand what application controls are currently enforced through AppLocker rules.
-
- **Analyze the AppLocker logs in Event Viewer**
-
When AppLocker policy enforcement is set to **Enforce rules**, rules are enforced for the rule collection and all events are audited. When AppLocker policy enforcement is set to **Audit only**, rules are not enforced but are still evaluated to generate audit event data that is written to the AppLocker logs.
-
For the procedure to access the log, see [View the AppLocker Log in Event Viewer](#bkmk-applkr-view-log).
-
- **Enable the Audit only AppLocker enforcement setting**
-
By using the **Audit only** enforcement setting, you can ensure that the AppLocker rules are properly configured for your organization. When AppLocker policy enforcement is set to **Audit only**, rules are only evaluated but all events generated from that evaluation are written to the AppLocker log.
-
For the procedure to do this, see [Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md).
-
- **Review AppLocker events with Get-AppLockerFileInformation**
-
For both event subscriptions and local events, you can use the **Get-AppLockerFileInformation** Windows PowerShell cmdlet to determine which files have been blocked or would have been blocked (if you are using the audit-only enforcement mode) and how many times the event has occurred for each file.
-
For the procedure to do this, see [Review AppLocker Events with Get-AppLockerFileInformation](#bkmk-applkr-review-events).
-
- **Review AppLocker events with Test-AppLockerPolicy**
-
You can use the **Test-AppLockerPolicy** Windows PowerShell cmdlet to determine whether any of the rules in your rule collections will be blocked on your reference device or the device on which you maintain policies.
-
For the procedure to do this, see [Test an AppLocker policy by using Test-AppLockerPolicy](test-an-applocker-policy-by-using-test-applockerpolicy.md).
-
### Review AppLocker events with Get-AppLockerFileInformation
-
For both event subscriptions and local events, you can use the **Get-AppLockerFileInformation** Windows PowerShell cmdlet to determine which files have been blocked or would have been blocked (if the **Audit only** enforcement setting is applied) and how many times the event has occurred for each file.
-
Membership in the local **Administrators** group, or equivalent, is the minimum required to complete this procedure.
-
**Note**
If the AppLocker logs are not on your local device, you will need permission to view the logs. If the output is saved to a file, you will need permission to read that file.
-
-
**To review AppLocker events with Get-AppLockerFileInformation**
-
1. At the command prompt, type **PowerShell**, and then press ENTER.
-
2. Run the following command to review how many times a file would have been blocked from running if rules were enforced:
-
`Get-AppLockerFileInformation –EventLog –EventType Audited –Statistics`
-
3. Run the following command to review how many times a file has been allowed to run or prevented from running:
-
`Get-AppLockerFileInformation –EventLog –EventType Allowed –Statistics`
-
### View the AppLocker Log in Event Viewer
-
When AppLocker policy enforcement is set to **Enforce rules**, rules are enforced for the rule collection and all events are audited. When AppLocker policy enforcement is set to **Audit only**, rules are only evaluated but all events generated from that evaluation are written to the AppLocker log.
-
Membership in the local **Administrators** group, or equivalent, is the minimum required to complete this procedure.
-
**To view events in the AppLocker log by using Event Viewer**
-
1. Open Event Viewer. To do this, click **Start**, type **eventvwr.msc**, and then press ENTER.
-
2. In the console tree under **Application and Services Logs\\Microsoft\\Windows**, double-click **AppLocker**.
-
AppLocker events are listed in either the **EXE and DLL** log, the **MSI and Script** log, or the **Packaged app-Deployment** or **Packaged app-Execution** log. Event information includes the enforcement setting, file name, date and time, and user name. The logs can be exported to other file formats for further analysis.
-
## Related topics
-
-
[AppLocker](applocker-overview.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/monitor-central-access-policy-and-rule-definitions.md b/windows/keep-secure/monitor-central-access-policy-and-rule-definitions.md
index b8e3992188..228daa4fa2 100644
--- a/windows/keep-secure/monitor-central-access-policy-and-rule-definitions.md
+++ b/windows/keep-secure/monitor-central-access-policy-and-rule-definitions.md
@@ -2,83 +2,44 @@
title: Monitor central access policy and rule definitions (Windows 10)
description: This topic for the IT professional describes how to monitor changes to central access policy and central access rule definitions when you use advanced security auditing options to monitor dynamic access control objects.
ms.assetid: 553f98a6-7606-4518-a3c5-347a33105130
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Monitor central access policy and rule definitions
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional describes how to monitor changes to central access policy and central access rule definitions when you use advanced security auditing options to monitor dynamic access control objects.
-
Central access policies and rules determine access permissions for multiple files on multiple file servers. Therefore, it is important to monitor changes to them. Like user claim and device claim definitions, central access policy and rule definitions reside in Active Directory Domain Services (AD DS), and they can be monitored just like any other object in Active Directory. Central access policies and rules are critical elements in a Dynamic Access Control deployment. These policies and rules are stored in AD DS, so they should be less likely to be tampered with than other network objects. However, it is important to monitor these objects for potential changes in security auditing and to verify that policies are being enforced.
-
Use the following procedures to configure settings to monitor changes to central access policy and central access rule definitions and to verify the changes. These procedures assume that you have configured and deployed Dynamic Access Control, including central access policies, claims, and other components, in your network. If you have not yet deployed Dynamic Access Control in your network, see [Deploy a Central Access Policy (Demonstration Steps)](http://technet.microsoft.com/library/hh846167.aspx).
-
**Note**
Your server might function differently based on the version and edition of the operating system that is installed, your account permissions, and your menu settings.
-
-
**To configure settings to monitor changes to central access policy and rule definitions**
-
1. Sign in to your domain controller by using domain administrator credentials.
-
2. In Server Manager, point to **Tools**, and then click **Group Policy Management**.
-
3. In the console tree, right-click the default domain controller Group Policy Object, and then click **Edit**.
-
4. Double-click **Computer Configuration**, click **Security Settings**, expand **Advanced Audit Policy Configuration**, expand **System Audit Policies**, click **DS Access**, and then double-click **Audit directory service changes**.
-
5. Select the **Configure the following audit events** check box, select the **Success** check box (and the **Failure** check box, if desired), and then click **OK**.
-
6. Close the Group Policy Management Editor.
-
7. Open the Active Directory Administrative Center.
-
8. Under Dynamic Access Control, right-click **Central Access Policies**, and then select **Properties**.
-
9. Click the **Security** tab, click **Advanced** to open the **Advanced Security Settings** dialog box, and then click the **Auditing** tab.
-
10. Click **Add**, add a security auditing setting for the container, and then close all Security properties dialog boxes.
-
After you configure settings to monitor changes to central access policy and central access rule definitions, verify that the changes are being monitored.
-
**To verify that changes to central access policy and rule definitions are monitored**
-
1. Sign in to your domain controller by using domain administrator credentials.
-
2. Open the Active Directory Administrative Center.
-
3. Under **Dynamic Access Control**, right-click **Central Access Policies**, and then click **Properties**.
-
4. Click the **Security** tab, click **Advanced** to open the **Advanced Security Settings** dialog box, and then click the **Auditing** tab.
-
5. Click **Add**, add a security auditing setting for the container, and then close all Security properties dialog boxes.
-
6. In the **Central Access Policies** container, add a new central access policy (or select one that exists), click **Properties** in the **Tasks** pane, and then change one or more attributes.
-
7. Click **OK**, and then close the Active Directory Administrative Center.
-
8. In Server Manager, click **Tools**, and then click **Event Viewer**.
-
9. Expand **Windows Logs**, and then click **Security**. Verify that event 4819 appears in the security log.
-
### Related resource
-
[Using advanced security auditing options to monitor dynamic access control objects](using-advanced-security-auditing-options-to-monitor-dynamic-access-control-objects.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/monitor-claim-types.md b/windows/keep-secure/monitor-claim-types.md
index 67265eeab9..88650d8745 100644
--- a/windows/keep-secure/monitor-claim-types.md
+++ b/windows/keep-secure/monitor-claim-types.md
@@ -2,73 +2,39 @@
title: Monitor claim types (Windows 10)
description: This topic for the IT professional describes how to monitor changes to claim types that are associated with dynamic access control when you are using advanced security auditing options.
ms.assetid: 426084da-4eef-44af-aeec-e7ab4d4e2439
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Monitor claim types
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional describes how to monitor changes to claim types that are associated with dynamic access control when you are using advanced security auditing options.
-
Claim types are one of the basic building blocks of Dynamic Access Control. Claim types can include attributes such as the departments in an organization or the levels of security clearance that apply to classes of users. You can use security auditing to track whether claims are added, modified, enabled, disabled, or deleted.
-
Use the following procedures to configure settings to monitor changes to claim types in AD DS. These procedures assume that you have configured and deployed Dynamic Access Control, including central access policies, claims, and other components, in your network. If you have not yet deployed Dynamic Access Control in your network, see [Deploy a Central Access Policy (Demonstration Steps)](http://technet.microsoft.com/library/hh846167.aspx).
-
**Note**
Your server might function differently based on the version and edition of the operating system that is installed, your account permissions, and your menu settings.
-
-
**To configure settings to monitor changes to claim types**
-
1. Sign in to your domain controller by using domain administrator credential.
-
2. In Server Manager, point to **Tools**, and then click **Group Policy Management**.
-
3. In the console tree, right-click the default domain controller Group Policy Object, and then click **Edit**.
-
4. Double-click **Computer Configuration**, click **Security Settings**, expand **Advanced Audit Policy Configuration**, expand **System Audit Policies**, click **DS Access**, and then double-click **Audit directory service changes**.
-
5. Select the **Configure the following audit events** check box, select the **Success** check box (andthe **Failure** check box, if desired), and then click **OK**.
-
After you configure settings to monitor changes to claim types in AD DS, verify that the changes are being monitored.
-
**To verify that changes to claim types are monitored**
-
1. Sign in to your domain controller by using domain administrator credentials.
-
2. Open the Active Directory Administrative Center.
-
3. Under **Dynamic Access Control**, right-click **Claim Types**, and then click **Properties**.
-
4. Click the **Security** tab, click **Advanced** to open the **Advanced Security Settings** dialog box, and then click the **Auditing** tab.
-
5. Click **Add**, add a security auditing setting for the container, and then close all the Security properties dialog boxes.
-
6. In the **Claim Types** container, add a new claim type or select an existing claim type. In the **Tasks** pane, click **Properties**, and then change one or more attributes.
-
Click **OK**, and then close the Active Directory Administrative Center.
-
7. Open Event Viewer on this domain controller, expand **Windows Logs**, and select the **Security** log.
-
Look for event 5137. Key information to look for includes the name of the new attribute that was added, the type of claim that was created, and the user who created the claim.
-
### Related resource
-
[Using advanced security auditing options to monitor dynamic access control objects](using-advanced-security-auditing-options-to-monitor-dynamic-access-control-objects.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/monitor-resource-attribute-definitions.md b/windows/keep-secure/monitor-resource-attribute-definitions.md
index 2412bd06b9..71c872ac0f 100644
--- a/windows/keep-secure/monitor-resource-attribute-definitions.md
+++ b/windows/keep-secure/monitor-resource-attribute-definitions.md
@@ -2,81 +2,43 @@
title: Monitor resource attribute definitions (Windows 10)
description: This topic for the IT professional describes how to monitor changes to resource attribute definitions when you are using advanced security auditing options to monitor dynamic access control objects.
ms.assetid: aace34b0-123a-4b83-9e09-f269220e79de
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Monitor resource attribute definitions
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional describes how to monitor changes to resource attribute definitions when you are using advanced security auditing options to monitor dynamic access control objects.
-
Resource attribute definitions define the basic properties of resource attributes, such as what it means for a resource to be defined as “high business value.” Resource attribute definitions are stored in AD DS under the Resource Properties container. Changes to these definitions could significantly change the protections that govern a resource, even if the resource attributes that apply to the resource remain unchanged. Changes can be monitored like any other AD DS object.
-
For information about monitoring changes to the resource attributes that apply to files, see [Monitor the resource attributes on files and folders](monitor-the-resource-attributes-on-files-and-folders.md).
-
Use the following procedures to configure settings to monitor changes to resource attribute definitions in AD DS and to verify the changes. These procedures assume that you have configured and deployed Dynamic Access Control, including central access policies, claims, and other components, in your network. If you have not yet deployed Dynamic Access Control in your network, see [Deploy a Central Access Policy (Demonstration Steps)](http://technet.microsoft.com/library/hh846167.aspx).
-
**Note**
Your server might function differently based on the version and edition of the operating system that is installed, your account permissions, and your menu settings.
-
-
**To configure settings to monitor changes to resource attributes**
-
1. Sign in to your domain controller by using domain administrator credentials.
-
2. In Server Manager, point to **Tools**, and then click **Group Policy Management**.
-
3. In the console tree, right-click the Group Policy Object for the default domain controller, and then click **Edit**.
-
4. Double-click **Computer Configuration**, click **Security Settings**, expand **Advanced Audit Policy Configuration**, expand **System Audit Policies**, click **DS Access**, and then double-click **Audit directory service changes**.
-
5. Select the **Configure the following audit events** check box, select the **Success** check box (and the **Failure** check box, if desired), and then click **OK**.
-
6. Close the Group Policy Management Editor.
-
7. Open the Active Directory Administrative Center.
-
8. Under **Dynamic Access Control**, right-click **Resource Properties**, and then click **Properties**.
-
9. Click the **Security** tab, click **Advanced** to open the **Advanced Security Settings** dialog box, and then click the **Auditing** tab.
-
10. Click **Add**, add a security auditing setting for the container, and then close all Security properties dialog boxes.
-
After you configure settings to monitor changes to resource attributes in AD DS, verify that the changes are being monitored.
-
**To verify that changes to resource definitions are monitored**
-
1. Sign in to your domain controller by using domain administrator credentials.
-
2. Open the Active Directory Administrative Center.
-
3. Under **Dynamic Access Control**, click **Resource Properties**, and then double-click a resource attribute.
-
4. Make changes to this resource attribute.
-
5. Click **OK**, and then close the Active Directory Administrative Center.
-
6. In Server Manager, click **Tools**, and then click **Event Viewer**.
-
7. Expand **Windows Logs**, and then click **Security**. Verify that event 5137 appears in the security log.
-
### Related resource
-
[Using advanced security auditing options to monitor dynamic access control objects](using-advanced-security-auditing-options-to-monitor-dynamic-access-control-objects.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/monitor-the-central-access-policies-associated-with-files-and-folders.md b/windows/keep-secure/monitor-the-central-access-policies-associated-with-files-and-folders.md
index 322fd4217e..3aff0a5708 100644
--- a/windows/keep-secure/monitor-the-central-access-policies-associated-with-files-and-folders.md
+++ b/windows/keep-secure/monitor-the-central-access-policies-associated-with-files-and-folders.md
@@ -2,100 +2,53 @@
title: Monitor the central access policies associated with files and folders (Windows 10)
description: This topic for the IT professional describes how to monitor changes to the central access policies that are associated with files and folders when you are using advanced security auditing options to monitor dynamic access control objects.
ms.assetid: 2ea8fc23-b3ac-432f-87b0-6a16506e8eed
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Monitor the central access policies associated with files and folders
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional describes how to monitor changes to the central access policies that are associated with files and folders when you are using advanced security auditing options to monitor dynamic access control objects.
-
This security audit policy and the event that it records are generated when the central access policy that is associated with a file or folder is changed. This security audit policy is useful when an administrator wants to monitor potential changes on some, but not all, files and folders on a file server.
-
For info about monitoring potential central access policy changes for an entire file server, see [Monitor the central access policies that apply on a file server](monitor-the-central-access-policies-that-apply-on-a-file-server.md).
-
Use the following procedures to configure settings to monitor central access policies that are associated with files. These procedures assume that you have configured and deployed Dynamic Access Control in your network. For more information about how to configure and deploy Dynamic Access Control, see [Dynamic Access Control: Scenario Overview](http://technet.microsoft.com/library/hh831717.aspx).
-
**Note**
Your server might function differently based on the version and edition of the operating system that is installed, your account permissions, and your menu settings.
-
-
**To configure settings to monitor central access policies associated with files or folders**
-
1. Sign in to your domain controller by using domain administrator credentials.
-
2. In Server Manager, point to **Tools**, and then click **Group Policy Management**.
-
3. In the console tree, right-click the flexible access Group Policy Object, and then click **Edit**.
-
4. Double-click **Computer Configuration**, double-click **Security Settings**, double-click **Advanced Audit Policy Configuration**, double-click **Policy Change**, and then double-click **Audit Authorization Policy Change**.
-
5. Select the **Configure the following audit events** check box, select the **Success** check box (and the **Failure** check box, if desired), and then click **OK**.
-
6. Enable auditing for a file or folder as described in the following procedure.
-
**To enable auditing for a file or folder**
-
1. Sign in as a member of the local administrators group on the computer that contains the files or folders that you want to audit.
-
2. Right-click the file or folder, click **Properties**, and then click the **Security** tab.
-
3. Click **Advanced**, click the **Auditing** tab, and then click **Continue**.
-
If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click **Yes**.
-
4. Click **Add**, click **Select a principal**, type a user name or group name in the format **contoso\\user1**, and then click **OK**.
-
5. In the **Auditing Entry for** dialog box, select the permissions that you want to audit, such as **Full Control** or **Delete**.
-
6. Click **OK** four times to complete the configuration of the object SACL.
-
7. Open a File Explorer window and select or create a file or folder to audit.
-
8. Open an elevated command prompt, and run the following command:
-
**gpupdate /force**
-
After you configure settings to monitor changes to the central access policies that are associated with files and folders, verify that the changes are being monitored.
-
**To verify that changes to central access policies associated with files and folders are monitored**
-
1. Sign in as a member of the local administrators group on the computer that contains the files or folders that you want to audit.
-
2. Open a File Explorer window and select the file or folder that you configured for auditing in the previous procedure.
-
3. Right-click the file or folder, click **Properties**, click the **Security** tab, and then click **Advanced**.
-
4. Click the **Central Policy** tab, click **Change**, and select a different central access policy (if one is available) or select **No Central Access Policy**, and then click **OK** twice.
-
**Note**
You must select a setting that is different than your original setting to generate the audit event.
-
-
5. In Server Manager, click **Tools**, and then click **Event Viewer**.
-
6. Expand **Windows Logs**, and then click **Security**.
-
7. Look for event 4913, which is generated when the central access policy that is associated with a file or folder is changed. This event includes the security identifiers (SIDs) of the old and new central access policies.
-
### Related resource
-
[Using advanced security auditing options to monitor dynamic access control objects](using-advanced-security-auditing-options-to-monitor-dynamic-access-control-objects.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/monitor-the-central-access-policies-that-apply-on-a-file-server.md b/windows/keep-secure/monitor-the-central-access-policies-that-apply-on-a-file-server.md
index d19126daa6..54838b32b6 100644
--- a/windows/keep-secure/monitor-the-central-access-policies-that-apply-on-a-file-server.md
+++ b/windows/keep-secure/monitor-the-central-access-policies-that-apply-on-a-file-server.md
@@ -2,81 +2,43 @@
title: Monitor the central access policies that apply on a file server (Windows 10)
description: This topic for the IT professional describes how to monitor changes to the central access policies that apply to a file server when using advanced security auditing options to monitor dynamic access control objects.
ms.assetid: 126b051e-c20d-41f1-b42f-6cff24dcf20c
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Monitor the central access policies that apply on a file server
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional describes how to monitor changes to the central access policies that apply to a file server when using advanced security auditing options to monitor dynamic access control objects. Central access policies are created on a domain controller and then applied to file servers through Group Policy management.
-
Use the following procedures to configure and verify security auditing settings that are used to monitor changes to the set of central access policies on a file server. The following procedures assume that you have configured and deployed dynamic access control, including central access policies, and claims in your network. If you have not yet deployed dynamic access control in your network, see [Deploy a Central Access Policy (Demonstration Steps)](http://technet.microsoft.com/library/hh846167.aspx).
-
**To configure settings to monitor changes to central access policies**
-
1. Sign in to your domain controller by using domain administrator credentials.
-
2. In Server Manager, point to **Tools**, and then click **Group Policy Management**.
-
3. In the console tree, right-click the flexible access Group Policy Object, and then click **Edit**.
-
4. Double-click **Computer Configuration**, double-click **Security Settings**, double-click **Advanced Audit Policy Configuration**, double-click **Policy Change**, and then double-click **Other Policy Change Events**.
-
**Note**
This policy setting monitors policy changes that might not be captured otherwise, such as central access policy changes or trusted platform module configuration changes.
-
-
5. Select the **Configure the following audit events** check box, select the **Success** check box (and the **Failure** check box, if desired), and then click **OK**.
-
After you modify the central access policies on the domain controller, verify that the changes have been applied to the file server and that the proper events are logged.
-
**To verify changes to the central access policies**
-
1. Sign in to your domain controller by using domain administrator credentials.
-
2. Open the Group Policy Management Console.
-
3. Right-click **Default domain policy**, and then click **Edit**.
-
4. Double-click **Computer Configuration**, double-click **Policies**, and then double-click **Windows Settings**.
-
5. Double-click **Security Settings**, right-click **File system**, and then click **Manage CAPs**.
-
6. In the wizard that appears, follow the instructions to add a new central access policy (CAP), and then click **OK**.
-
7. Use local administrator credentials to sign in to the server that hosts resources that are subject to the central access policies you changed.
-
8. Press the Windows key + R, then type **cmd** to open a Command Prompt window.
-
**Note**
If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click **Yes**.
-
-
9. Type **gpupdate /force**, and press ENTER.
-
10. In Server Manager, click **Tools**, and then click **Event Viewer**.
-
11. Expand **Windows Logs**, and then click **Security**. Verify that event 4819 appears in the security log.
-
## Related resource
-
-
[Using advanced security auditing options to monitor dynamic access control objects](using-advanced-security-auditing-options-to-monitor-dynamic-access-control-objects.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/monitor-the-resource-attributes-on-files-and-folders.md b/windows/keep-secure/monitor-the-resource-attributes-on-files-and-folders.md
index 0e52151278..8c4c23bf12 100644
--- a/windows/keep-secure/monitor-the-resource-attributes-on-files-and-folders.md
+++ b/windows/keep-secure/monitor-the-resource-attributes-on-files-and-folders.md
@@ -2,79 +2,42 @@
title: Monitor the resource attributes on files and folders (Windows 10)
description: This topic for the IT professional describes how to monitor attempts to change settings to the resource attributes on files when you are using advanced security auditing options to monitor dynamic access control objects.
ms.assetid: 4944097b-320f-44c7-88ed-bf55946a358b
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Monitor the resource attributes on files and folders
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional describes how to monitor attempts to change settings to the resource attributes on files when you are using advanced security auditing options to monitor dynamic access control objects.
-
If your organization has a carefully thought out authorization configuration for resources, changes to these resource attributes can create potential security risks. Examples include:
-
- Changing files that have been marked as high business value to low business value.
-
- Changing the Retention attribute of files that have been marked for retention.
-
- Changing the Department attribute of files that are marked as belonging to a particular department.
-
Use the following procedures to configure settings to monitor changes to resource attributes on files and folders. These procedures assume that have configured and deployed central access policies in your network. For more information about how to configure and deploy central access policies, see [Dynamic Access Control: Scenario Overview](http://technet.microsoft.com/library/hh831717.aspx) .
-
**Note**
Your server might function differently based on the version and edition of the operating system that is installed, your account permissions, and your menu settings.
-
-
**To monitor changes to resource attributes on files**
-
1. Sign in to your domain controller by using domain administrator credentials.
-
2. In Server Manager, point to **Tools**, and then click **Group Policy Management**.
-
3. In the console tree, right-click the flexible access Group Policy Object, and then click **Edit**.
-
4. Double-click **Computer Configuration**, double-click **Security Settings**, double-click **Advanced Audit Policy Configuration**, double-click **Policy Change**, and then double-click **Audit Authorization Policy Change**.
-
5. Select the **Configure the following audit events** check box, select the **Success** and **Failure** check boxes, and then click **OK**.
-
After you configure settings to monitor resource attributes on files, verify that the changes are being monitored.
-
**To verify that changes to resource attributes on files are monitored**
-
1. Use administrator credentials to sign in to the server that hosts the resource you want to monitor.
-
2. From an elevated command prompt, type **gpupdate /force**, and then press ENTER.
-
3. Attempt to change resource properties on one or more files and folders.
-
4. In Server Manager, click **Tools**, and then click **Event Viewer**.
-
5. Expand **Windows Logs**, and then click **Security**.
-
6. Depending on which resource attributes you attempted to change, you should look for the following events:
-
- Event 4911, which tracks changes to file attributes
-
- Event 4913, which tracks changes to central access policies
-
Key information to look for includes the name and account domain of the principal attempting to change the resource attribute, the object that the principal is attempting to modify, and information about the changes that are being attempted.
-
### Related resource
-
[Using advanced security auditing options to monitor dynamic access control objects](using-advanced-security-auditing-options-to-monitor-dynamic-access-control-objects.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/monitor-the-use-of-removable-storage-devices.md b/windows/keep-secure/monitor-the-use-of-removable-storage-devices.md
index 4a241ac162..b465dfccb6 100644
--- a/windows/keep-secure/monitor-the-use-of-removable-storage-devices.md
+++ b/windows/keep-secure/monitor-the-use-of-removable-storage-devices.md
@@ -2,83 +2,45 @@
title: Monitor the use of removable storage devices (Windows 10)
description: This topic for the IT professional describes how to monitor attempts to use removable storage devices to access network resources. It describes how to use advanced security auditing options to monitor dynamic access control objects.
ms.assetid: b0a9e4a5-b7ff-41c6-96ff-0228d4ba5da8
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Monitor the use of removable storage devices
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional describes how to monitor attempts to use removable storage devices to access network resources. It describes how to use advanced security auditing options to monitor dynamic access control objects.
-
If you configure this policy setting, an audit event is generated each time a user attempts to copy, move, or save a resource to a removable storage device.
-
Use the following procedures to monitor the use of removable storage devices and to verify that the devices are being monitored.
-
**Note**
Your server might function differently based on the version and edition of the operating system that is installed, your account permissions, and your menu settings.
-
-
**To configure settings to monitor removable storage devices**
-
1. Sign in to your domain controller by using domain administrator credentials.
-
2. In Server Manager, point to **Tools**, and then click **Group Policy Management**.
-
3. In the console tree, right-click the flexible access Group Policy Object on the domain controller, and then click **Edit**.
-
4. Double-click **Computer Configuration**, double-click **Security Settings**, double-click **Advanced Audit Policy Configuration**, double-click **Object Access**, and then double-click **Audit Removable Storage**.
-
5. Select the **Configure the following audit events** check box, select the **Success** check box (and the **Failure** check box, if desired), and then click **OK**.
-
6. If you selected the **Failure** check box, double-click **Audit Handle Manipulation**, select the **Configure the following audit events check box**, and then select **Failure**.
-
7. Click **OK**, and then close the Group Policy Management Editor.
-
After you configure the settings to monitor removable storage devices, use the following procedure to verify that the settings are active.
-
**To verify that removable storage devices are monitored**
-
1. Sign in to the computer that hosts the resources that you want to monitor. Press the Windows key + R, and then type **cmd** to open a Command Prompt window.
-
**Note**
If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click **Yes**.
-
-
2. Type **gpupdate /force**, and press ENTER.
-
3. Connect a removable storage device to the targeted computer and attempt to copy a file that is protected with the Removable Storage Audit policy.
-
4. In Server Manager, click **Tools**, and then click **Event Viewer**.
-
5. Expand **Windows Logs**, and then click **Security**.
-
6. Look for event 4663, which logs successful attempts to write to or read from a removable storage device. Failures will log event 4656. Both events include **Task Category = Removable Storage device**.
-
Key information to look for includes the name and account domain of the user who attempted to access the file, the object that the user is attempting to access, resource attributes of the resource, and the type of access that was attempted.
-
**Note**
We do not recommend that you enable this category on a file server that hosts file shares on a removable storage device. When Removable Storage Auditing is configured, any attempt to access the removable storage device will generate an audit event.
-
-
### Related resource
-
[Using advanced security auditing options to monitor dynamic access control objects](using-advanced-security-auditing-options-to-monitor-dynamic-access-control-objects.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/monitor-user-and-device-claims-during-sign-in.md b/windows/keep-secure/monitor-user-and-device-claims-during-sign-in.md
index cee27df860..43db7d7f40 100644
--- a/windows/keep-secure/monitor-user-and-device-claims-during-sign-in.md
+++ b/windows/keep-secure/monitor-user-and-device-claims-during-sign-in.md
@@ -2,67 +2,36 @@
title: Monitor user and device claims during sign-in (Windows 10)
description: This topic for the IT professional describes how to monitor user and device claims that are associated with a user’s security token when you are using advanced security auditing options to monitor dynamic access control objects.
ms.assetid: 71796ea9-5fe4-4183-8475-805c3c1f319f
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Monitor user and device claims during sign-in
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional describes how to monitor user and device claims that are associated with a user’s security token when you are using advanced security auditing options to monitor dynamic access control objects.
-
Device claims are associated with the system that is used to access resources that are protected with Dynamic Access Control. User claims are attributes that are associated with a user. User claims and device claims are included in the user’s security token used at sign-on. For example, information about Department, Company, Project, or Security clearances might be included in the token.
-
Use the following procedures to monitor changes to user claims and device claims in the user’s sign-on token and to verify the changes. These procedures assume that you have configured and deployed Dynamic Access Control, including central access policies, claims, and other components, in your network. If you have not yet deployed Dynamic Access Control in your network, see [Deploy a Central Access Policy (Demonstration Steps)](http://technet.microsoft.com/library/hh846167.aspx).
-
**Note**
Your server might function differently based on the version and edition of the operating system that is installed, your account permissions, and your menu settings.
-
-
**To monitor user and device claims in user logon token**
-
1. Sign in to your domain controller by using domain administrator credentials.
-
2. In Server Manager, point to **Tools**, and then click **Group Policy Management**.
-
3. In the console tree, right-click the flexible access Group Policy Object, and then click **Edit**.
-
4. Double-click **Computer Configuration**, click **Security Settings**, expand **Advanced Audit Policy Configuration**, expand **System Audit Policies**, click **Logon/Logoff**, and then double-click **Audit User/Device claims**.
-
5. Select the **Configure the following audit events** check box, select the **Success** check box (and the **Failure** check box, if desired), and then click **OK**.
-
6. Close the Group Policy Management Editor.
-
After you configure settings to monitor user and device claims, verify that the changes are being monitored.
-
**To verify that user and device claims in user logon token are monitored**
-
1. With local administrator credentials, sign in to a file server that is subject to the flexible access Group Policy Object.
-
2. Open an elevated command prompt, and run the following command:
-
**gpupdate force**
-
3. From a client computer, connect to a file share on the file server as a user who has access permissions to the file server.
-
4. On the file server, open Event Viewer, expand **Windows Logs**, and select the **Security** log. Look for event 4626, and confirm that it contains information about user claims and device claims.
-
### Related resource
-
[Using advanced security auditing options to monitor dynamic access control objects](using-advanced-security-auditing-options-to-monitor-dynamic-access-control-objects.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/network-access-allow-anonymous-sidname-translation.md b/windows/keep-secure/network-access-allow-anonymous-sidname-translation.md
index 286cf227fe..ce3d50eac0 100644
--- a/windows/keep-secure/network-access-allow-anonymous-sidname-translation.md
+++ b/windows/keep-secure/network-access-allow-anonymous-sidname-translation.md
@@ -2,54 +2,32 @@
title: Network access Allow anonymous SID/Name translation (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Network access Allow anonymous SID/Name translation security policy setting.
ms.assetid: 0144477f-22a6-4d06-b70a-9c9c2196e99e
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Network access: Allow anonymous SID/Name translation
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **Network access: Allow anonymous SID/Name translation** security policy setting.
-
## Reference
-
-
This policy setting enables or disables the ability of an anonymous user to request security identifier (SID) attributes for another user.
-
If this policy setting is enabled, a user might use the well-known Administrators SID to get the real name of the built-in Administrator account, even if the account has been renamed. That person might then use the account name to initiate a brute-force password-guessing attack.
-
Misuse of this policy setting is a common error that can cause data loss or problems with data access or security.
-
### Possible values
-
- Enabled
-
An anonymous user can request the SID attribute for another user. An anonymous user with knowledge of an administrator's SID could contact a computer that has this policy enabled and use the SID to get the administrator's name. This setting affects the SID-to-name translation as well as the name-to-SID translation
-
- Disabled
-
Prevents an anonymous user from requesting the SID attribute for another user.
-
- Not defined
-
### Best practices
-
- Set this policy to Disabled. This is the default value on member computers; therefore, it will have no impact on them. The default value for domain controllers is Enabled.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -88,57 +66,26 @@ The following table lists the actual and effective default values for this polic
-
-
### Operating system version differences
-
The default value of this setting has changed between operating systems as follows:
-
- The default on domain controllers running Windows Server 2003 R2 or earlier was set to Enabled.
-
- The default on domain controllers running Windows Server 2008 and later is set to Disabled.
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Group Policy
-
Modifying this setting may affect compatibility with client computers, services, and applications.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
If this policy setting is enabled, a user with local access could use the well-known Administrator's SID to learn the real name of the built-in Administrator account, even if it has been renamed. That person could then use the account name to initiate a password-guessing attack.
-
### Countermeasure
-
Disable the **Network access: Allow anonymous SID/Name translation** setting.
-
### Potential impact
-
Disabled is the default configuration for this policy setting on member devices; therefore, it has no impact on them. The default configuration for domain controllers is Enabled.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts-and-shares.md b/windows/keep-secure/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts-and-shares.md
index 9b2363c07f..95f97f704f 100644
--- a/windows/keep-secure/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts-and-shares.md
+++ b/windows/keep-secure/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts-and-shares.md
@@ -2,48 +2,29 @@
title: Network access Do not allow anonymous enumeration of SAM accounts and shares (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Network access Do not allow anonymous enumeration of SAM accounts and shares security policy setting.
ms.assetid: 3686788d-4cc7-4222-9163-cbc7c3362d73
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Network access: Do not allow anonymous enumeration of SAM accounts and shares
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **Network access: Do not allow anonymous enumeration of SAM accounts and shares** security policy setting.
-
## Reference
-
-
This policy setting determines which additional permissions will be assigned for anonymous connections to the device. Windows allows anonymous users to perform certain activities, such as enumerating the names of domain accounts and network shares. This is convenient, for example, when an administrator wants to give access to users in a trusted domain that does not maintain a reciprocal trust. However, even with this policy setting enabled, anonymous users will have access to resources with permissions that explicitly include the built-in group, ANONYMOUS LOGON.
-
This policy setting has no impact on domain controllers.
-
Misuse of this policy setting is a common error that can cause data loss or problems with data access or security.
-
### Possible values
-
- Enabled
-
- Disabled
-
No additional permissions can be assigned by the administrator for anonymous connections to the device. Anonymous connections will rely on default permissions. However, an unauthorized user could anonymously list account names and use the information to attempt to guess passwords or perform social-engineering attacks.
-
- Not defined
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -82,53 +63,24 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Policy conflicts
-
Even with this policy setting enabled, anonymous users will have access to resources with permissions that explicitly include the built-in group, ANONYMOUS LOGON (on systems earlier than Windows Server 2008 and Windows Vista).
-
### Group Policy
-
This policy has no impact on domain controllers.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
An unauthorized user could anonymously list account names and shared resources and use the information to attempt to guess passwords or perform social-engineering attacks.
-
### Countermeasure
-
Enable the **Network access: Do not allow anonymous enumeration of SAM accounts and shares** setting.
-
### Potential impact
-
It is impossible to grant access to users of another domain across a one-way trust because administrators in the trusting domain are unable to enumerate lists of accounts in the other domain. Users who access file and print servers anonymously are unable to list the shared network resources on those servers; the users must be authenticated before they can view the lists of shared folders and printers.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts.md b/windows/keep-secure/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts.md
index 70eb372dcb..2324359e3a 100644
--- a/windows/keep-secure/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts.md
+++ b/windows/keep-secure/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts.md
@@ -2,48 +2,29 @@
title: Network access Do not allow anonymous enumeration of SAM accounts (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Network access Do not allow anonymous enumeration of SAM accounts security policy setting.
ms.assetid: 6ee25b33-ad43-4097-b031-7be680f64c7c
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Network access: Do not allow anonymous enumeration of SAM accounts
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **Network access: Do not allow anonymous enumeration of SAM accounts** security policy setting.
-
## Reference
-
-
This policy setting determines which additional permissions will be assigned for anonymous connections to the device. Windows allows anonymous users to perform certain activities, such as enumerating the names of domain accounts and network shares. This is convenient, for example, when an administrator wants to give access to users in a trusted domain that does not maintain a reciprocal trust.
-
This policy setting has no impact on domain controllers.
-
Misuse of this policy setting is a common error that can cause data loss or problems with data access or security.
-
### Possible values
-
- Enabled
-
- Disabled
-
No additional permissions can be assigned by the administrator for anonymous connections to the device. Anonymous connections will rely on default permissions.
-
- Not defined
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -82,53 +63,24 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Policy conflicts
-
Even with this policy setting enabled, anonymous users will have access to resources with permissions that explicitly include the built-in group, ANONYMOUS LOGON (on systems earlier than Windows Server 2008 and Windows Vista).
-
### Group Policy
-
This policy has no impact on domain controllers.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
An unauthorized user could anonymously list account names and use the information to perform social engineering attacks or attempt to guess passwords. Social engineering attackers try to deceive users in some way to obtain passwords or some form of security information.
-
### Countermeasure
-
Enable the **Network access: Do not allow anonymous enumeration of SAM accounts** setting.
-
### Potential impact
-
It is impossible to grant access to users of another domain across a one-way trust because administrators in the trusting domain are unable to enumerate lists of accounts in the other domain. Users who access file and print servers anonymously are unable to list the shared network resources on those servers; the users must be authenticated before they can view the lists of shared folders and printers.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/network-access-do-not-allow-storage-of-passwords-and-credentials-for-network-authentication.md b/windows/keep-secure/network-access-do-not-allow-storage-of-passwords-and-credentials-for-network-authentication.md
index 6fd38c9352..16fa1842da 100644
--- a/windows/keep-secure/network-access-do-not-allow-storage-of-passwords-and-credentials-for-network-authentication.md
+++ b/windows/keep-secure/network-access-do-not-allow-storage-of-passwords-and-credentials-for-network-authentication.md
@@ -2,50 +2,30 @@
title: Network access Do not allow storage of passwords and credentials for network authentication (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Network access Do not allow storage of passwords and credentials for network authentication security policy setting.
ms.assetid: b9b64360-36ea-40fa-b795-2d6558c46563
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Network access: Do not allow storage of passwords and credentials for network authentication
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **Network access: Do not allow storage of passwords and credentials for network authentication** security policy setting.
-
## Reference
-
-
This security setting determines whether Credential Manager saves passwords and credentials for later use when it gains domain authentication.
-
### Possible values
-
- Enabled
-
Credential Manager does not store passwords and credentials on the device
-
- Disabled
-
Credential Manager will store passwords and credentials on this computer for later use for domain authentication.
-
- Not defined
-
### Best practices
-
It is a recommended practice to disable the ability of the Windows operating system to cache credentials on any device where credentials are not needed. Evaluate your servers and workstations to determine the requirements. Cached credentials are designed primarily to be used on laptops that require domain credentials when disconnected from the domain.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -84,61 +64,29 @@ The following table lists the actual and effective default values for this polic
-
-
### Policy management
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
A restart of the device is required before this policy will be effective when changes to this policy are saved locally or distributed through Group Policy.
-
### Group Policy
-
This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Passwords that are cached can be accessed by the user when logged on to the device. Although this information may sound obvious, a problem can arise if the user unknowingly runs malicious software that reads the passwords and forwards them to another, unauthorized user.
-
**Note**
The chances of success for this exploit and others that involve malicious software are reduced significantly for organizations that effectively implement and manage an enterprise antivirus solution combined with sensible software restriction policies.
-
-
Regardless of what encryption algorithm is used to encrypt the password verifier, a password verifier can be overwritten so that an attacker can authenticate as the user to whom the verifier belongs. Therefore, the administrator's password may be overwritten. This procedure requires physical access to the device. Utilities exist that can help overwrite the cached verifier. By using one of these utilities, an attacker can authenticate by using the overwritten value.
-
Overwriting the administrator's password does not help the attacker access data that is encrypted by using that password. Also, overwriting the password does not help the attacker access any Encrypting File System (EFS) data that belongs to other users on that device. Overwriting the password does not help an attacker replace the verifier, because the base keying material is incorrect. Therefore, data that is encrypted by using Encrypting File System or by using the Data Protection API (DPAPI) will not decrypt.
-
### Countermeasure
-
Enable the **Network access: Do not allow storage of passwords and credentials for network authentication** setting.
-
To limit the number of changed domain credentials that are stored on the computer, set the **cachedlogonscount** registry entry. By default, the operating system caches the verifier for each unique user's ten most recent valid logons. This value can be set to any value between 0 and 50. By default, all versions of the Windows operating system remember 10 cached logons, except Windows Server 2008 and later, which are set at 25.
-
When you try to log on to a domain from a Windows-based client device, and a domain controller is unavailable, you do not receive an error message. Therefore, you may not notice that you logged on with cached domain credentials. You can set a notification of logon that uses cached domain credentials with the ReportDC registry entry.
-
### Potential impact
-
Users are forced to type passwords whenever they log on to their Microsoft Account or other network resources that are not accessible to their domain account. This policy setting should have no impact on users who access network resources that are configured to allow access with their Active Directory–based domain account.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/network-access-let-everyone-permissions-apply-to-anonymous-users.md b/windows/keep-secure/network-access-let-everyone-permissions-apply-to-anonymous-users.md
index a1cbd0efd4..84c96fe8a5 100644
--- a/windows/keep-secure/network-access-let-everyone-permissions-apply-to-anonymous-users.md
+++ b/windows/keep-secure/network-access-let-everyone-permissions-apply-to-anonymous-users.md
@@ -2,52 +2,31 @@
title: Network access Let Everyone permissions apply to anonymous users (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Network access Let Everyone permissions apply to anonymous users security policy setting.
ms.assetid: cdbc5159-9173-497e-b46b-7325f4256353
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Network access: Let Everyone permissions apply to anonymous users
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **Network access: Let Everyone permissions apply to anonymous users** security policy setting.
-
## Reference
-
-
This policy setting determines what additional permissions are granted for anonymous connections to the device. If you enable this policy setting, anonymous users can enumerate the names of domain accounts and shared folders and perform certain other activities. This capability is convenient, for example, when an administrator wants to grant access to users in a trusted domain that does not maintain a reciprocal trust.
-
By default, the token that is created for anonymous connections does not include the Everyone SID. Therefore, permissions that are assigned to the Everyone group do not apply to anonymous users.
-
### Possible values
-
- Enabled
-
The Everyone SID is added to the token that is created for anonymous connections, and anonymous users can access any resource for which the Everyone group has been assigned permissions.
-
- Disabled
-
The Everyone SID is removed from the token that is created for anonymous connections.
-
- Not defined
-
### Best practices
-
- Set this policy to **Disabled**.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Polices\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -86,45 +65,20 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
An unauthorized user could anonymously list account names and shared resources and use the information to attempt to guess passwords, perform social engineering attacks, or launch DoS attacks.
-
### Countermeasure
-
Disable the **Network access: Let Everyone permissions apply to anonymous users** setting.
-
### Potential impact
-
None. This is the default configuration.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/network-access-named-pipes-that-can-be-accessed-anonymously.md b/windows/keep-secure/network-access-named-pipes-that-can-be-accessed-anonymously.md
index 3d5c222290..3046386e99 100644
--- a/windows/keep-secure/network-access-named-pipes-that-can-be-accessed-anonymously.md
+++ b/windows/keep-secure/network-access-named-pipes-that-can-be-accessed-anonymously.md
@@ -2,46 +2,28 @@
title: Network access Named Pipes that can be accessed anonymously (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Network access Named Pipes that can be accessed anonymously security policy setting.
ms.assetid: 8897d2a4-813e-4d2b-8518-fcee71e1cf2c
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Network access: Named Pipes that can be accessed anonymously
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **Network access: Named Pipes that can be accessed anonymously** security policy setting.
-
## Reference
-
-
This policy setting determines which communication sessions, or pipes, have attributes and permissions that allow anonymous access.
-
Restricting access over named pipes such as COMNAP and LOCATOR helps prevent unauthorized access to the network.
-
### Possible values
-
- User-defined list of shared folders
-
- Not defined
-
### Best practices
-
- Set this policy to a null value; that is, enable the policy setting, but do not enter named pipes in the text box. This will disable null session access over named pipes, and applications that rely on this feature or on unauthenticated access to named pipes will no longer function.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -80,31 +62,17 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes different features and tools available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Group Policy
-
For this policy setting to take effect, you must also enable the [Network access: Restrict anonymous access to Named Pipes and Shares](network-access-restrict-anonymous-access-to-named-pipes-and-shares.md) setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
You can restrict access over named pipes such as COMNAP and LOCATOR to help prevent unauthorized access to the network. The following list describes available named pipes and their purpose. These pipes were granted anonymous access in earlier versions of Windows and some legacy applications may still use them.
-
@@ -151,27 +119,12 @@ You can restrict access over named pipes such as COMNAP and LOCATOR to help prev
-
-
### Countermeasure
-
Configure the **Network access: Named Pipes that can be accessed anonymously** setting to a null value (enable the setting but do not specify named pipes in the text box).
-
### Potential impact
-
This configuration disables null-session access over named pipes, and applications that rely on this feature or on unauthenticated access to named pipes no longer function. This may break trust between Windows Server 2003 domains in a mixed mode environment.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/network-access-remotely-accessible-registry-paths-and-subpaths.md b/windows/keep-secure/network-access-remotely-accessible-registry-paths-and-subpaths.md
index b38246a85a..c4154f266c 100644
--- a/windows/keep-secure/network-access-remotely-accessible-registry-paths-and-subpaths.md
+++ b/windows/keep-secure/network-access-remotely-accessible-registry-paths-and-subpaths.md
@@ -2,48 +2,29 @@
title: Network access Remotely accessible registry paths and subpaths (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Network access Remotely accessible registry paths and subpaths security policy setting.
ms.assetid: 3fcbbf70-a002-4f85-8e86-8dabad21928e
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Network access: Remotely accessible registry paths and subpaths
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **Network access: Remotely accessible registry paths and subpaths** security policy setting.
-
## Reference
-
-
This policy setting determines which registry paths and subpaths are accessible when an application or process references the WinReg key to determine access permissions.
-
The registry is a database for device configuration information, much of which is sensitive. A malicious user can use it to facilitate unauthorized activities. The chance of this happening is reduced by the fact that the default ACLs that are assigned throughout the registry are fairly restrictive, and they help protect it from access by unauthorized users.
-
To allow remote access, you must also enable the Remote Registry service.
-
### Possible values
-
- User-defined list of paths
-
- Not Defined
-
### Best practices
-
- Set this policy to a null value; that is, enable the policy setting, but do not enter any paths in the text box. Remote management tools, such as the Microsoft Baseline Security Analyzer and Configuration Manager, require remote access to the registry. Removing the default registry paths from the list of accessible paths might cause these and other management tools to fail.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -82,74 +63,35 @@ The following table lists the actual and effective default values for this polic
-
-
The combination of all the following registry keys apply to the previous settings:
-
1. System\\CurrentControlSet\\Control\\Print\\Printers
-
2. System\\CurrentControlSet\\Services\\Eventlog
-
3. Software\\Microsoft\\OLAP Server
-
4. Software\\Microsoft\\Windows NT\\CurrentVersion\\Print
-
5. Software\\Microsoft\\Windows NT\\CurrentVersion\\Windows
-
6. System\\CurrentControlSet\\Control\\ContentIndex
-
7. System\\CurrentControlSet\\Control\\Terminal Server
-
8. System\\CurrentControlSet\\Control\\Terminal Server\\UserConfig
-
9. System\\CurrentControlSet\\Control\\Terminal Server\\DefaultUserConfiguration
-
10. Software\\Microsoft\\Windows NT\\CurrentVersion\\Perflib
-
11. System\\CurrentControlSet\\Services\\SysmonLog
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a computer restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
The registry contains sensitive device configuration information that could be used by an attacker to facilitate unauthorized activities. The fact that the default ACLs that are assigned throughout the registry are fairly restrictive and help to protect the registry from access by unauthorized users reduces the risk of such an attack.
-
### Countermeasure
-
Configure the **Network access: Remotely accessible registry paths and sub-paths** setting to a null value (enable the setting but do not enter any paths in the text box).
-
### Potential impact
-
Remote management tools such as MBSA and Configuration Manager require remote access to the registry to properly monitor and manage those computers. If you remove the default registry paths from the list of accessible ones, such remote management tools could fail.
-
**Note**
If you want to allow remote access, you must also enable the Remote Registry service.
-
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/network-access-remotely-accessible-registry-paths.md b/windows/keep-secure/network-access-remotely-accessible-registry-paths.md
index dbc8008031..33f15de3de 100644
--- a/windows/keep-secure/network-access-remotely-accessible-registry-paths.md
+++ b/windows/keep-secure/network-access-remotely-accessible-registry-paths.md
@@ -2,48 +2,29 @@
title: Network access Remotely accessible registry paths (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Network access Remotely accessible registry paths security policy setting.
ms.assetid: 977f86ea-864f-4f1b-9756-22220efce0bd
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Network access: Remotely accessible registry paths
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **Network access: Remotely accessible registry paths** security policy setting.
-
## Reference
-
-
This policy setting determines which registry paths are accessible when an application or process references the WinReg key to determine access permissions.
-
The registry is a database for device configuration information, much of which is sensitive. A malicious user can use the registry to facilitate unauthorized activities. To reduce the risk of this happening, suitable access control lists (ACLs) are assigned throughout the registry to help protect it from access by unauthorized users.
-
To allow remote access, you must also enable the Remote Registry service.
-
### Possible values
-
- User-defined list of paths
-
- Not Defined
-
### Best practices
-
- Set this policy to a null value; that is, enable the policy setting but do not enter any paths in the text box. Remote management tools, such as the Microsoft Baseline Security Analyzer and Configuration Manager, require remote access to the registry. Removing the default registry paths from the list of accessible paths might cause these and other management tools to fail.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -82,58 +63,27 @@ The following table lists the actual and effective default values for this polic
-
-
The combination of all the following registry keys apply to the previous settings:
-
1. System\\CurrentControlSet\\Control\\ProductOptions
-
2. System\\CurrentControlSet\\Control\\Server Applications
-
3. Software\\Microsoft\\Windows NT\\CurrentVersion
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
An attacker could use information in the registry to facilitate unauthorized activities. To reduce the risk of such an attack, suitable ACLs are assigned throughout the registry to help protect it from access by unauthorized users.
-
### Countermeasure
-
Configure the **Network access: Remotely accessible registry paths** setting to a null value (enable the setting, but do not enter any paths in the text box).
-
### Potential impact
-
Remote management tools such as the Microsoft Baseline Security Analyzer (MBSA) and Configuration Manager require remote access to the registry to properly monitor and manage those computers. If you remove the default registry paths from the list of accessible ones, such remote management tools could fail.
-
**Note**
If you want to allow remote access, you must also enable the Remote Registry service.
-
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/network-access-restrict-anonymous-access-to-named-pipes-and-shares.md b/windows/keep-secure/network-access-restrict-anonymous-access-to-named-pipes-and-shares.md
index baaacfe3a8..ab84cb8711 100644
--- a/windows/keep-secure/network-access-restrict-anonymous-access-to-named-pipes-and-shares.md
+++ b/windows/keep-secure/network-access-restrict-anonymous-access-to-named-pipes-and-shares.md
@@ -2,48 +2,29 @@
title: Network access Restrict anonymous access to Named Pipes and Shares (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Network access Restrict anonymous access to Named Pipes and Shares security policy setting.
ms.assetid: e66cd708-7322-4d49-9b57-1bf8ec7a4c10
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Network access: Restrict anonymous access to Named Pipes and Shares
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **Network access: Restrict anonymous access to Named Pipes and Shares** security policy setting.
-
## Reference
-
-
This policy setting enables or disables the restriction of anonymous access to only those shared folders and pipes that are named in the **Network access: Named pipes that can be accessed anonymously** and [Network access: Shares that can be accessed anonymously](network-access-shares-that-can-be-accessed-anonymously.md) settings. The setting controls null session access to shared folders on your computers by adding RestrictNullSessAccess with the value 1 in the registry key **HKEY\_LOCAL\_MACHINE\\System\\CurrentControlSet\\Services\\LanManServer\\Parameters**. This registry value toggles null session shared folders on or off to control whether the Server service restricts unauthenticated clients' access to named resources.
-
Null sessions are a weakness that can be exploited through the various shared folders on the devices in your environment.
-
### Possible values
-
- Enabled
-
- Disabled
-
- Not defined
-
### Best practices
-
- Set this policy to Enabled. Enabling this policy setting restricts null session access to unauthenticated users to all server pipes and shared folders except those listed in the **NullSessionPipes** and **NullSessionShares** registry entries.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -82,45 +63,20 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Null sessions are a weakness that can be exploited through shared folders (including the default shared folders) on devices in your environment.
-
### Countermeasure
-
Enable the **Network access: Restrict anonymous access to Named Pipes and Shares** setting.
-
### Potential impact
-
You can enable this policy setting to restrict null-session access for unauthenticated users to all server pipes and shared folders except those that are listed in the NullSessionPipes and NullSessionShares entries.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/network-access-shares-that-can-be-accessed-anonymously.md b/windows/keep-secure/network-access-shares-that-can-be-accessed-anonymously.md
index 14290aa358..604898a019 100644
--- a/windows/keep-secure/network-access-shares-that-can-be-accessed-anonymously.md
+++ b/windows/keep-secure/network-access-shares-that-can-be-accessed-anonymously.md
@@ -2,44 +2,27 @@
title: Network access Shares that can be accessed anonymously (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Network access Shares that can be accessed anonymously security policy setting.
ms.assetid: f3e4b919-8279-4972-b415-5f815e2f0a1a
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Network access: Shares that can be accessed anonymously
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **Network access: Shares that can be accessed anonymously** security policy setting.
-
## Reference
-
-
This policy setting determines which shared folders can be accessed by anonymous users.
-
### Possible values
-
- User-defined list of shared folders
-
- Not Defined
-
### Best practices
-
- Set this policy to a null value. There should be little impact because this is the default value. All users will have to be authenticated before they can access shared resources on the server.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -78,45 +61,20 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Any shared folders that are listed can be accessed by any network user, which could lead to the exposure or corruption of sensitive data.
-
### Countermeasure
-
Configure the **Network access: Shares that can be accessed anonymously** setting to a null value.
-
### Potential impact
-
There should be little impact because this is the default configuration. Only authenticated users have access to shared resources on the server.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/network-access-sharing-and-security-model-for-local-accounts.md b/windows/keep-secure/network-access-sharing-and-security-model-for-local-accounts.md
index e76dbe2316..c1f32eb9c3 100644
--- a/windows/keep-secure/network-access-sharing-and-security-model-for-local-accounts.md
+++ b/windows/keep-secure/network-access-sharing-and-security-model-for-local-accounts.md
@@ -2,57 +2,34 @@
title: Network access Sharing and security model for local accounts (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Network access Sharing and security model for local accounts security policy setting.
ms.assetid: 0b3d703c-ea27-488f-8f59-b345af75b994
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Network access: Sharing and security model for local accounts
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **Network access: Sharing and security model for local accounts** security policy setting.
-
## Reference
-
-
This policy setting determines how network logons that use local accounts are authenticated. If you configure this policy setting to Classic, network logons that use local account credentials authenticate with those credentials. If you configure this policy setting to Guest only, network logons that use local accounts are automatically mapped to the Guest account. The Classic model provides precise control over access to resources, and it enables you to grant different types of access to different users for the same resource. Conversely, the Guest only model treats all users equally, and they all receive the same level of access to a given resource, which can be either Read Only or Modify.
-
**Note**
This policy setting does not affect network logons that use domain accounts. Nor does this policy setting affect interactive logons that are performed remotely through services such as Telnet or Remote Desktop Services.
-
When the device is not joined to a domain, this policy setting also tailors the **Sharing** and **Security** tabs in Windows Explorer to correspond to the sharing and security model that is being used.
-
-
When the value of this policy setting is **Guest only - local users authenticate as Guest**, any user who can access your device over the network does so with Guest user rights. This means that they will probably be unable to write to shared folders. Although this does increase security, it makes it impossible for authorized users to access shared resources on those systems. When the value is **Classic - local users authenticate as themselves**, local accounts must be password-protected; otherwise, anyone can use those user accounts to access shared system resources.
-
### Possible values
-
- Classic - Local users authenticate as themselves
-
- Guest only - Local users authenticate as Guest
-
- Not defined
-
### Best practices
-
1. For network servers, set this policy to **Classic - local users authenticate as themselves**.
-
2. On end-user systems, set this policy to **Guest only - local users authenticate as Guest**.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -91,49 +68,22 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Group Policy
-
This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
With the Guest only model, any user who can authenticate to your device over the network does so with Guest privileges, which probably means that they do not have Write access to shared resources on that device. Although this restriction does increase security, it makes it more difficult for authorized users to access shared resources on those computers because ACLs on those resources must include access control entries (ACEs) for the Guest account. With the Classic model, local accounts should be password protected. Otherwise, if Guest access is enabled, anyone can use those user accounts to access shared system resources.
-
### Countermeasure
-
For network servers, configure the **Network access: Sharing and security model for local accounts setting** to **Classic – local users authenticate as themselves**. On end-user computers, configure this policy setting to **Guest only – local users authenticate as guest**.
-
### Potential impact
-
None. This is the default configuration.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/network-list-manager-policies.md b/windows/keep-secure/network-list-manager-policies.md
index 82b2e0ecd4..931739dc93 100644
--- a/windows/keep-secure/network-list-manager-policies.md
+++ b/windows/keep-secure/network-list-manager-policies.md
@@ -2,96 +2,50 @@
title: Network List Manager policies (Windows 10)
description: Network List Manager policies are security settings that you can use to configure different aspects of how networks are listed and displayed on one device or on many devices.
ms.assetid: bd8109d4-b07c-4beb-a9a6-affae2ba2fda
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Network List Manager policies
-
-
**Applies to**
-
- Windows 10
-
Network List Manager policies are security settings that you can use to configure different aspects of how networks are listed and displayed on one device or on many devices.
-
To configure Network List Manager Policies for one device, you can use the Microsoft Management Console (MMC) with the Group Policy Object Editor snap-in, and edit the local computer policy. The Network List Manager Policies are located at the following path in Group Policy Object Editor:
-
**Computer Configuration | Windows Settings | Security Settings | Network List Manager Policies**
-
To configure Network List Manager Policies for many computers, such as for all of the Domain Computers in an Active Directory domain, follow Group Policy documentation to learn how to edit the policies for the object that you require. The path to the Network List Manager Policies is the same as the path listed above.
-
### Policy settings for Network List Manager Policies
-
The following policy settings are provided for Network List Manager Policies. These policy settings are located in the details pane of the Group Policy Object Editor, in **Network Name**.
-
### Unidentified Networks
-
This policy setting allows you to configure the **Network Location**, including the location type and the user permissions, for networks that Windows cannot identify due to a network issue or a lack of identifiable characters in the network information received by the operating system from the network. A network location identifies the type of network that a computer is connected to and automatically sets the appropriate firewall settings for that location. You can configure the following items for this policy setting:
-
- **Location type**. For this item, the following options are available:
-
- **Not configured**. If you select this option, this policy setting does not apply a location type to unidentified network connections.
-
- **Private**. If you select this option, this policy setting applies a location type of Private to unidentified network connections. A private network, such as a home or work network, is a location type that assumes that you trust the other computers on the network. Do not select this item if there is a possibility that an active, unidentified network is in a public place.
-
- **Public**. If you select this option, this policy setting applies a location type of Public to unidentified network connections. A public network, such as a wireless network at an airport or coffee shop, is a location type that assumes that you do not trust the other computers on the network.
-
- **User permissions**. For this item, the following options are available:
-
- **Not configured**. If you select this option, this policy setting does not specify whether users can change the location for unidentified network connections.
-
- **User can change location**. If you select this option, this policy setting allows users to change an unidentified network connection location from Private to Public or from Public to Private.
-
- **User cannot change location**. If you select this option, this policy setting does not allow users to change the location of an unidentified network connection.
-
### Identifying Networks
-
This policy setting allows you to configure the **Network Location** for networks that are in a temporary state while Windows works to identify the network and location type. A network location identifies the type of network that a computer is connected to and automatically sets the appropriate firewall settings for that location. You can configure the following items for this policy setting:
-
- **Location type**. For this item, the following options are available:
-
- **Not configured**. If you select this option, this policy setting does not apply a location type to network connections that are in the process of being identified by Windows.
-
- **Private**. If you select this option, this policy setting applies a location type of Private to network connections that are in the process of being identified. A private network, such as a home or work network, is a location type that assumes that you trust the other devices on the network. Do not select this item if there is a possibility that an active, unidentified network is in a public place.
-
- **Public**. If you select this option, this policy setting applies a location type of Public to network connections that are in the process of being identified by Windows. A public network, such as a wireless network at an airport or coffee shop, is a location type that assumes that you do not trust the other devices on the network.
-
### All Networks
-
This policy setting allows you to specify the **User Permissions** that control whether users can change the network name, location, or icon, for all networks to which the user connects. You can configure the following items for this policy setting:
-
- **Network name**. For this item, the following options are available:
-
- **Not configured**. If you select this option, this policy setting does not specify whether users can change the network name for all network connections.
-
- **User can change name**. If you select this option, users can change the network name for all networks to which they connect.
-
- **User cannot change name**. If you select this option, users cannot change the network name for any networks to which they connect.
-
- **Network location**. For this item, the following options are available:
-
- **Not configured**. If you select this option, this policy setting does not specify whether users can change the location for all network connections.
-
- **User can change location**. If you select this option, this policy setting allows users to change all network locations from Private to Public or from Public to Private.
-
- **User cannot change location**. If you select this option, this policy setting does not allow users to change the location for any networks to which they connect.
-
- **Network icon**. For this item, the following options are available:
-
- **Not configured**. If you select this option, this policy setting does not specify whether users can change the network icon for all network connections.
-
- **User can change icon**. If you select this option, this policy setting allows users to change the network icon for all networks to which the user connects.
-
- **User cannot change icon**. If you select this option, this policy setting does not allow users to change the network icon for any networks to which the user connects.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/network-security-allow-local-system-to-use-computer-identity-for-ntlm.md b/windows/keep-secure/network-security-allow-local-system-to-use-computer-identity-for-ntlm.md
index 3933e3f9ff..532768f78b 100644
--- a/windows/keep-secure/network-security-allow-local-system-to-use-computer-identity-for-ntlm.md
+++ b/windows/keep-secure/network-security-allow-local-system-to-use-computer-identity-for-ntlm.md
@@ -2,30 +2,20 @@
title: Network security Allow Local System to use computer identity for NTLM (Windows 10)
description: Describes the location, values, policy management, and security considerations for the Network security Allow Local System to use computer identity for NTLM security policy setting.
ms.assetid: c46a658d-b7a4-4139-b7ea-b9268c240053
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Network security: Allow Local System to use computer identity for NTLM
-
-
**Applies to**
-
- Windows 10
-
Describes the location, values, policy management, and security considerations for the **Network security: Allow Local System to use computer identity for NTLM** security policy setting.
-
## Reference
-
-
When services connect to devices that are running versions of the Windows operating system earlier than Windows Vista or Windows Server 2008, services that run as Local System and use SPNEGO (Negotiate) that revert to NTLM will authenticate anonymously. In Windows Server 2008 R2 and Windows 7 and later, if a service connects to a computer running Windows Server 2008 or Windows Vista, the system service uses the computer identity.
-
When a service connects with the device identity, signing and encryption are supported to provide data protection. (When a service connects anonymously, a system-generated session key is created, which provides no protection, but it allows applications to sign and encrypt data without errors. Anonymous authentication uses a NULL session, which is a session with a server in which no user authentication is performed; and therefore, anonymous access is allowed.)
-
### Possible values
-
@@ -57,17 +47,11 @@ When a service connects with the device identity, signing and encryption are sup
-
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -106,59 +90,27 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Policy conflict considerations
-
The policy [Network security: Allow LocalSystem NULL session fallback](network-security-allow-localsystem-null-session-fallback.md), if enabled, will allow NTLM or Kerberos authentication to be used when a system service attempts authentication. This will increase the success of interoperability at the expense of security.
-
The anonymous authentication behavior is different for Windows Server 2008 and Windows Vista than later versions of Windows. Configuring and applying this policy setting on those systems might not produce the same results.
-
### Group Policy
-
This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
When a service connects to computers running versions of Windows earlier than Windows Vista or Windows Server 2008, services that run as Local System and use SPNEGO (Negotiate) that revert to NTLM will use NULL session. In Windows Server 2008 R2 and Windows 7 and later, if a service connects to a computer running Windows Server 2008 or Windows Vista, the system service uses the computer identity.
-
When a service connects with the computer identity, signing and encryption are supported to provide data protection. When a service connects with a NULL session, a system-generated session key is created, which provides no protection, but it allows applications to sign and encrypt data without errors.
-
### Countermeasure
-
You can configure the **Network security: Allow Local System to use computer identity for NTLM** security policy setting to allow Local System services that use Negotiate to use the computer identity when reverting to NTLM authentication.
-
### Potential impact
-
If you do not configure this policy setting on Windows Server 2008 and Windows Vista, services running as Local System that use the default credentials will use the NULL session and revert to NTLM authentication for Windows operating systems earlier than Windows Vista or Windows Server 2008.
-
Beginning with Windows Server 2008 R2 and Windows 7, the system allows Local System services that use Negotiate to use the computer identity when reverting to NTLM authentication.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/network-security-allow-localsystem-null-session-fallback.md b/windows/keep-secure/network-security-allow-localsystem-null-session-fallback.md
index ca4c87257c..393c0a9382 100644
--- a/windows/keep-secure/network-security-allow-localsystem-null-session-fallback.md
+++ b/windows/keep-secure/network-security-allow-localsystem-null-session-fallback.md
@@ -2,50 +2,30 @@
title: Network security Allow LocalSystem NULL session fallback (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Network security Allow LocalSystem NULL session fallback security policy setting.
ms.assetid: 5b72edaa-bec7-4572-b6f0-648fc38f5395
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Network security: Allow LocalSystem NULL session fallback
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **Network security: Allow LocalSystem NULL session fallback** security policy setting.
-
## Reference
-
-
This policy affects session security during the authentication process between devices running Windows Server 2008 R2 and Windows 7 and later and those devices running earlier versions of the Windows operating system. For computers running Windows Server 2008 R2 and Windows 7 and later, services running as Local System require a service principal name (SPN) to generate the session key. However, if [Network security: Allow Local System to use computer identity for NTLM](network-security-allow-local-system-to-use-computer-identity-for-ntlm.md) is set to disabled, services running as Local System will fall back to using NULL session authentication when they transmit data to servers running versions of Windows earlier than Windows Vista or Windows Server 2008. NULL session does not establish a unique session key for each authentication; and thus, it cannot provide integrity or confidentiality protection. The setting **Network security: Allow LocalSystem NULL session fallback** determines whether services that request the use of session security are allowed to perform signature or encryption functions with a well-known key for application compatibility.
-
### Possible values
-
- **Enabled**
-
When a service running as Local System connects with a NULL session, a system-generated session key is created, which provides no protection but allows applications to sign and encrypt data without errors. This increases application compatibility, but it degrades the level of security.
-
- **Disabled**
-
When a service running as Local System connects with a NULL session, session security will be unavailable. Calls seeking encryption or signing will fail. This setting is more secure, but at the risk of degrading application incompatibility. Calls that are using the device identity instead of a NULL session will still have full use of session security.
-
- Not defined. When this policy is not defined, the default takes effect. This is Enabled for versions of the Windows operating system earlier than Windows Server 2008 R2 and Windows 7, and it is Disabled otherwise.
-
### Best practices
-
When services connect with the device identity, signing and encryption are supported to provide data protection. When services connect with a NULL session, this level of data protection is not provided. However, you will need to evaluate your environment to determine the Windows operating system versions that you support. If this policy is enabled, some services may not be able to authenticate.
-
This policy applies to Windows Server 2008 and Windows Vista (SP1 and later). When your environment no longer requires support for Windows NT 4, this policy should be disabled. By default, it is disabled in Windows 7 and Windows Server 2008 R2 and later.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
@@ -84,36 +64,16 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Sec
-
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
If this setting is Enabled, when a service connects with a NULL session, a system-generated session key is created, which provides no protection but allows applications to sign and encrypt data without errors. Data that is intended to be protected might be exposed.
-
### Countermeasure
-
You can configure the computer to use the computer identity for Local System with the policy **Network security: Allow Local System to use computer identity for NTLM**. If that is not possible, this policy can be used to prevent data from being exposed in transit if it was protected with a well-known key.
-
### Potential impact
-
If you enable this policy, services that use NULL session with Local System could fail to authenticate because they will be prohibited from using signing and encryption.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/network-security-allow-pku2u-authentication-requests-to-this-computer-to-use-online-identities.md b/windows/keep-secure/network-security-allow-pku2u-authentication-requests-to-this-computer-to-use-online-identities.md
index 7072c876dd..a5ffb6243d 100644
--- a/windows/keep-secure/network-security-allow-pku2u-authentication-requests-to-this-computer-to-use-online-identities.md
+++ b/windows/keep-secure/network-security-allow-pku2u-authentication-requests-to-this-computer-to-use-online-identities.md
@@ -2,59 +2,35 @@
title: Network security Allow PKU2U authentication requests to this computer to use online identities (Windows 10)
description: Describes the best practices, location, and values for the Network Security Allow PKU2U authentication requests to this computer to use online identities security policy setting.
ms.assetid: e04a854e-d94d-4306-9fb3-56e9bd7bb926
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Network security: Allow PKU2U authentication requests to this computer to use online identities
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, and values for the **Network Security: Allow PKU2U authentication requests to this computer to use online identities** security policy setting.
-
## Reference
-
-
Starting with Windows Server 2008 R2 and Windows 7, the Negotiate Security Support Provider (SSP) supports an extension SSP, Negoexts.dll. This extension SSP is treated as an authentication protocol by the Windows operating system, and it supports SSPs from Microsoft, including PKU2U. You can also develop or add other SSPs.
-
When devices are configured to accept authentication requests by using online IDs, Negoexts.dll calls the PKU2U SSP on the computer that is used to log on. The PKU2U SSP obtains a local certificate and exchanges the policy between the peer computers. When validated on the peer computer, the certificate within the metadata is sent to the logon peer for validation. It associates the user's certificate to a security token, and then the logon process completes.
-
**Note**
The ability to link online IDs can be performed by anyone with an account that has standard user’s credentials through **Credential Manager**.
-
-
This policy is not configured by default on domain-joined devices. This would disallow the online identities to be able to authenticate to the domain-joined computers in Windows 7 and later.
-
### Possible values
-
- **Enabled**
-
This will allow authentication to successfully complete between the two (or more) computers that have established a peer relationship through the use on online IDs. The PKU2U SSP obtains a local certificate and exchanges the policy between the peer devices. When validated on the peer computer, the certificate within the metadata is sent to the logon peer for validation. It associates the user's certificate to a security token, and then the logon process completes.
-
- **Disabled**
-
This will prevent online IDs from being used to authenticate the user to another computer in a peer-to-peer relationship.
-
- Not set. Not configuring this policy prevents online IDs from being used to authenticate the user. This is the default on domain-joined devices
-
### Best practices
-
Within a domain, domain accounts should be used for authentication. Set this policy to **Disabled** or do not configure this policy to exclude online identities from being used to authenticate.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -93,36 +69,16 @@ The following table lists the actual and effective default values for this polic
-
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Enabling this policy setting allows a user’s account on one computer to be associated with an online identity, such as Microsoft Account, so that account can log on to a peer device (if the peer device is likewise configured) without the use of a Windows logon account (domain or local). Although this is beneficial for workgroups or home groups, using this feature in a domain-joined environment might circumvent your established security policies.
-
### Countermeasure
-
Set this policy to Disabled or do not configure this security policy for domain-joined devices.
-
### Potential impact
-
If you do not set or disable this policy, the PKU2U protocol will not be used to authenticate between peer devices, which forces users to follow domain defined access control policies. If you enable this policy, you will allow your users to authenticate by using local certificates between systems that are not part of a domain that uses PKU2U. This will allow users to share resources between devices
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/network-security-configure-encryption-types-allowed-for-kerberos.md b/windows/keep-secure/network-security-configure-encryption-types-allowed-for-kerberos.md
index 981f5cdd24..6fa8240e2e 100644
--- a/windows/keep-secure/network-security-configure-encryption-types-allowed-for-kerberos.md
+++ b/windows/keep-secure/network-security-configure-encryption-types-allowed-for-kerberos.md
@@ -2,30 +2,20 @@
title: Network security Configure encryption types allowed for Kerberos Win7 only (Windows 10)
description: Describes the best practices, location, values and security considerations for the Network security Configure encryption types allowed for Kerberos Win7 only security policy setting.
ms.assetid: 303d32cc-415b-44ba-96c0-133934046ece
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Network security: Configure encryption types allowed for Kerberos Win7 only
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values and security considerations for the **Network security: Configure encryption types allowed for Kerberos Win7 only** security policy setting.
-
## Reference
-
-
This policy setting allows you to set the encryption types that the Kerberos protocol is allowed to use. If it is not selected, the encryption type will not be allowed. This setting might affect compatibility with client computers or services and applications. Multiple selections are permitted.
-
For more information, see [article 977321](http://support.microsoft.com/kb/977321) in the Microsoft Knowledge Base.
-
The following table lists and explains the allowed encryption types.
-
@@ -69,37 +59,21 @@ The following table lists and explains the allowed encryption types.
-
-
### Possible values
-
The encryption type options include:
-
- DES\_CBC\_CRC
-
- DES\_CBC\_MD5
-
- RC4\_HMAC\_MD5
-
- AES128\_HMAC\_SHA1
-
- AES256\_HMAC\_SHA1
-
- Future encryption types
-
As of the release of Windows 7 and Windows Server 2008 R2, this is reserved by Microsoft for additional encryption types that might be implemented.
-
### Best practices
-
You must analyze your environment to determine which encryption types will be supported and then select those that meet that evaluation.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
@@ -138,40 +112,18 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Sec
-
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Windows Server 2008 R2 and Windows 7 do not support the DES cryptographic suites because stronger ones are available. To enable Kerberos interoperability with non-Windows versions of the Kerberos protocol, these suites can be enabled. However, doing so might open attack vectors on computers running Windows Server 2008 R2 and Windows 7. You can also disable DES for your computers running Windows Vista and Windows Server 2008.
-
### Countermeasure
-
Do not configure this policy. This will force the computers running Windows Server 2008 R2 and Windows 7 to use the AES or RC4 cryptographic suites.
-
### Potential impact
-
If you do not select any of the encryption types, computers running Windows Server 2008 R2 and Windows 7 might have Kerberos authentication failures when connecting with computers running non-Windows versions of the Kerberos protocol.
-
If you do select any encryption type, you will lower the effectiveness of encryption for Kerberos authentication but you will improve interoperability with computers running older versions of Windows.
-
Contemporary non-Windows implementations of the Kerberos protocol support RC4 and AES 128-bit and AES 256-bit encryption. Most implementations, including the MIT Kerberos protocol and the Windows Kerberos protocol, are deprecating DES encryption.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/network-security-do-not-store-lan-manager-hash-value-on-next-password-change.md b/windows/keep-secure/network-security-do-not-store-lan-manager-hash-value-on-next-password-change.md
index 2585a9b1fe..97a0897fcf 100644
--- a/windows/keep-secure/network-security-do-not-store-lan-manager-hash-value-on-next-password-change.md
+++ b/windows/keep-secure/network-security-do-not-store-lan-manager-hash-value-on-next-password-change.md
@@ -2,50 +2,30 @@
title: Network security Do not store LAN Manager hash value on next password change (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Network security Do not store LAN Manager hash value on next password change security policy setting.
ms.assetid: 6452b268-e5ba-4889-9d38-db28f919af51
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Network security: Do not store LAN Manager hash value on next password change
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **Network security: Do not store LAN Manager hash value on next password change** security policy setting.
-
## Reference
-
-
This policy setting determines whether LAN Manager is prevented from storing hash values for the new password the next time the password is changed. Hash values are a representation of the password after the encryption algorithm is applied that corresponds to the format that is specified by the algorithm. To decrypt the hash value, the encryption algorithm must be determined and then reversed. The LAN Manager hash is relatively weak and prone to attack compared to the cryptographically stronger NTLM hash. Because the LM hash is stored on the local device in the security database, the passwords can be compromised if the security database, Security Accounts Manager (SAM), is attacked.
-
By attacking the SAM file, attackers can potentially gain access to user names and password hashes. Attackers can use a password-cracking tool to determine what the password is. After they have access to this information, they can use it to gain access to resources on your network by impersonating users. Enabling this policy setting will not prevent these types of attacks, but it will make them much more difficult.
-
### Possible values
-
- Enabled
-
- Disabled
-
- Not defined
-
### Best practices
-
1. Set **Network security: Do not store LAN Manager hash value on next password change** to **Enabled**.
-
2. Require all users to set new passwords the next time they log on to the domain so that LAN Manager hashes are removed.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -84,45 +64,20 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
The SAM file can be targeted by attackers who seek access to user names and password hashes. Such attacks use special tools to discover passwords, which can then be used to impersonate users and gain access to resources on your network. These types of attacks are not prevented by enabling this policy setting because LAN Manager hashes are much weaker than NTLM hashes, but it is much more difficult for these attacks to succeed.
-
### Countermeasure
-
Enable the **Network security: Do not store LAN Manager hash value on next password change** setting. Require all users to set new passwords the next time they log on to the domain so that LAN Manager hashes are removed.
-
### Potential impact
-
Some non-Microsoft applications might not be able to connect to the system.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/network-security-force-logoff-when-logon-hours-expire.md b/windows/keep-secure/network-security-force-logoff-when-logon-hours-expire.md
index 2b6ab3ada7..410ead1171 100644
--- a/windows/keep-secure/network-security-force-logoff-when-logon-hours-expire.md
+++ b/windows/keep-secure/network-security-force-logoff-when-logon-hours-expire.md
@@ -2,52 +2,31 @@
title: Network security Force logoff when logon hours expire (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Network security Force logoff when logon hours expire security policy setting.
ms.assetid: 64d5dde4-58e4-4217-b2c4-73bd554ec926
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Network security: Force logoff when logon hours expire
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **Network security: Force logoff when logon hours expire** security policy setting.
-
## Reference
-
-
This security setting determines whether to disconnect users who are connected to the local device outside their user account's valid logon hours. This setting affects the Server Message Block (SMB) component.
-
This policy setting does not apply to administrator accounts, but it behaves as an account policy. For domain accounts, there can be only one account policy. The account policy must be defined in the Default Domain Policy, and it is enforced by the domain controllers that make up the domain. A domain controller always pulls the account policy from the Default Domain Policy Group Policy Object (GPO), even if there is a different account policy that is applied to the organizational unit that contains the domain controller. By default, workstations and servers that are joined to a domain (for example, member devices) also receive the same account policy for their local accounts. However, local account policies for member devices can be different from the domain account policy by defining an account policy for the organizational unit that contains the member devices. Kerberos settings are not applied to member devices.
-
### Possible values
-
- Enabled
-
When enabled, this policy causes client sessions with the SMB server to be forcibly disconnected when the client's logon hours expire.
-
- Disabled
-
When disabled, this policy allows for the continuation of an established client session after the client's logon hours have expired.
-
- Not defined
-
### Best practices
-
- Set **Network security: Force logoff when logon hours expire** to Enabled. SMB sessions will be terminated on member servers when a user's logon time expires, and the user will be unable to log on to the system until their next scheduled access time begins.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -86,45 +65,20 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
If you disable this policy setting, users can remain connected to the computer outside of their allotted logon hours.
-
### Countermeasure
-
Enable the **Network security: Force logoff when logon hours expire** setting. This policy setting does not apply to administrator accounts.
-
### Potential impact
-
When a user's logon time expires, SMB sessions terminate. The user cannot log on to the device until the next scheduled access time commences.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/network-security-lan-manager-authentication-level.md b/windows/keep-secure/network-security-lan-manager-authentication-level.md
index 5915894ae2..1b3103d943 100644
--- a/windows/keep-secure/network-security-lan-manager-authentication-level.md
+++ b/windows/keep-secure/network-security-lan-manager-authentication-level.md
@@ -2,56 +2,33 @@
title: Network security LAN Manager authentication level (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Network security LAN Manager authentication level security policy setting.
ms.assetid: bbe1a98c-420a-41e7-9d3c-3a2fe0f1843e
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Network security: LAN Manager authentication level
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **Network security: LAN Manager authentication level** security policy setting.
-
## Reference
-
-
This policy setting determines which challenge or response authentication protocol is used for network logons. LAN Manager (LM) includes client computer and server software from Microsoft that allows users to link personal devices together on a single network. Network capabilities include transparent file and print sharing, user security features, and network administration tools. In Active Directory domains, the Kerberos protocol is the default authentication protocol. However, if the Kerberos protocol is not negotiated for some reason, Active Directory uses LM, NTLM, or NTLM version 2 (NTLMv2).
-
LAN Manager authentication includes the LM, NTLM, and NTLMv2 variants, and it is the protocol that is used to authenticate all client devices running the Windows operating system when they perform the following operations:
-
- Join a domain
-
- Authenticate between Active Directory forests
-
- Authenticate to domains based on earlier versions of the Windows operating system
-
- Authenticate to computers that do not run Windows operating systems, beginning with Windows 2000
-
- Authenticate to computers that are not in the domain
-
### Possible values
-
- Send LM & NTLM responses
-
- Send LM & NTLM - use NTLMv2 session security if negotiated
-
- Send NTLM responses only
-
- Send NTLMv2 responses only
-
- Send NTLMv2 responses only. Refuse LM
-
- Send NTLMv2 responses only. Refuse LM & NTLM
-
- Not Defined
-
The **Network security: LAN Manager authentication level** setting determines which challenge/response authentication protocol is used for network logons. This choice affects the authentication protocol level that clients use, the session security level that the computers negotiate, and the authentication level that servers accept. The following table identifies the policy settings, describes the setting, and identifies the security level used in the corresponding registry setting if you choose to use the registry to control this setting instead of the policy setting.
-
@@ -98,21 +75,13 @@ The **Network security: LAN Manager authentication level** setting determines wh
-
-
### Best practices
-
- Best practices are dependent on your specific security and authentication requirements.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -151,49 +120,22 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Group Policy
-
Modifying this setting may affect compatibility with client devices, services, and applications.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
In Windows 7 and Windows Vista, this setting is undefined. In Windows Server 2008 R2 and later, this setting is configured to **Send NTLMv2 responses only**.
-
### Countermeasure
-
Configure the **Network security: LAN Manager Authentication Level** setting to **Send NTLMv2 responses only**. Microsoft and a number of independent organizations strongly recommend this level of authentication when all client computers support NTLMv2.
-
### Potential impact
-
Client devices that do not support NTLMv2 authentication cannot authenticate in the domain and access domain resources by using LM and NTLM.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/network-security-ldap-client-signing-requirements.md b/windows/keep-secure/network-security-ldap-client-signing-requirements.md
index ed336b244a..533858f613 100644
--- a/windows/keep-secure/network-security-ldap-client-signing-requirements.md
+++ b/windows/keep-secure/network-security-ldap-client-signing-requirements.md
@@ -2,56 +2,33 @@
title: Network security LDAP client signing requirements (Windows 10)
description: This security policy reference topic for the IT professional describes the best practices, location, values, policy management and security considerations for this policy setting.
ms.assetid: 38b35489-eb5b-4035-bc87-df63de50509c
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Network security: LDAP client signing requirements
-
-
**Applies to**
-
- Windows 10
-
This security policy reference topic for the IT professional describes the best practices, location, values, policy management and security considerations for this policy setting. This information applies to computers running at least the Windows Server 2008 operating system.
-
## Reference
-
-
This policy setting determines the level of data signing that is requested on behalf of client devices that issue LDAP BIND requests. The levels of data signing are described in the following list:
-
- **None**. The LDAP BIND request is issued with the caller-specified options.
-
- **Negotiate signing**. If Transport Layer Security/Secure Sockets Layer (TLS/SSL) has not been started, the LDAP BIND request is initiated with the LDAP data signing option set in addition to the caller-specified options. If TLS/SSL has been started, the LDAP BIND request is initiated with the caller-specified options.
-
- **Require signing**. This level is the same as **Negotiate signing**. However, if the LDAP server's intermediate saslBindInProgress response does not indicate that LDAP traffic signing is required, the caller is returned a message that the LDAP BIND command request failed.
-
Misuse of this policy setting is a common error that can cause data loss or problems with data access or security.
-
### Possible values
-
- None
-
- Negotiate signing
-
- Require signature
-
- Not Defined
-
### Best practices
-
- Set **Domain controller: LDAP server signing requirements** to **Require signature**. If you set the server to require LDAP signatures, you must also set the client devices to do so. Not setting the client devices will prevent client computers from communicating with the server. This can cause many features to fail, including user authentication, Group Policy, and logon scripts.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -90,49 +67,22 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Group Policy
-
Modifying this setting may affect compatibility with client devices, services, and applications.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Unsigned network traffic is susceptible to man-in-the-middle attacks in which an intruder captures the packets between the client computer and server, modifies them, and then forwards them to the server. For an LDAP server, this susceptibility means that an attacker could cause a server to make decisions that are based on false or altered data from the LDAP queries. To lower this risk in your network, you can implement strong physical security measures to protect the network infrastructure. Also, you can make all types of man-in-the-middle attacks extremely difficult if you require digital signatures on all network packets by means of IPsec authentication headers.
-
### Countermeasure
-
Configure the **Network security: LDAP server signing requirements** setting to **Require signature**.
-
### Potential impact
-
If you configure the server to require LDAP signatures, you must also configure the client computers. If you do not configure the client devices, they cannot communicate with the server, which could cause many features to fail, including user authentication, Group Policy, and logon scripts.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-clients.md b/windows/keep-secure/network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-clients.md
index 0f6aa65a9c..1fcbb6bbc4 100644
--- a/windows/keep-secure/network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-clients.md
+++ b/windows/keep-secure/network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-clients.md
@@ -2,48 +2,29 @@
title: Network security Minimum session security for NTLM SSP based (including secure RPC) clients (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Network security Minimum session security for NTLM SSP based (including secure RPC) clients security policy setting.
ms.assetid: 89903de8-23d0-4e0f-9bef-c00cb7aebf00
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Network security: Minimum session security for NTLM SSP based (including secure RPC) clients
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **Network security: Minimum session security for NTLM SSP based (including secure RPC) clients** security policy setting.
-
## Reference
-
-
This policy setting allows a client device to require the negotiation of 128-bit encryption or NTLMv2 session security. These values are dependent on the **Network security: LAN Manager Authentication Level policy** setting value.
-
### Possible values
-
- Require NTLMv2 session security
-
The connection fails if strong encryption (128-bit) is not negotiated.
-
- Require 128-bit encryption
-
The connection fails if the NTLMv2 protocol is not negotiated.
-
### Best practices
-
Practices in setting this policy are dependent on your security requirements.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -82,49 +63,22 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Policy conflicts
-
The settings for this security policy are dependent on the **Network security: LAN Manager Authentication Level policy** setting value. For info about this policy, see [Network security: LAN Manager authentication level](network-security-lan-manager-authentication-level.md).
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Network traffic that uses the NTLM Security Support Provider (NTLM SSP) could be exposed such that an attacker who has gained access to the network can create man-in-the-middle attacks.
-
### Countermeasure
-
Enable all options that are available for the **Network security: Minimum session security for NTLM SSP based (including secure RPC) clients policy** setting.
-
### Potential impact
-
Client devices that enforce these settings cannot communicate with older servers that do not support them.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-servers.md b/windows/keep-secure/network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-servers.md
index 09698504bc..581c58aa2d 100644
--- a/windows/keep-secure/network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-servers.md
+++ b/windows/keep-secure/network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-servers.md
@@ -2,48 +2,29 @@
title: Network security Minimum session security for NTLM SSP based (including secure RPC) servers (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Network security Minimum session security for NTLM SSP based (including secure RPC) servers security policy setting.
ms.assetid: c6a60c1b-bc8d-4d02-9481-f847a411b4fc
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Network security: Minimum session security for NTLM SSP based (including secure RPC) servers
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **Network security: Minimum session security for NTLM SSP based (including secure RPC) servers** security policy setting.
-
## Reference
-
-
This policy setting allows a client device to require the negotiation of 128-bit encryption or NTLMv2 session security. These values are dependent on the [Network security: LAN Manager authentication level](network-security-lan-manager-authentication-level.md) policy setting value.
-
Setting all of these values for this policy setting will help protect network traffic that uses the NTLM Security Support Provider (NTLM SSP) from being exposed or tampered with by a malicious user who has gained access to the same network. That is, these settings help protect against man-in-the-middle attacks.
-
### Possible values
-
- Require 128-bit encryption. The connection fails if strong encryption (128-bit) is not negotiated.
-
- Require NTLMv2 session security. The connection fails if the NTLMv2 protocol is not negotiated.
-
- Not Defined.
-
### Best practices
-
- Enable all values that are available for this security policy. Legacy client devices that do not support these policy settings will be unable to communicate with the server.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -82,49 +63,22 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Policy dependencies
-
The settings for this security policy are dependent on the [Network security: LAN Manager authentication level](network-security-lan-manager-authentication-level.md) setting value.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Network traffic that uses the NTLM Security Support Provider (NTLM SSP) could be exposed such that an attacker who has gained access to the network can create man-in-the-middle attacks.
-
### Countermeasure
-
Enable all options that are available for the **Network security: Minimum session security for NTLM SSP based (including secure RPC) servers** policy setting.
-
### Potential impact
-
Older client devices that do not support these security settings cannot communicate with the computer on which this policy is set.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication.md b/windows/keep-secure/network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication.md
index cd2bf1d88c..64151c9c05 100644
--- a/windows/keep-secure/network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication.md
+++ b/windows/keep-secure/network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication.md
@@ -2,54 +2,32 @@
title: Network security Restrict NTLM Add remote server exceptions for NTLM authentication (Windows 10)
description: Describes the best practices, location, values, management aspects, and security considerations for the Network security Restrict NTLM Add remote server exceptions for NTLM authentication security policy setting.
ms.assetid: 9b017399-0a54-4580-bfae-614c2beda3a1
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, management aspects, and security considerations for the **Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication** security policy setting.
-
## Reference
-
-
The **Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication** policy setting allows you to create an exception list of remote servers to which client devices are allowed to use NTLM authentication if the [Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers](network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md) policy setting is configured.
-
If you configure this policy setting, you can define a list of remote servers to which client devices are allowed to use NTLM authentication.
-
If you do not configure this policy setting, no exceptions will be applied, and if [Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers](network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md) is enabled, NTLM authentication attempts from the client devices will fail.
-
List the NetBIOS server names that are used by the applications as the naming format, one per line. To ensure exceptions, the names that are used by all applications need to be in the list. A single asterisk (\*) can be used anywhere in the string as a wildcard character.
-
### Possible values
-
- User-defined list of remote servers
-
When you enter a list of remote servers to which clients are allowed to use NTLM authentication, the policy is defined and enabled.
-
- Not defined
-
If you do not configure this policy setting by defining a list of servers, the policy is undefined and no exceptions will be applied.
-
### Best practices
-
1. First enforce the [Network Security: Restrict NTLM: Audit incoming NTLM traffic](network-security-restrict-ntlm-audit-incoming-ntlm-traffic.md) or [Network Security: Restrict NTLM: Audit NTLM authentication in this domain](network-security-restrict-ntlm-audit-ntlm-authentication-in-this-domain.md) policy setting and then review the operational event log to understand which servers are involved in these authentication attempts so you can decide which servers to exempt.
-
2. After you have set the server exception list, enforce the [Network Security: Restrict NTLM: Audit incoming NTLM traffic](network-security-restrict-ntlm-audit-incoming-ntlm-traffic.md) or [Network Security: Restrict NTLM: Audit NTLM authentication in this domain](network-security-restrict-ntlm-audit-ntlm-authentication-in-this-domain.md) policy setting and then review the operational event log again before setting the policies to block NTLM traffic.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
@@ -88,59 +66,27 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Sec
-
-
## Policy management
-
-
This section describes the features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Group Policy
-
Setting and deploying this policy through Group Policy takes precedence over the setting on the local device. If the Group Policy setting is set to **Not Configured**, local settings will apply.
-
### Auditing
-
View the operational event log to see if your server exception list is functioning as intended. Audit and block events are recorded on this device in the operational event log located in **Applications and Services Log\\Microsoft\\Windows\\NTLM**.
-
There are no security audit policies that can be configured to view output from this policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
When it has been determined that the NTLM authentication protocol should not be used from a client device to any remote servers because you are required to use a more secure protocol such as Kerberos, there might be some client applications that still use NTLM. If so, and you set [Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers](network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md) to any of the deny options, those applications will fail because the outbound NTLM authentication traffic from the client computer will be blocked.
-
If you define an exception list of servers to which client devices are allowed to use NTLM authentication, then NTLM authentication traffic will continue to flow between those client applications and servers. The servers then are vulnerable to any malicious attack that takes advantage of security weaknesses in NTLM.
-
### Countermeasure
-
When you use [Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers](network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md) in audit-only mode, you can determine by reviewing which client applications are making NTLM authentication requests to the remote servers in your environment. When assessed, you will have to determine on a case-by-case basis if NTLM authentication still minimally meets your security requirements. If not, the client application has to be upgraded to use something other than NTLM authentication.
-
### Potential impact
-
Defining a list of servers for this policy setting will enable NTLM authentication traffic from the client application that uses those servers, and this might result in a security vulnerability.
-
If this list is not defined and [Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers](network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md) is enabled, then client applications that use NTLM will fail to authenticate to those servers that they have previously used.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/network-security-restrict-ntlm-add-server-exceptions-in-this-domain.md b/windows/keep-secure/network-security-restrict-ntlm-add-server-exceptions-in-this-domain.md
index dfb2288ae6..a9dd8ee023 100644
--- a/windows/keep-secure/network-security-restrict-ntlm-add-server-exceptions-in-this-domain.md
+++ b/windows/keep-secure/network-security-restrict-ntlm-add-server-exceptions-in-this-domain.md
@@ -2,54 +2,32 @@
title: Network security Restrict NTLM Add server exceptions in this domain (Windows 10)
description: Describes the best practices, location, values, management aspects, and security considerations for the Network security Restrict NTLM Add server exceptions in this domain security policy setting.
ms.assetid: 2f981b68-6aa7-4dd9-b53d-d88551277cc0
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Network security: Restrict NTLM: Add server exceptions in this domain
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, management aspects, and security considerations for the **Network security: Restrict NTLM: Add server exceptions in this domain** security policy setting.
-
## Reference
-
-
The **Network security: Restrict NTLM: Add server exceptions in this domain** policy setting allows you to create an exception list of servers in this domain to which client device are allowed to use NTLM pass-through authentication if any of the deny options are set in the [Network Security: Restrict NTLM: NTLM authentication in this domain](network-security-restrict-ntlm-ntlm-authentication-in-this-domain.md) policy setting.
-
If you configure this policy setting, you can define a list of servers in this domain to which client devices are allowed to use NTLM authentication.
-
If you do not configure this policy setting, no exceptions will be applied, and if **Network Security: Restrict NTLM: NTLM authentication in this domain** is enabled, all NTLM authentication attempts in the domain will fail.
-
List the NetBIOS server names as the naming format, one per line. A single asterisk (\*) can be used anywhere in the string as a wildcard character.
-
### Possible values
-
- User-defined list of servers
-
When you enter a list of servers in this domain to which clients are allowed to use NTLM authentication, the policy is defined and enabled.
-
- Not defined
-
If you do not configure this policy setting by defining a list of servers, the policy is undefined and no exceptions will be applied.
-
### Best practices
-
1. First enforce the **Network Security: Restrict NTLM: Audit NTLM authentication in this domain** policy setting, and then review the operational event log to understand what domain controllers are involved in these authentication attempts so you can decide which servers to exempt.
-
2. After you have set the server exception list, enforce the **Network Security: Restrict NTLM: Audit NTLM authentication in this domain** policy setting, and then review the operational event log again before setting the policies to block NTLM traffic.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
@@ -88,59 +66,27 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Sec
-
-
## Policy management
-
-
This section describes different features and tools available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a restart when saved locally or distributed through Group Policy.
-
### Group Policy
-
Setting and deploying this policy via Group Policy takes precedence over the setting on the local device. If the Group Policy is set to **Not Configured**, local settings will apply.
-
### Auditing
-
View the operational event log to see if your server exception list is functioning as intended. Audit and block events are recorded on this computer in the operational event log located in **Applications and Services Log\\Microsoft\\Windows\\NTLM**.
-
There are no security audit policies that can be configured to view output from this policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
When it has been determined that the NTLM authentication protocol should not be used within a domain because you are required to use a more secure protocol such as Kerberos, there might be some NTLM authentication traffic that is still present in the domain. If so, and you set Network Security: [Network Security: Restrict NTLM: NTLM authentication in this domain](network-security-restrict-ntlm-ntlm-authentication-in-this-domain.md) to any of the deny options, any NTLM authentication request will fail because the pass-through member server will block the NTLM request.
-
If you define an exception list of servers in this domain to which client computers are allowed to use NTLM pass-through authentication, then NTLM authentication traffic will continue to flow between those servers, which make them vulnerable to any malicious attack that takes advantage of security weaknesses in NTLM.
-
### Countermeasure
-
When you use **Network Security: Restrict NTLM: NTLM authentication in this domain** in audit-only mode, you can determine by reviewing which client applications are making NTLM authentication requests to the pass-through authentication servers. When assessed, you will have to determine on a case-by-case basis if NTLM authentication still minimally meets your security requirements.
-
### Potential impact
-
Defining a list of servers for this policy setting will enable NTLM authentication traffic between those servers might result in a security vulnerability.
-
If this list is not defined and **Network Security: Restrict NTLM: NTLM authentication in this domain** is enabled, then NTLM authentication will fail on those pass-through servers in the domain that they have previously used
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/network-security-restrict-ntlm-audit-incoming-ntlm-traffic.md b/windows/keep-secure/network-security-restrict-ntlm-audit-incoming-ntlm-traffic.md
index f801658d52..1f01809e6d 100644
--- a/windows/keep-secure/network-security-restrict-ntlm-audit-incoming-ntlm-traffic.md
+++ b/windows/keep-secure/network-security-restrict-ntlm-audit-incoming-ntlm-traffic.md
@@ -2,60 +2,35 @@
title: Network security Restrict NTLM Audit incoming NTLM traffic (Windows 10)
description: Describes the best practices, location, values, management aspects, and security considerations for the Network Security Restrict NTLM Audit incoming NTLM traffic security policy setting.
ms.assetid: 37e380c2-22e1-44cd-9993-e12815b845cf
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Network security: Restrict NTLM: Audit incoming NTLM traffic
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, management aspects, and security considerations for the **Network Security: Restrict NTLM: Audit incoming NTLM traffic** security policy setting.
-
## Reference
-
-
The **Network Security: Restrict NTLM: Audit incoming NTLM traffic** policy setting allows you to audit incoming NTLM traffic.
-
When this audit policy is enabled within Group Policy, it is enforced on any server where that Group Policy is distributed. The events will be recorded in the operational event log located in **Applications and Services Log\\Microsoft\\Windows\\NTLM**. Using an audit event collection system can help you collect the events for analysis more efficiently.
-
When you enable this policy on a server, only authentication traffic to that server will be logged.
-
When you enable this audit policy, it functions in the same way as the [Network Security: Restrict NTLM: Incoming NTLM traffic](network-security-restrict-ntlm-incoming-ntlm-traffic.md) policy, but it does not actually block any traffic. Therefore, you can use it effectively to understand the authentication traffic in your environment, and when you are ready to block that traffic, you can enable the Network Security: Restrict NTLM: Incoming NTLM traffic policy setting and select **Deny all accounts** or **Deny all domain accounts**.
-
### Possible values
-
- Disable
-
The server on which this policy is set will not log events for incoming NTLM traffic.
-
- Enable auditing for domain accounts
-
The server on which this policy is set will log events for NTLM pass-through authentication requests only for accounts in the domain that would be blocked when the [Network Security: Restrict NTLM: Incoming NTLM traffic](network-security-restrict-ntlm-incoming-ntlm-traffic.md) policy setting is set to **Deny all domain accounts**.
-
- Enable auditing for all accounts
-
The server on which this policy is set will log events for all NTLM authentication requests that would be blocked when the [Network Security: Restrict NTLM: Incoming NTLM traffic](network-security-restrict-ntlm-incoming-ntlm-traffic.md) policy setting is set to **Deny all accounts**.
-
- Not defined
-
This is the same as **Disable**, and it results in no auditing of NTLM traffic.
-
### Best practices
-
Depending on your environment and the duration of your testing, monitor the log size regularly.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
@@ -94,57 +69,26 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Sec
-
-
## Policy management
-
-
This section describes different features and tools available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a restart when saved locally or distributed through Group Policy.
-
### Group Policy
-
Setting and deploying this policy using Group Policy takes precedence over the setting on the local device. If the Group Policy is set to **Not Configured**, local settings will apply.
-
### Auditing
-
View the operational event log to see if this policy is functioning as intended. Audit and block events are recorded on this computer in the operational event log located in **Applications and Services Log\\Microsoft\\Windows\\NTLM**. Using an audit event collection system can help you collect the events for analysis more efficiently.
-
There are no security audit event policies that can be configured to view output from this policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
NTLM and NTLMv2 authentication is vulnerable to a variety of malicious attacks, including SMB relay, man-in-the-middle attacks, and brute force attacks. Reducing and eliminating NTLM authentication from your environment forces the Windows operating system to use more secure protocols, such as the Kerberos version 5 protocol, or different authentication mechanisms, such as smart cards.
-
### Vulnerability
-
Enabling this policy setting will reveal through logging which servers and client computers within your network or domain handle NTLM traffic. The identity of these devices can be used in malicious ways if NTLM authentication traffic is compromised. The policy setting does not prevent or mitigate any vulnerability because it is for audit purposes only.
-
### Countermeasure
-
Restrict access to the log files when this policy setting is enabled in your production environment.
-
### Potential impact
-
If you do not enable or configure this policy setting, no NTLM authentication traffic information will be logged. If you do enable this policy setting, only auditing functions will occur; no security enhancements will be implemented.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/network-security-restrict-ntlm-audit-ntlm-authentication-in-this-domain.md b/windows/keep-secure/network-security-restrict-ntlm-audit-ntlm-authentication-in-this-domain.md
index e8a80b5166..6f7df9f011 100644
--- a/windows/keep-secure/network-security-restrict-ntlm-audit-ntlm-authentication-in-this-domain.md
+++ b/windows/keep-secure/network-security-restrict-ntlm-audit-ntlm-authentication-in-this-domain.md
@@ -2,58 +2,34 @@
title: Network security Restrict NTLM Audit NTLM authentication in this domain (Windows 10)
description: Describes the best practices, location, values, management aspects, and security considerations for the Network Security Restrict NTLM Audit NTLM authentication in this domain security policy setting.
ms.assetid: 33183ef9-53b5-4258-8605-73dc46335e6e
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Network security: Restrict NTLM: Audit NTLM authentication in this domain
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, management aspects, and security considerations for the **Network Security: Restrict NTLM: Audit NTLM authentication in this domain** security policy setting.
-
## Reference
-
-
The **Network Security: Restrict NTLM: Audit NTLM authentication in this domain** policy setting allows you to audit on the domain controller NTLM authentication in that domain.
-
When you enable this policy setting on the domain controller, only authentication traffic to that domain controller will be logged.
-
When you enable this audit policy, it functions in the same way as the **Network Security: Restrict NTLM: NTLM authentication in this domain** policy setting, but it does not actually block any traffic. Therefore, you can use it effectively to understand the authentication traffic to your domain controllers and when you are ready to block that traffic, you can enable the **Network Security: Restrict NTLM: NTLM authentication in this domain** policy setting and select **Deny for domain accounts to domain servers**, **Deny for domain servers**, or **Deny for domain accounts**.
-
### Possible values
-
- **Disable**
-
The domain controller on which this policy is set will not log events for incoming NTLM traffic.
-
- **Enable for domain accounts to domain servers**
-
The domain controller on which this policy is set will log events for NTLM authentication logon attempts for accounts in the domain to domain servers when NTLM authentication would be denied because the **Network security: Restrict NTLM: NTLM authentication in this domain** policy setting is set to **Deny for domain accounts to domain servers**.
-
- **Enable for domain accounts**
-
The domain controller will log events for NTLM authentication logon attempts that use domain accounts when NTLM authentication would be denied because the **Network security: Restrict NTLM: NTLM authentication in this domain** policy setting is set to **Deny for domain accounts**.
-
- Not defined
-
This is the same as **Disable** and results in no auditing of NTLM traffic.
-
### Best practices
-
Depending on your environment and the duration of your testing, monitor the operational event log size regularly.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
@@ -92,57 +68,26 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Sec
-
-
## Policy management
-
-
This section describes different features and tools available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a restart when saved locally or distributed through Group Policy.
-
### Group Policy
-
Setting and deploying this policy using Group Policy takes precedence over the setting on the local device. If the Group Policy is set to **Not Configured**, local settings will apply.
-
### Auditing
-
View the operational event log to see if this policy is functioning as intended. Audit and block events are recorded on this computer in the operational event log located in **Applications and Services Log\\Microsoft\\Windows\\NTLM**. Using an audit event collection system can help you collect the events for analysis more efficiently.
-
There are no security audit event policies that can be configured to view output from this policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
NTLM and NTLMv2 authentication is vulnerable to a variety of malicious attacks, including SMB replay, man-in-the-middle attacks, and brute force attacks. Reducing and eliminating NTLM authentication from your environment forces the Windows operating system to use more secure protocols, such as the Kerberos version 5 protocol, or different authentication mechanisms, such as smart cards.
-
### Vulnerability
-
Enabling this policy setting will reveal through logging which devices within your network or domain handle NTLM traffic. The identity of these devices can be used in malicious ways if NTLM authentication traffic is compromised. The policy setting does not prevent or mitigate any vulnerability because it is for audit purposes only.
-
### Countermeasure
-
Restrict access to the log files when this policy setting is enabled in your production environment.
-
### Potential impact
-
If you do not enable or configure this policy setting, no NTLM authentication traffic information will be logged. If you do enable this policy setting, only auditing functions will occur; no security enhancements will be implemented.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/network-security-restrict-ntlm-incoming-ntlm-traffic.md b/windows/keep-secure/network-security-restrict-ntlm-incoming-ntlm-traffic.md
index 11866f1750..500af92295 100644
--- a/windows/keep-secure/network-security-restrict-ntlm-incoming-ntlm-traffic.md
+++ b/windows/keep-secure/network-security-restrict-ntlm-incoming-ntlm-traffic.md
@@ -2,54 +2,32 @@
title: Network security Restrict NTLM Incoming NTLM traffic (Windows 10)
description: Describes the best practices, location, values, management aspects, and security considerations for the Network Security Restrict NTLM Incoming NTLM traffic security policy setting.
ms.assetid: c0eff7d3-ed59-4004-908a-2205295fefb8
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Network security: Restrict NTLM: Incoming NTLM traffic
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, management aspects, and security considerations for the **Network Security: Restrict NTLM: Incoming NTLM traffic** security policy setting.
-
## Reference
-
-
The **Network Security: Restrict NTLM: Incoming NTLM traffic** policy setting allows you to deny or allow incoming NTLM traffic from client computers, other member servers, or a domain controller.
-
### Possible values
-
- **Allow all**
-
The server will allow all NTLM authentication requests.
-
- **Deny all domain accounts**
-
The server will deny NTLM authentication requests for domain logon, return an NTLM blocked error message to the client device, and log the error, but the server will allow local account logon.
-
- **Deny all accounts**
-
The server will deny NTLM authentication requests from all incoming traffic (whether domain account logon or local account logon), return an NTLM blocked error message to the client device, and log the error.
-
- Not defined
-
This is the same as **Allow all**, and the server will allow all NTLM authentication requests.
-
### Best practices
-
If you select **Deny all domain accounts** or **Deny all accounts**, incoming NTLM traffic to the member server will be restricted. It is better to set the **Network Security: Restrict NTLM: Audit Incoming NTLM traffic** policy setting and then review the Operational log to understand what authentication attempts are made to the member servers, and subsequently what client applications are using NTLM.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
@@ -88,57 +66,26 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Sec
-
-
## Policy management
-
-
This section describes different features and tools available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a restart when saved locally or distributed through Group Policy.
-
### Group Policy
-
Setting and deploying this policy using Group Policy takes precedence over the setting on the local device. If the Group Policy is set to **Not Configured**, local settings will apply.
-
### Auditing
-
View the operational event log to see if this policy is functioning as intended. Audit and block events are recorded on this computer in the operational event log located in **Applications and Services Log\\Microsoft\\Windows\\NTLM**.
-
There are no Security Audit Event policies that can be configured to view event output from this policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
NTLM and NTLMv2 authentication is vulnerable to a variety of malicious attacks, including SMB replay, man-in-the-middle attacks, and brute force attacks. Reducing and eliminating NTLM authentication from your environment forces the Windows operating system to use more secure protocols, such as the Kerberos version 5 protocol, or different authentication mechanisms, such as smart cards.
-
### Vulnerability
-
Malicious attacks on NTLM authentication traffic that result in a compromised server can occur only if the server handles NTLM requests. If those requests are denied, brute force attacks on NTLM are eliminated.
-
### Countermeasure
-
When it has been determined that the NTLM authentication protocol should not be used within a network because you are required to use a more secure protocol such as Kerberos, you can select one of several options that this security policy setting offers to restrict NTLM usage.
-
### Potential impact
-
If you configure this policy setting, numerous NTLM authentication requests could fail within your network, which could degrade productivity. Before implementing this change through this policy setting, set **Network security: Restrict NTLM: Audit Incoming NTLM traffic** to the same option so that you can review the log for the potential impact, perform an analysis of servers, and create an exception list of servers to exclude from this policy setting [Network security: Restrict NTLM: Add server exceptions in this domain](network-security-restrict-ntlm-add-server-exceptions-in-this-domain.md).
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/network-security-restrict-ntlm-ntlm-authentication-in-this-domain.md b/windows/keep-secure/network-security-restrict-ntlm-ntlm-authentication-in-this-domain.md
index 47e59383c0..27500c1d95 100644
--- a/windows/keep-secure/network-security-restrict-ntlm-ntlm-authentication-in-this-domain.md
+++ b/windows/keep-secure/network-security-restrict-ntlm-ntlm-authentication-in-this-domain.md
@@ -2,64 +2,37 @@
title: Network security Restrict NTLM NTLM authentication in this domain (Windows 10)
description: Describes the best practices, location, values, management aspects, and security considerations for the Network Security Restrict NTLM NTLM authentication in this domain security policy setting.
ms.assetid: 4c7884e9-cc11-4402-96b6-89c77dc908f8
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Network security: Restrict NTLM: NTLM authentication in this domain
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, management aspects, and security considerations for the **Network Security: Restrict NTLM: NTLM authentication in this domain** security policy setting.
-
## Reference
-
-
The **Network Security: Restrict NTLM: NTLM authentication in this domain** policy setting allows you to deny or allow NTLM authentication within a domain from this domain controller. This policy setting does not affect interactive logon to this domain controller.
-
### Possible values
-
- **Disable**
-
The domain controller will allow all NTLM pass-through authentication requests within the domain.
-
- **Deny for domain accounts to domain servers**
-
The domain controller will deny all NTLM authentication logon attempts using accounts from this domain to all servers in the domain. The NTLM authentication attempts will be blocked and will return an NTLM blocked error unless the server name is on the exception list in the **Network security: Restrict NTLM: Add server exceptions in this domain** policy setting.
-
NTLM can be used if the users are connecting to other domains. This depends on if any Restrict NTLM policies have been set on those domains.
-
- **Deny for domain accounts**
-
Only the domain controller will deny all NTLM authentication logon attempts from domain accounts and will return an NTLM blocked error unless the server name is on the exception list in the **Network security: Restrict NTLM: Add server exceptions in this domain** policy setting.
-
- **Deny for domain servers**
-
The domain controller will deny NTLM authentication requests to all servers in the domain and will return an NTLM blocked error unless the server name is on the exception list in the **Network security: Restrict NTLM: Add server exceptions in this domain** policy setting. Servers that are not joined to the domain will not be affected if this policy setting is configured.
-
- **Deny all**
-
The domain controller will deny all NTLM pass-through authentication requests from its servers and for its accounts and return an NTLM blocked error unless the server name is on the exception list in the **Network security: Restrict NTLM: Add server exceptions in this domain** policy setting.
-
- Not defined
-
The domain controller will allow all NTLM authentication requests in the domain where the policy is deployed.
-
### Best practices
-
If you select any of the deny options, incoming NTLM traffic to the domain will be restricted. First, set the **Network Security: Restrict NTLM: Audit NTLM authentication in this domain** policy setting, and then review the Operational log to understand what authentication attempts are made to the member servers. You can then add those member server names to a server exception list by using the [Network security: Restrict NTLM: Add server exceptions in this domain](network-security-restrict-ntlm-add-server-exceptions-in-this-domain.md) policy setting.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
@@ -98,57 +71,26 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Sec
-
-
## Policy management
-
-
This section describes different features and tools available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a restart when saved locally or distributed through Group Policy.
-
### Group Policy
-
Setting and deploying this policy using Group Policy takes precedence over the setting on the local device. If the Group Policy is set to **Not Configured**, local settings will apply.
-
### Auditing
-
View the operational event log to see if this policy is functioning as intended. Audit and block events are recorded on this computer in the operational event log located in **Applications and Services Log\\Microsoft\\Windows\\NTLM**.
-
There are no security audit event policies that can be configured to view output from this policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
NTLM and NTLMv2 authentication is vulnerable to a variety of malicious attacks, including SMB replay, man-in-the-middle attacks, and brute force attacks. Reducing and eliminating NTLM authentication from your environment forces the Windows operating system to use more secure protocols, such as the Kerberos version 5 protocol, or different authentication mechanisms, such as smart cards.
-
### Vulnerability
-
Malicious attacks on NTLM authentication traffic resulting in a compromised server or domain controller can occur only if the server or domain controller handles NTLM requests. If those requests are denied, this attack vector is eliminated.
-
### Countermeasure
-
When it has been determined that the NTLM authentication protocol should not be used within a network because you are required to use a more secure protocol such as the Kerberos protocol, then you can select one of several options that this security policy setting offers to restrict NTLM usage within the domain.
-
### Potential impact
-
If you configure this policy setting, numerous NTLM authentication requests could fail within the domain, which could degrade productivity. Before implementing this change through this policy setting, set **Network security: Restrict NTLM: Audit NTLM authentication in this domain** to the same option so that you can review the log for the potential impact, perform an analysis of servers, and create an exception list of servers to exclude from this policy setting by using [Network security: Restrict NTLM: Add server exceptions in this domain](network-security-restrict-ntlm-add-server-exceptions-in-this-domain.md).
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md b/windows/keep-secure/network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md
index defbe6351f..b73aff9db6 100644
--- a/windows/keep-secure/network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md
+++ b/windows/keep-secure/network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md
@@ -2,59 +2,35 @@
title: Network security Restrict NTLM Outgoing NTLM traffic to remote servers (Windows 10)
description: Describes the best practices, location, values, management aspects, and security considerations for the Network Security Restrict NTLM Outgoing NTLM traffic to remote servers security policy setting.
ms.assetid: 63437a90-764b-4f06-aed8-a4a26cf81bd1
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, management aspects, and security considerations for the **Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers** security policy setting.
-
## Reference
-
-
The **Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers** policy setting allows you to deny or audit outgoing NTLM traffic from a computer running Windows 7, Windows Server 2008, or later to any remote server running the Windows operating system.
-
**Warning**
Modifying this policy setting may affect compatibility with client computers, services, and applications.
-
-
### Possible values
-
- **Allow all**
-
The device can authenticate identities to a remote server by using NTLM authentication because no restrictions exist.
-
- **Audit all**
-
The device that sends the NTLM authentication request to a remote server logs an event for each request. This allows you to identify those servers that receive NTLM authentication requests from the client device
-
- **Deny all**
-
The device cannot authenticate any identities to a remote server by using NTLM authentication. You can use the [Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication](network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication.md) policy setting to define a list of remote servers to which client devices are allowed to use NTLM authentication while denying others. This setting will also log an event on the device that is making the authentication request.
-
- Not defined
-
This is the same as **Allow all**, and the device will allow all NTLM authentication requests when the policy is deployed.
-
### Best practices
-
If you select **Deny all**, the client device cannot authenticate identities to a remote server by using NTLM authentication. First, select **Audit all** and then review the operational event log to understand which servers are involved in these authentication attempts. You can then add those server names to a server exception list by using the [Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication](network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication.md) policy setting.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
@@ -93,57 +69,26 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Sec
-
-
## Policy management
-
-
This section describes different features and tools available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a restart when saved locally or distributed through Group Policy.
-
### Group Policy
-
Setting and deploying this policy using Group Policy takes precedence over the setting on the local device. If the Group Policy is set to **Not Configured**, local settings will apply.
-
### Auditing
-
View the operational event log to see if this policy is functioning as intended. Audit and block events are recorded on this computer in the operational event log located in **Applications and Services Log\\Microsoft\\Windows\\NTLM**.
-
There are no security audit event policies that can be configured to view event output from this policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
NTLM and NTLMv2 authentication is vulnerable to a variety of malicious attacks, including SMB replay, man-in-the-middle attacks, and brute force attacks. Reducing and eliminating NTLM authentication from your environment forces the Windows operating system to use more secure protocols, such as the Kerberos version 5 protocol, or different authentication mechanisms, such as smart cards.
-
### Vulnerability
-
Malicious attacks on NTLM authentication traffic that result in a compromised server or domain controller can occur only if the server or domain controller handles NTLM requests. If those requests are denied, this attack vector is eliminated.
-
### Countermeasure
-
When it has been determined that the NTLM authentication protocol should not be used within a network because you are required to use a more secure protocol such as Kerberos, then you can select from several options to restrict NTLM usage to servers.
-
### Potential impact
-
If you configure this policy setting to deny all requests, numerous NTLM authentication requests to remote servers could fail, which could degrade productivity. Before implementing this restriction through this policy setting, select **Audit all** so that you can review the log for the potential impact, perform an analysis of servers, and create an exception list of servers to exclude from this policy setting by using [Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication](network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication.md).
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/optimize-applocker-performance.md b/windows/keep-secure/optimize-applocker-performance.md
index 87143fb82f..f8eb1d4d8e 100644
--- a/windows/keep-secure/optimize-applocker-performance.md
+++ b/windows/keep-secure/optimize-applocker-performance.md
@@ -2,41 +2,22 @@
title: Optimize AppLocker performance (Windows 10)
description: This topic for IT professionals describes how to optimize AppLocker policy enforcement.
ms.assetid: a20efa20-bc98-40fe-bd81-28ec4905e0f6
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Optimize AppLocker performance
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals describes how to optimize AppLocker policy enforcement.
-
## Optimization of Group Policy
-
-
AppLocker policies can be implemented by organization unit (OU) using Group Policy. If so, your Group Policy infrastructure should be optimized and retested for performance when AppLocker policies are added to existing Group Policy Objects (GPOs) or new GPOs are created, as you do with adding any policies to your GPOs.
-
For more info, see the [Optimizing Group Policy Performance](http://go.microsoft.com/fwlink/p/?LinkId=163238) article in TechNet Magazine.
-
### AppLocker rule limitations
-
The more rules per GPO, the longer AppLocker requires for evaluation. There is no set limitation on the number of rules per GPO, but the number of rules that can fit into a 100 MB GPO varies based on the complexity of the rule, such as the number of file hashes included in a single file hash condition.
-
### Using the DLL rule collection
-
When the DLL rule collection is enabled, AppLocker must check each DLL that an application loads. The more DLLs, the longer AppLocker requires to complete the evaluation.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/packaged-apps-and-packaged-app-installer-rules-in-applocker.md b/windows/keep-secure/packaged-apps-and-packaged-app-installer-rules-in-applocker.md
index 428029452b..64303436c2 100644
--- a/windows/keep-secure/packaged-apps-and-packaged-app-installer-rules-in-applocker.md
+++ b/windows/keep-secure/packaged-apps-and-packaged-app-installer-rules-in-applocker.md
@@ -2,48 +2,26 @@
title: Packaged apps and packaged app installer rules in AppLocker (Windows 10)
description: This topic explains the AppLocker rule collection for packaged app installers and packaged apps.
ms.assetid: 8fd44d08-a0c2-4c5b-a91f-5cb9989f971d
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Packaged apps and packaged app installer rules in AppLocker
-
-
**Applies to**
-
- Windows 10
-
This topic explains the AppLocker rule collection for packaged app installers and packaged apps.
-
Universal Windows apps can be installed through the Windows Store or can be sideloaded using the Windows PowerShell cmdlets. Universal Windows apps can be installed by a standard user unlike some Classic Windows applications that sometimes require administrative privileges for installation.
-
Typically, an app consists of multiple components – the installer used to install the app and one or more exes, dlls or scripts. With Classic Windows applications, not all those components always share common attributes such as the publisher name, product name and product version. Therefore, AppLocker has to control each of these components separately through different rule collections – exe, dll, script and Windows Installers. In contrast, all the components of a Universal Windows app share the same attributes: Publisher name, Package name and Package version. It is therefore possible to control an entire app with a single rule.
-
AppLocker enforces rules for Universal Windows apps separately from Classic Windows applications. A single AppLocker rule for a Universal Windows app can control both the installation and the running of an app. Because all Universal Windows apps are signed, AppLocker supports only publisher rules for Universal Windows apps. A publisher rule for a Universal Windows app is based on the following attributes of the app:
-
- Publisher name
-
- Package name
-
- Package version
-
In summary, including AppLocker rules for Universal Windows apps in your policy design provides:
-
- The ability to control the installation and running of the app
-
- The ability to control all the components of the app with a single rule rather than controlling individual binaries within the app
-
- The ability to create application control policies that survive app updates
-
- Management of Universal Windows apps through Group Policy.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/passport-event-300.md b/windows/keep-secure/passport-event-300.md
index d5f6dd3808..dfcc826405 100644
--- a/windows/keep-secure/passport-event-300.md
+++ b/windows/keep-secure/passport-event-300.md
@@ -2,26 +2,19 @@
title: Event ID 300 - Passport successfully created (Windows 10)
description: This event is created when a Microsoft Passport for Enterprise is successfully created and registered with Azure Active Directory (Azure AD).
ms.assetid: 0DD59E75-1C5F-4CC6-BB0E-71C83884FF04
+ms.pagetype: security
keywords: ["ngc"]
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: jdeckerMS
---
-
# Event ID 300 - Passport successfully created
-
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
-
This event is created when a Microsoft Passport for Enterprise is successfully created and registered with Azure Active Directory (Azure AD). Applications or services can trigger actions on this event. For example, a certificate provisioning service can listen to this event and trigger a certificate request.
-
## Event details
-
-
| | |
|--------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Product:** | Windows 10 operating system |
@@ -29,34 +22,15 @@ This event is created when a Microsoft Passport for Enterprise is successfully c
| **Source:** | Microsoft Azure Device Registration Service |
| **Version:** | 10 |
| **Message:** | The NGC key was successfully registered. Key ID: {4476694e-8e3b-4ef8-8487-be21f95e6f07}. UPN:test@contoso.com. Attestation: ATT\_SOFT. Client request ID: . Server request ID: db2da6bd-3d70-4b9b-b26b-444f669902da. Server response: {"kid":"4476694e-8e3b-4ef8-8487-be21f95e6f07","upn":"test@contoso.com"} |
-
-
## Resolve
-
-
This is a normal condition. No further action is required.
-
## Related topics
-
-
[Manage identity verification using Microsoft Passport](manage-identity-verification-using-microsoft-passport.md)
-
[Implement Microsoft Passport in your organization](implement-microsoft-passport-in-your-organization.md)
-
[Why a PIN is better than a password](why-a-pin-is-better-than-a-password.md)
-
[Prepare people to use Microsoft Passport](prepare-people-to-use-microsoft-passport.md)
-
[Microsoft Passport and password changes](microsoft-passport-and-password-changes.md)
-
[Microsoft Passport errors during PIN creation](microsoft-passport-errors-during-pin-creation.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/password-must-meet-complexity-requirements.md b/windows/keep-secure/password-must-meet-complexity-requirements.md
index c4b7b4420c..fba24e4fb4 100644
--- a/windows/keep-secure/password-must-meet-complexity-requirements.md
+++ b/windows/keep-secure/password-must-meet-complexity-requirements.md
@@ -2,76 +2,43 @@
title: Password must meet complexity requirements (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Password must meet complexity requirements security policy setting.
ms.assetid: 94482ae3-9dda-42df-9782-2f66196e6afe
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Password must meet complexity requirements
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **Password must meet complexity requirements** security policy setting.
-
## Reference
-
-
The **Passwords must meet complexity requirements** policy setting determines whether passwords must meet a series of guidelines that are considered important for a strong password. Enabling this policy setting requires passwords to meet the following requirements:
-
1. Passwords may not contain the user's samAccountName (Account Name) value or entire displayName (Full Name value). Both checks are not case sensitive.
-
The samAccountName is checked in its entirety only to determine whether it is part of the password. If the samAccountName is less than three characters long, this check is skipped.
-
The displayName is parsed for delimiters: commas, periods, dashes or hyphens, underscores, spaces, pound signs, and tabs. If any of these delimiters are found, the displayName is split and all parsed sections (tokens) are confirmed to not be included in the password. Tokens that are less than three characters are ignored, and substrings of the tokens are not checked. For example, the name "Erin M. Hagens" is split into three tokens: "Erin", "M", and "Hagens". Because the second token is only one character long, it is ignored. Therefore, this user could not have a password that included either "erin" or "hagens" as a substring anywhere in the password.
-
2. The password contains characters from three of the following categories:
-
- Uppercase letters of European languages (A through Z, with diacritic marks, Greek and Cyrillic characters)
-
- Lowercase letters of European languages (a through z, sharp-s, with diacritic marks, Greek and Cyrillic characters)
-
- Base 10 digits (0 through 9)
-
- Non-alphanumeric characters (special characters) (for example, !, $, \#, %)
-
- Any Unicode character that is categorized as an alphabetic character but is not uppercase or lowercase. This includes Unicode characters from Asian languages.
-
Complexity requirements are enforced when passwords are changed or created.
-
The rules that are included in the Windows Server password complexity requirements are part of Passfilt.dll, and they cannot be directly modified.
-
Enabling the default Passfilt.dll may cause some additional Help Desk calls for locked-out accounts because users might not be used to having passwords that contain characters other than those found in the alphabet. However, this policy setting is liberal enough that all users should be able to abide by the requirements with a minor learning curve.
-
Additional settings that can be included in a custom Passfilt.dll are the use of non–upper-row characters. Upper-row characters are those that are typed by holding down the SHIFT key and typing any of the digits from 1 through 10.
-
### Possible values
-
- Enabled
-
- Disabled
-
- Not defined
-
### Best practices
-
Set **Passwords must meet complexity requirements** to Enabled. This policy setting, combined with a minimum password length of 8, ensures that there are at least 218,340,105,584,896 different possibilities for a single password. This makes a brute force attack difficult, but still not impossible.
-
The use of ALT key character combinations can greatly enhance the complexity of a password. However, requiring all users in an organization to adhere to such stringent password requirements can result in unhappy users and an extremely busy Help Desk. Consider implementing a requirement in your organization to use ALT characters in the range from 0128 through 0159 as part of all administrator passwords. (ALT characters outside of this range can represent standard alphanumeric characters that do not add additional complexity to the password.)
-
Passwords that contain only alphanumeric characters are easy to compromise by using publicly available tools. To prevent this, passwords should contain additional characters and meet complexity requirements.
-
### Location
-
**Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Password Policy**
-
### Default values
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -110,42 +77,19 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Passwords that contain only alphanumeric characters are extremely easy to discover with several publicly available tools.
-
### Countermeasure
-
Configure the **Passwords must meet complexity requirements** policy setting to Enabled and advise users to use a variety of characters in their passwords.
-
When combined with a [Minimum password length](minimum-password-length.md) of 8, this policy setting ensures that the number of different possibilities for a single password is so great that it is difficult (but not impossible) for a brute force attack to succeed. (If the Minimum password length policy setting is increased, the average amount of time necessary for a successful attack also increases.)
-
### Potential impact
-
If the default password complexity configuration is retained, additional Help Desk calls for locked-out accounts could occur because users might not be accustomed to passwords that contain non-alphabetical characters, or they might have problems entering passwords that contain accented characters or symbols on keyboards with different layouts. However, all users should be able to comply with the complexity requirement with minimal difficulty.
-
If your organization has more stringent security requirements, you can create a custom version of the Passfilt.dll file that allows the use of arbitrarily complex password strength rules. For example, a custom password filter might require the use of non-upper-row symbols. (Upper-row symbols are those that require you to press and hold the SHIFT key and then press any of the digits between 1 and 0.) A custom password filter might also perform a dictionary check to verify that the proposed password does not contain common dictionary words or fragments.
-
The use of ALT key character combinations can greatly enhance the complexity of a password. However, such stringent password requirements can result in additional Help Desk requests. Alternatively, your organization could consider a requirement for all administrator passwords to use ALT characters in the 0128–0159 range. (ALT characters outside of this range can represent standard alphanumeric characters that would not add additional complexity to the password.)
-
## Related topics
-
-
[Password Policy](password-policy.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/password-policy.md b/windows/keep-secure/password-policy.md
index 742ac0e7dd..4d1c366110 100644
--- a/windows/keep-secure/password-policy.md
+++ b/windows/keep-secure/password-policy.md
@@ -2,42 +2,26 @@
title: Password Policy (Windows 10)
description: An overview of password policies for Windows and links to information for each policy setting.
ms.assetid: aec1220d-a875-4575-9050-f02f9c54a3b6
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Password Policy
-
-
**Applies to**
-
- Windows 10
-
An overview of password policies for Windows and links to information for each policy setting.
-
In many operating systems, the most common method to authenticate a user's identity is to use a secret passphrase or password. A secure network environment requires all users to use strong passwords, which have at least eight characters and include a combination of letters, numbers, and symbols. These passwords help prevent the compromise of user accounts and administrative accounts by unauthorized users who use manual methods or automated tools to guess weak passwords. Strong passwords that are changed regularly reduce the likelihood of a successful password attack.
-
Introduced in Windows Server 2008 R2 and Windows Server 2008, Windows supports fine-grained password policies. This feature provides organizations with a way to define different password and account lockout policies for different sets of users in a domain. Fine-grained password policies apply only to user objects (or inetOrgPerson objects if they are used instead of user objects) and global security groups.
-
To apply a fine-grained password policy to users of an OU, you can use a shadow group. A shadow group is a global security group that is logically mapped to an OU to enforce a fine-grained password policy. You add users of the OU as members of the newly created shadow group and then apply the fine-grained password policy to this shadow group. You can create additional shadow groups for other OUs as needed. If you move a user from one OU to another, you must update the membership of the corresponding shadow groups.
-
Fine-grained password policies include attributes for all the settings that can be defined in the default domain policy (except Kerberos settings) in addition to account lockout settings. When you specify a fine-grained password policy, you must specify all of these settings. By default, only members of the Domain Admins group can set fine-grained password policies. However, you can also delegate the ability to set these policies to other users. The domain must be running at least Windows Server 2008 R2 or Windows Server 2008 to use fine-grained password policies. Fine-grained password policies cannot be applied to an organizational unit (OU) directly.
-
You can enforce the use of strong passwords through an appropriate password policy. There are password policy settings that control the complexity and lifetime of passwords, such as the **Passwords must meet complexity requirements** policy setting.
-
You can configure the password policy settings in the following location by using the Group Policy Management Console:
-
**Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Password Policy**
-
If individual groups require distinct password policies, these groups should be separated into another domain or forest, based on additional requirements.
-
The following topics provide a discussion of password policy implementation and best practices considerations, policy location, default values for the server type or GPO, relevant differences in operating system versions, security considerations (including the possible vulnerabilities of each setting), countermeasures that you can take, and the potential impact for each setting.
-
## In this section
-
-
@@ -76,19 +60,8 @@ The following topics provide a discussion of password policy implementation and
-
-
## Related topics
-
-
[Configure security policy settings](how-to-configure-security-policy-settings.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/perform-volume-maintenance-tasks.md b/windows/keep-secure/perform-volume-maintenance-tasks.md
index 6c1b779093..8080674711 100644
--- a/windows/keep-secure/perform-volume-maintenance-tasks.md
+++ b/windows/keep-secure/perform-volume-maintenance-tasks.md
@@ -2,50 +2,30 @@
title: Perform volume maintenance tasks (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Perform volume maintenance tasks security policy setting.
ms.assetid: b6990813-3898-43e2-8221-c9c06d893244
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Perform volume maintenance tasks
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Perform volume maintenance tasks** security policy setting.
-
## Reference
-
-
This policy setting determines which users can perform volume or disk management tasks, such as defragmenting an existing volume, creating or removing volumes, and running the Disk Cleanup tool.
-
Use caution when assigning this user right. Users with this user right can explore disks and extend files in to memory that contains other data. When the extended files are opened, the user might be able to read and modify the acquired data.
-
Constant: SeManageVolumePrivilege
-
### Possible values
-
- User-defined list of accounts
-
- Not Defined
-
### Best practices
-
- Ensure that only the local Administrators group is assigned the **Perform volume maintenance tasks** user right.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
By default this setting is Administrators on domain controllers and on stand-alone servers.
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -84,59 +64,27 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
A restart of the device is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
### Group Policy
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
A user who is assigned the **Perform volume maintenance tasks** user right could delete a volume, which could result in the loss of data or a denial-of- service condition. Also, disk maintenance tasks can be used to modify data on the disk, such as user rights assignments that might lead to escalation of privileges.
-
### Countermeasure
-
Ensure that only the local Administrators group is assigned the **Perform volume maintenance tasks** user right.
-
### Potential impact
-
None. Restricting the **Perform volume maintenance tasks** user right to the local Administrators group is the default configuration.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/plan-for-applocker-policy-management.md b/windows/keep-secure/plan-for-applocker-policy-management.md
index e3f5b525a5..d7b423cdb3 100644
--- a/windows/keep-secure/plan-for-applocker-policy-management.md
+++ b/windows/keep-secure/plan-for-applocker-policy-management.md
@@ -2,139 +2,71 @@
title: Plan for AppLocker policy management (Windows 10)
description: This topic for describes the decisions you need to make to establish the processes for managing and maintaining AppLocker policies.
ms.assetid: dccc196f-6ae0-4ae4-853a-a3312b18751b
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Plan for AppLocker policy management
-
-
**Applies to**
-
- Windows 10
-
This topic for describes the decisions you need to make to establish the processes for managing and maintaining AppLocker policies.
-
## Policy management
-
-
Before you begin the deployment process, consider how the AppLocker rules will be managed. Developing a process for managing AppLocker rules helps assure that AppLocker continues to effectively control how applications are allowed to run in your organization.
-
### Application and user support policy
-
Developing a process for managing AppLocker rules helps assure that AppLocker continues to effectively control how applications are allowed to run in your organization. Considerations include:
-
- What type of end-user support is provided for blocked applications?
-
- How are new rules added to the policy?
-
- How are existing rules updated?
-
- Are events forwarded for review?
-
**Help desk support**
-
If your organization has an established help desk support department in place, consider the following when deploying AppLocker policies:
-
- What documentation does your support department require for new policy deployments?
-
- What are the critical processes in each business group both in work flow and timing that will be affected by application control policies and how could they affect your support department's workload?
-
- Who are the contacts in the support department?
-
- How will the support department resolve application control issues between the end user and those who maintain the AppLocker rules?
-
**End-user support**
-
Because AppLocker is preventing unapproved apps from running, it is important that your organization carefully plan how to provide end-user support. Considerations include:
-
- Do you want to use an intranet site as a first line of support for users who have tried to run a blocked app?
-
- How do you want to support exceptions to the policy? Will you allow users to run a script to temporarily allow access to a blocked app?
-
**Using an intranet site**
-
AppLocker can be configured to display the default message but with a custom URL. You can use this URL to redirect users to a support site that contains information about why the user received the error and which applications are allowed. If you do not display a custom URL for the message when an app is blocked, the default URL is used.
-
The following image shows an example of the error message for a blocked app. You can use the **Set a support web link** policy setting to customize the **More information** link.
-
-
For steps to display a custom URL for the message, see [Display a custom URL message when users try to run a blocked app](display-a-custom-url-message-when-users-try-to-run-a-blocked-application.md).
-
**AppLocker event management**
-
Each time that a process requests permission to run, AppLocker creates an event in the AppLocker event log. The event details which file tried to run, the attributes of that file, the user that initiated the request, and the rule GUID that was used to make the AppLocker execution decision. The AppLocker event log is located in the following path: **Applications and Services Logs\\Microsoft\\Windows\\AppLocker**. The AppLocker log includes three logs:
-
1. **EXE and DLL**. Contains events for all files affected by the executable and DLL rule collections (.exe, .com, .dll, and .ocx).
-
2. **MSI and Script**. Contains events for all files affected by the Windows Installer and script rule collections (.msi, .msp, .ps1, .bat, .cmd, .vbs, and .js).
-
3. **Packaged app-Deployment** or **Packaged app-Execution**, contains events for all Universal Windows apps affected by the packaged app and packed app installer rule collection (.appx).
-
Collecting these events in a central location can help you maintain your AppLocker policy and troubleshoot rule configuration problems. Event collection technologies such as those available in Windows allow administrators to subscribe to specific event channels and have the events from source computers aggregated into a forwarded event log on a Windows Server operating system collector. For more info about setting up an event subscription, see [Configure Computers to Collect and Forward Events](http://go.microsoft.com/fwlink/p/?LinkId=145012).
-
### Policy maintenance
-
As new apps are deployed or existing apps are updated by the software publisher, you will need to make revisions to your rule collections to ensure that the policy is current.
-
You can edit an AppLocker policy by adding, changing, or removing rules. However, you cannot specify a version for the policy by importing additional rules. To ensure version control when modifying an AppLocker policy, use Group Policy management software that allows you to create versions of Group Policy Objects (GPOs). An example of this type of software is the Advanced Group Policy Management feature from the Microsoft Desktop Optimization Pack. For more info about Advanced Group Policy Management, see [Advanced Group Policy Management Overview](http://go.microsoft.com/fwlink/p/?LinkId=145013) (http://go.microsoft.com/fwlink/p/?LinkId=145013).
-
**Caution**
You should not edit an AppLocker rule collection while it is being enforced in Group Policy. Because AppLocker controls what files are allowed to run, making changes to a live policy can create unexpected behavior.
-
-
**New version of a supported app**
-
When a new version of an app is deployed in the organization, you need to determine whether to continue to support the previous version of that app. To add the new version, you might only need to create a new rule for each file that is associated with the app. If you are using publisher conditions and the version is not specified, then the existing rule or rules might be sufficient to allow the updated file to run. You must ensure, however, that the updated app has not altered the file names or added files to support new functionality. If so, then you must modify the existing rules or create new rules. To continue to reuse a publisher-based rule without a specific file version, you must also ensure that the file's digital signature is still identical to the previous version—the publisher, product name, and file name (if configured in your rule) must all match for the rule to be correctly applied.
-
To determine whether a file has been modified during an app update, review the publisher's release details provided with the update package. You can also review the publisher's web page to retrieve this information. Each file can also be inspected to determine the version.
-
For files that are allowed or denied with file hash conditions, you must retrieve the new file hash. To add support for a new version and maintain support for the older version, you can either create a new file hash rule for the new version or edit the existing rule and add the new file hash to the list of conditions.
-
For files with path conditions, you should verify that the installation path has not changed from what is stated in the rule. If the path has changed, you need to update the rule before installing the new version of the app
-
**Recently deployed app**
-
To support a new app, you must add one or more rules to the existing AppLocker policy.
-
**App is no longer supported**
-
If your organization has determined that it will no longer support an application that has AppLocker rules associated with it, the easiest way to prevent users from running the app is to delete these rules.
-
**App is blocked but should be allowed**
-
A file could be blocked for three reasons:
-
- The most common reason is that no rule exists to allow the app to run.
-
- There may be an existing rule that was created for the file that is too restrictive.
-
- A deny rule, which cannot be overridden, is explicitly blocking the file.
-
Before editing the rule collection, first determine what rule is preventing the file from running. You can troubleshoot the problem by using the **Test-AppLockerPolicy** Windows PowerShell cmdlet. For more info about troubleshooting an AppLocker policy, see [Testing and Updating an AppLocker Policy](http://go.microsoft.com/fwlink/p/?LinkId=160269) (http://go.microsoft.com/fwlink/p/?LinkId=160269).
-
## Next steps
-
-
After deciding how your organization will manage your AppLocker policy, record your findings.
-
- **End-user support policy.** Document the process that you will use for handling calls from users who have attempted to run a blocked app, and ensure that support personnel have clear escalation steps so that the administrator can update the AppLocker policy, if necessary.
-
- **Event processing.** Document whether events will be collected in a central location called a store, how that store will be archived, and whether the events will be processed for analysis.
-
- **Policy maintenance.** Detail how rules will be added to the policy and in which GPO the rules are defined.
-
For information and steps how to document your processes, see [Document your application control management processes](document-your-application-control-management-processes.md).
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/planning-and-deploying-advanced-security-audit-policies.md b/windows/keep-secure/planning-and-deploying-advanced-security-audit-policies.md
index 6895bda120..8a2a90eb1f 100644
--- a/windows/keep-secure/planning-and-deploying-advanced-security-audit-policies.md
+++ b/windows/keep-secure/planning-and-deploying-advanced-security-audit-policies.md
@@ -2,135 +2,72 @@
title: Planning and deploying advanced security audit policies (Windows 10)
description: This topic for the IT professional explains the options that security policy planners must consider and the tasks they must complete to deploy an effective security audit policy in a network that includes advanced security audit policies.
ms.assetid: 7428e1db-aba8-407b-a39e-509671e5a442
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Planning and deploying advanced security audit policies
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional explains the options that security policy planners must consider and the tasks they must complete to deploy an effective security audit policy in a network that includes advanced security audit policies.
-
Organizations invest a large portion of their information technology budgets on security applications and services, such as antimalware software, firewalls, and encryption. But no matter how much security hardware or software you deploy, how tightly you control the rights of users, or how carefully you configure security permissions on your data, you should not consider the job complete unless you have a well-defined, timely auditing strategy to track the effectiveness of your defenses and identify attempts to circumvent them.
-
To be well defined and timely, an auditing strategy must provide useful tracking data for an organization's most important resources, critical behaviors, and potential risks. In a growing number of organizations, it must also provide absolute proof that IT operations comply with corporate and regulatory requirements.
-
Unfortunately, no organization has unlimited resources to monitor every resource and activity on a network. If you do not plan well, you will likely have gaps in your auditing strategy. However, if you try to audit every resource and activity, you may find yourself with far too much monitoring data, including thousands of benign audit entries that an analyst needs to sift through to identify the narrow set of entries that warrant closer examination. This could cause delays or even prevent auditors from identifying suspicious activity. Thus, too much monitoring can leave an organization as vulnerable as not enough monitoring.
-
Here are some features that can help you focus your effort:
-
- **Advanced audit policy settings**. You can apply and manage detailed audit policy settings through Group Policy.
-
- **"Reason for access" auditing**. You can specify and identify the permissions that were used to generate a particular object access security event.
-
- **Global object access auditing**. You can define system access control lists (SACLs) for an entire computer file system or registry.
-
To deploy these features and plan an effective security auditing strategy, you need to:
-
- Identify your most critical resources and the most important activities that need to be tracked.
-
- Identify the audit settings that can be used to track these activities.
-
- Assess the advantages and potential costs associated with each.
-
- Test these settings to validate your choices.
-
- Develop plans for deploying and managing your audit policy.
-
## About this guide
-
-
This document will guide you through the steps needed to plan a security auditing policy that uses Windows auditing features. This policy must identify and address vital business needs, including:
-
- Network reliability
-
- Regulatory requirements
-
- Protection of the organization's data and intellectual property
-
- Users, including employees, contractors, partners, and customers
-
- Client computers and applications
-
- Servers and the applications and services running on those servers
-
The audit policy also must identify processes for managing audit data after it has been logged, including:
-
- Collecting, evaluating, and reviewing audit data
-
- Storing and (if required) disposing of audit data
-
By carefully planning, designing, testing, and deploying a solution based on your organization's business requirements, you can provide the standardized functionality, security, and management control that your organization needs.
-
## Understanding the security audit policy design process
-
-
The process of designing and deploying a Windows security audit policy involves the following tasks, which are described in greater detail throughout this document:
-
- [Identifying your Windows security audit policy deployment goals](#bkmk-1)
-
This section helps define the business objectives that will guide your Windows security audit policy. It also helps you define the resources, users, and computers that will be the focus of your security auditing.
-
- [Mapping the security audit policy to groups of users, computers, and resources in your organization](#bkmk-2)
-
This section explains how to integrate security audit policy settings with domain Group Policy settings for different groups of users, computers, and resources. In addition, if your network includes multiple versions of Windows client and server operating systems, it also explains when to use basic audit policy settings and when to use advanced security audit policy settings.
-
- [Mapping your security auditing goals to a security audit policy configuration](#bkmk-3)
-
This section explains the categories of Windows security auditing settings that are available. It also identifies individual Windows security auditing policy settings that can be of particular value to address auditing scenarios.
-
- [Planning for security audit monitoring and management](#bkmk-4)
-
This section helps you plan to collect, analyze, and store Windows audit data. Depending on the number of computers and types of activity that you want to audit, Windows event logs can fill up quickly. In addition, this section explains how auditors can access and aggregate event data from multiple servers and desktop computers. It also explains how to address storage requirements, including how much audit data to store and how it must be stored.
-
- [Deploying the security audit policy](#bkmk-5)
-
This section provides recommendations and guidelines for the effective deployment of a Windows security audit policy. Configuring and deploying Windows audit policy settings in a test lab environment can help you confirm that the settings you have selected will produce the type of audit data you need. However, only a carefully staged pilot and incremental deployments based on your domain and organizational unit (OU) structure will enable you to confirm that the audit data you generate can be monitored and that it meets your organization's audit needs.
-
## Identifying your Windows security audit policy deployment goals
-
-
A security audit policy must support and be a critical and integrated aspect of an organization's overall security design and framework.
-
Every organization has a unique set of data and network assets (such as customer and financial data and trade secrets), physical resources (such as desktop computers, portable computers, and servers), and users (which can include various internal groups such as finance and marketing, and external groups such as partners, customers, and anonymous users on the website). Not all of these assets, resources, and users justify the cost of an audit. Your task is to identify which assets, resources, and users provide the strongest justification for the focus of a security audit.
-
To create your Windows security audit plan, begin by identifying:
-
- The overall network environment, including the domains, OUs, and security groups.
-
- The resources on the network, the users of those resources, and how those resources are being used.
-
- Regulatory requirements.
-
### Network environment
-
An organization's domain and OU structure provide a fundamental starting point for thinking about how to apply a security audit policy because it likely provides a foundation of Group Policy Objects (GPOs) and logical grouping of resources and activities that you can use to apply the audit settings that you choose. It is also likely that certain portions of your domain and OU structure already provide logical groups of users, resources, and activities that justify the time and resources needed to audit them. For information about how to integrate a security audit policy with your domain and OU structure, see [Mapping security audit policy to groups of users, computers, and resources in your organization](#bkmk-2) later in this document.
-
In addition to your domain model, you should also find out whether your organization creates and maintains a systematic threat model. A good threat model can help you identify threats to key components in your infrastructure, so you can define and apply audit settings that enhance the organization's ability to identify and counter those threats.
-
**Important**
Including auditing within your organization's security plan also makes it possible to budget your resources on the areas where auditing can achieve the most positive results.
-
-
For additional details about how to complete each of these steps and how to prepare a detailed threat model, download the [IT Infrastructure Threat Modeling Guide](http://go.microsoft.com/fwlink/p/?LinkId=163432).
-
### Data and resources
-
For data and resource auditing, you need to identify the most important types of data and resources (such as patient records, accounting data, or marketing plans) that can benefit from the closer monitoring that Windows auditing can provide. Some of these data resources might already be monitored through auditing features in products such as Microsoft SQL Server and Exchange Server. If so, you may want to consider how Windows auditing features can enhance the existing audit strategy. As with the domain and OU structure discussed previously, security auditing should focus on your most critical resources. You also must consider how much audit data you will be able to manage.
-
You can record if these resources have high business impact, medium business impact, or low business impact, the cost to the organization if these data resources are accessed by unauthorized users, and the risk that this access can pose to the organization. The type of access by users (such as Read, Modify, or Copy) can also pose different levels of risk to an organization.
-
Increasingly, data access and use is governed by regulations, and a breach can result in severe penalties and a loss in credibility for the organization. If regulatory compliance plays a role in how you manage your data, be sure to also document this information.
-
The following table provides an example of a resource analysis for an organization.
-
@@ -176,23 +113,14 @@ The following table provides an example of a resource analysis for an organizati
-
-
### Users
-
Many organizations find it useful to classify the types of users they have and base permissions on this classification. This same classification can help you identify which user activities should be the subject of security auditing and the amount of audit data they will generate.
-
Organizations can create distinctions based on the type of rights and permissions needed by users to perform their jobs. For example, under the classification Administrators, larger organizations might assign local administrator responsibilities for a single computer, for specific applications such as Exchange Server or SQL Server, or for an entire domain. Under Users, permissions and Group Policy settings can apply to as many as all users in an organization or as few as a subset of the employees in a given department.
-
Also, if your organization is subject to regulatory requirements, user activities such as accessing medical records or financial data may need to be audited to verify that you are complying with these requirements.
-
To effectively audit user activity, begin by listing the different types of users in your organization and the types of data they need access to—in addition to the data they should not have access to.
-
Also, if external users can access any of your organization's data, be sure to identify them, including if they belong to a business partner, customer, or general user, the data they have access to, and the permissions they have to access that data.
-
The following table illustrates an analysis of users on a network. Although our example contains a single column titled "Possible auditing considerations," you may want to create additional columns to differentiate between different types of network activity, such as logon hours and permission use.
-
@@ -224,35 +152,21 @@ The following table illustrates an analysis of users on a network. Although our
-
-
### Computers
-
Security and auditing requirements and audit event volume can vary considerably for different types of computers in an organization. These requirements can be based on:
-
- If the computers are servers, desktop computers, or portable computers.
-
- The important applications the computers run, such as Exchange Server, SQL Server, or Forefront Identity Manager.
-
**Note**
If the server applications (including Exchange Server and SQL Server) have audit settings. For more information about auditing in Exchange Server, see the [Exchange 2010 Security Guide](http://go.microsoft.com/fwlink/p/?linkid=128052). For more information about auditing in SQL Server 2008, see [Auditing (Database Engine)](http://go.microsoft.com/fwlink/p/?LinkId=163434). For SQL Server 2012, see [SQL Server Audit (Database Engine)](http://technet.microsoft.com/library/cc280386.aspx).
-
-
- The operating system versions.
-
**Note**
The operating system version determines which auditing options are available and the volume of audit event data.
-
-
- The business value of the data.
-
For example, a web server that is accessed by external users requires different audit settings than a root certification authority (CA) that is never exposed to the public Internet or even to regular users on the organization's network.
-
The following table illustrates an analysis of computers in an organization.
-
@@ -289,265 +203,133 @@ The following table illustrates an analysis of computers in an organization.
-
-
### Regulatory requirements
-
Many industries and locales have strict and specific requirements for network operations and how resources are protected. In the health care and financial industries, for example, there are strict guidelines for who has access to records and how they are used. Many countries have strict privacy rules. To identify regulatory requirements, work with your organization's legal department and other departments responsible for these requirements. Then consider the security configuration and auditing options that can be used to comply with and verify compliance with these regulations.
-
For more info, see the [System Center Process Pack for IT GRC](http://technet.microsoft.com/library/dd206732.aspx).
-
## Mapping the security audit policy to groups of users, computers, and resources in your organization
-
-
By using Group Policy, you can apply your security audit policy to defined groups of users, computers, and resources. To map a security auditing policy to these defined groups in your organization, you should understand the following considerations for using Group Policy to apply security audit policy settings:
-
- The policy settings you identify can be applied by using one or more GPOs. To create and edit a GPO, use the Group Policy Management Console (GPMC). By using the GPMC to link a GPO to selected Active Directory sites, domains, and OUs, you apply the policy settings in the GPO to the users and computers in those Active Directory objects. An OU is the lowest-level Active Directory container to which you can assign Group Policy settings.
-
- For every policy setting that you select, you need to decide whether it should be enforced across the organization, or whether it should apply only to selected users or computers. You can then combine these audit policy settings into GPOs and link them to the appropriate Active Directory containers.
-
- By default, options set in GPOs that are linked to higher levels of Active Directory sites, domains, and OUs are inherited by all OUs at lower levels. However, a GPO that is linked at a lower level can overwrite inherited policies.
-
For example, you might use a domain GPO to assign an organization-wide group of audit settings, but want a certain OU to get a defined group of additional settings. To accomplish this, you can link a second GPO to that specific lower-level OU. Therefore, a logon audit setting that is applied at the OU level will override a conflicting logon audit setting that is applied at the domain level (unless you have taken special steps to apply Group Policy loopback processing).
-
- Audit policies are computer policies. Therefore, they must be applied through GPOs that are applied to computer OUs, not to user OUs. However, in most cases you can apply audit settings for only specified resources and groups of users by configuring SACLs on the relevant objects. This enables auditing for a security group that contains only the users you specify.
-
For example, you could configure a SACL for a folder called Payroll Data on Accounting Server 1. This can audit attempts by members of the Payroll Processors OU to delete objects from this folder. The **Object Access\\Audit File System** audit policy setting applies to Accounting Server 1, but because it requires a corresponding resource SACL, only actions by members of the Payroll Processors OU on the Payroll Data folder generates audit events.
-
- Advanced security audit policy settings were introduced in Windows Server 2008 R2 or Windows 7 and can be applied to those operating systems and later. These advanced audit polices can only be applied by using Group Policy.
-
**Important**
Whether you apply advanced audit policies by using Group Policy or by using logon scripts, do not use both the basic audit policy settings under **Local Policies\\Audit Policy** and the advanced settings under **Security Settings\\Advanced Audit Policy Configuration**. Using both basic and advanced audit policy settings can cause unexpected results in audit reporting.
-
If you use **Advanced Audit Policy Configuration** settings or use logon scripts to apply advanced audit policies, be sure to enable the **Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings** policy setting under **Local Policies\\Security Options**. This will prevent conflicts between similar settings by forcing basic security auditing to be ignored.
-
-
The following are examples of how audit policies can be applied to an organization's OU structure:
-
- Apply data activity settings to an OU that contains file servers. If your organization has servers that contain particularly sensitive data, consider putting them in a separate OU so that you can configure and apply a more precise audit policy to these servers.
-
- Apply user activity audit policies to an OU that contains all computers in the organization. If your organization places users in OUs based on the department they work in, consider configuring and applying more detailed security permissions on critical resources that are accessed by employees who work in more sensitive areas, such as network administrators or the legal department.
-
- Apply network and system activity audit policies to OUs that contain the organization's most critical servers, such as domain controllers, CAs, email servers, or database servers.
-
## Mapping your security auditing goals to a security audit policy configuration
-
-
After you identify your security auditing goals, you can begin to map them to a security audit policy configuration. This audit policy configuration must address your most critical security auditing goals, but it also must address your organization's constraints, such as the number of computers that need to be monitored, the number of activities that you want to audit, the number of audit events that your desired audit configuration will generate, and the number of administrators available to analyze and act upon audit data.
-
To create your audit policy configuration, you need to:
-
1. Explore all of the audit policy settings that can be used to address your needs.
-
2. Choose the audit settings that will most effectively address the audit requirements identified in the previous section.
-
3. Confirm that the settings you choose are compatible with the operating systems running on the computers that you want to monitor.
-
4. Decide which configuration options (Success, Failure, or both Success and Failure) you want to use for the audit settings.
-
5. Deploy the audit settings in a lab or test environment to verify that they meet your desired results in terms of volume, supportability, and comprehensiveness. Then deploy the audit settings in a pilot production environment to ensure that your estimates of how much audit data your audit plan will generate are realistic and that you can manage this data.
-
### Exploring audit policy options
-
Security audit policy settings in the supported versions of Windows can be viewed and configured in the following locations:
-
- **Security Settings\\Local Policies\\Audit Policy**.
-
- **Security Settings\\Local Policies\\Security Options**.
-
- **Security Settings\\Advanced Audit Policy Configuration**. For more information, see [Advanced security audit policy settings](advanced-security-audit-policy-settings.md).
-
### Choosing audit settings to use
-
Depending on your goals, different sets of audit settings may be of particular value to you. For example, some settings under **Security Settings\\Advanced Audit Policy Configuration** can be used to monitor the following types of activity:
-
- Data and resources
-
- Users
-
- Network
-
**Important**
Settings that are described in the Reference might also provide valuable information about activity audited by another setting. For example, the settings used to monitor user activity and network activity have obvious relevance to protecting your data resources. Likewise, attempts to compromise data resources have huge implications for overall network status, and potentially for how well you are managing the activities of users on the network.
-
-
### Data and resource activity
-
For many organizations, compromising the organization's data resources can cause tremendous financial losses, in addition to lost prestige and legal liability. If your organization has critical data resources that need to be protected against any breach, the following settings can provide extremely valuable monitoring and forensic data:
-
- Object Access\\[Audit File Share](audit-file-share.md). This policy setting allows you to track what content was accessed, the source (IP address and port) of the request, and the user account that was used for the access. The volume of event data generated by this setting will vary depending on the number of client computers that attempt to access the file share. On a file server or domain controller, volume may be high due to SYSVOL access by client computers for policy processing. If you do not need to record routine access by client computers that have permissions on the file share, you may want to log audit events only for failed attempts to access the file share.
-
- Object Access\\[Audit File System](audit-file-system.md). This policy setting determines whether the operating system audits user attempts to access file system objects. Audit events are only generated for objects (such as files and folders) that have configured SACLs, and only if the type of access requested (such as Write, Read, or Modify) and the account that is making the request match the settings in the SACL.
-
If success auditing is enabled, an audit entry is generated each time any account successfully accesses a file system object that has a matching SACL. If failure auditing is enabled, an audit entry is generated each time any user unsuccessfully attempts to access a file system object that has a matching SACL. The amount of audit data generated by the **Audit File System** policy setting can vary considerably, depending on the number of objects that have been configured to be monitored.
-
**Note**
To audit user attempts to access all file system objects on a computer, use the Global Object Access Auditing settings [Registry (Global Object Access Auditing)](registry-global-object-access-auditing.md) or [File System (Global Object Access Auditing)](file-system-global-object-access-auditing.md).
-
-
- Object Access\\[Audit Handle Manipulation](audit-handle-manipulation.md). This policy setting determines whether the operating system generates audit events when a handle to an object is opened or closed. Only objects with configured SACLs generate these events, and only if the attempted handle operation matches the SACL.
-
Event volume can be high, depending on how SACLs are configured. When used together with the **Audit File System** or **Audit Registry** policy settings, the **Audit Handle Manipulation** policy setting can provide an administrator with useful "reason for access" audit data that details the precise permissions on which the audit event is based. For example, if a file is configured as a Read-only resource but a user attempts to save changes to the file, the audit event will log not only the event, but also the permissions that were used (or attempted to be used) to save the file changes.
-
- **Global Object Access Auditing**. A growing number of organizations are using security auditing to comply with regulatory requirements that govern data security and privacy. But demonstrating that strict controls are being enforced can be extremely difficult. To address this issue, the supported versions of Windows include two **Global Object Access Auditing** policy settings, one for the registry and one for the file system. When you configure these settings, they apply a global system access control SACL on all objects of that class on a system, which cannot be overridden or circumvented.
-
**Important**
The **Global Object Access Auditing** policy settings must be configured and applied in conjunction with the **Audit File System** and **Audit Registry** audit policy settings in the **Object Access** category.
-
-
### User activity
-
The settings in the previous section relate to activity involving the files, folders, and network shares that are stored on a network, and the settings in this section focus on the users, including employees, partners, and customers, who may try to access those resources.
-
In the majority of cases, these attempts will be legitimate and a network needs to make vital data readily available to legitimate users. However in other cases, employees, partners, and others may attempt to access resources that they have no legitimate reason to access. Security auditing can be used to track a wide variety of user activities on a particular computer to diagnose and resolve problems for legitimate users and identify and address illegitimate activities. The following are a few important settings that you should evaluate to track user activity on your network:
-
- Account Logon\\[Audit Credential Validation](audit-credential-validation.md). This is an extremely important policy setting because it enables you to track every successful and unsuccessful attempt to present credentials for a user logon. In particular, a pattern of unsuccessful attempts may indicate that a user or application is using credentials that are no longer valid, or attempting to use a variety of credentials in succession in hope that one of these attempts will eventually be successful. These events occur on the computer that is authoritative for the credentials. For domain accounts, the domain controller is authoritative. For local accounts, the local computer is authoritative.
-
- Detailed Tracking\\[Audit Process Creation](audit-process-creation.md) and Detailed Tracking\\[Audit Process Termination](audit-process-termination.md). These policy settings can enable you to monitor the applications that a user opens and closes on a computer.
-
- DS Access\\[Audit Directory Service Access](audit-directory-service-access.md) and DS Access\\[Audit Directory Service Changes](audit-directory-service-changes.md). These policy settings provide a detailed audit trail of attempts to access create, modify, delete, move, or undelete objects in Active Directory Domain Services (AD DS). Only domain administrators have permissions to modify AD DS objects, so it is extremely important to identify malicious attempts to modify these objects. In addition, although domain administrators should be among an organization's most trusted employees, the use of **Audit Directory Service Access** and **Audit Directory Service Changes** settings allow you to monitor and verify that only approved changes are made to AD DS. These audit events are logged only on domain controllers.
-
- Logon/Logoff\\[Audit Account Lockout](audit-account-lockout.md). Another common security scenario occurs when a user attempts to log on with an account that has been locked out. It is important to identify these events and to determine whether the attempt to use an account that has been locked out is malicious.
-
- Logon/Logoff\\[Audit Logoff](audit-logoff.md) and Logon/Logoff\\[Audit Logon](audit-logon.md). Logon and logoff events are essential to tracking user activity and detecting potential attacks. Logon events are related to the creation of logon sessions, and they occur on the computer that was accessed. For an interactive logon, events are generated on the computer that was logged on to. For network logon, such as accessing a shared resource, events are generated on the computer that hosts the resource that was accessed. Logoff events are generated when logon sessions are terminated.
-
**Note**
There is no failure event for logoff activity because failed logoffs (such as when a system abruptly shuts down) do not generate an audit record. Logoff events are not 100 percent reliable. For example, the computer can be turned off without a proper logoff and shutdown, and a logoff event is not generated.
-
-
- Logon/Logoff\\[Audit Special Logon](audit-special-logon.md). A special logon has administrator-equivalent rights and can be used to elevate a process to a higher level. It is recommended to track these types of logons. For more information about this feature, see [article 947223](http://go.microsoft.com/fwlink/p/?linkid=120183) in the Microsoft Knowledge Base.
-
- Object Access\\[Audit Certification Services](audit-certification-services.md). This policy setting allows you to track and monitor a wide variety of activities on a computer that hosts Active Directory Certificate Services (AD CS) role services to ensure that only authorized users are performing or attempting to perform these tasks, and that only authorized or desired tasks are being performed.
-
- Object Access\\[Audit File System](audit-file-system.md) and Object Access\\[Audit File Share](audit-file-share.md). These policy settings are described in the previous section.
-
- Object Access\\[Audit Handle Manipulation](audit-handle-manipulation.md). This policy setting and its role in providing "reason for access" audit data is described in the previous section.
-
- Object Access\\[Audit Registry](audit-registry.md). Monitoring for changes to the registry is one of the most critical means that an administrator has to ensure malicious users do not make changes to essential computer settings. Audit events are only generated for objects that have configured SACLs, and only if the type of access that is requested (such as Write, Read, or Modify) and the account making the request match the settings in the SACL.
-
**Important**
On critical systems where all attempts to change registry settings need to be tracked, you can combine the **Audit Registry** policy setting with the **Global Object Access Auditing** policy settings to ensure that all attempts to modify registry settings on a computer are tracked.
-
-
- Object Access\\[Audit SAM](audit-sam.md). The Security Accounts Manager (SAM) is a database that is present on computers running Windows that stores user accounts and security descriptors for users on the local computer. Changes to user and group objects are tracked by the **Account Management** audit category. However, user accounts with the proper user rights could potentially alter the files where the account and password information is stored in the system, bypassing any **Account Management** events.
-
- Privilege Use\\[Audit Sensitive Privilege Use](audit-sensitive-privilege-use.md). **Privilege Use** policy settings and audit events allow you to track the use of certain rights on one or more systems. If you configure this policy setting, an audit event is generated when sensitive rights requests are made.
-
### Network activity
-
The following network activity policy settings allow you to monitor security-related issues that are not necessarily covered in the data or user activity categories, but that can be equally important for network status and protection.
-
- **Account Management**. The policy settings in this category can be used to track attempts to create, delete, or modify user or computer accounts, security groups, or distribution groups. Monitoring these activities complements the monitoring strategies you select in the user activity and data activity sections.
-
- Account Logon\\[Audit Kerberos Authentication Service](audit-kerberos-authentication-service.md) and Account Logon\\[Audit Kerberos Service Ticket Operations](audit-kerberos-service-ticket-operations.md). Audit policy settings in the **Account Logon** category monitor activities that relate to the use of domain account credentials. These policy settings complement the policy settings in the **Logon/Logoff** category. The **Audit Kerberos Authentication Service** policy setting allows you to monitor the status of and potential threats to the Kerberos service. The Audit **Kerberos Service Ticket Operations** policy setting allows you to monitor the use of Kerberos service tickets.
-
**Note**
**Account Logon** policy settings apply only to specific domain account activities, regardless of the computer that is accessed, whereas **Logon/Logoff** policy settings apply to the computer that hosts the resources being accessed.
-
-
- Account Logon\\[Audit Other Account Logon Events](audit-other-account-logon-events.md). This policy setting can be used to track a number of different network activities, including attempts to create Remote Desktop connections, wired network connections, and wireless connections.
-
- **DS Access**. Policy settings in this category allow you to monitor the AD DS role services, which provide account data, validate logons, maintain network access permissions, and provide other services that are critical to the secure and proper functioning of a network. Therefore, auditing the rights to access and modify the configuration of a domain controller can help an organization maintain a secure and reliable network. In addition, one of the key tasks performed by AD DS is the replication of data between domain controllers.
-
- Logon/Logoff\\[Audit IPsec Extended Mode](audit-ipsec-extended-mode.md), Logon/Logoff\\[Audit IPsec Main Mode](audit-ipsec-main-mode.md), and Logon/Logoff\\[Audit IPsec Quick Mode](audit-ipsec-quick-mode.md). Many networks support large numbers of external users, including remote employees and partners. Because these users are outside the organization's network boundaries, IPsec is often used to help protect communications over the Internet by enabling network-level peer authentication, data origin authentication, data integrity, data confidentiality (encryption), and protection against replay attacks. You can use these settings to ensure that IPsec services are functioning properly.
-
- Logon/Logoff\\[Audit Network Policy Server](audit-network-policy-server.md). Organizations that use RADIUS (IAS) and Network Access Protection (NAP) to set and maintain security requirements for external users can use this policy setting to monitor the effectiveness of these policies and to determine whether anyone is attempting to circumvent these protections.
-
- **Policy Change**. These policy settings and events allow you to track changes to important security policies on a local computer or network. Because policies are typically established by administrators to help secure network resources, any changes or attempts to change these policies can be an important aspect of security management for a network.
-
- Policy Change\\[Audit Audit Policy Change](audit-audit-policy-change.md). This policy setting allows you to monitor changes to the audit policy. If malicious users obtain domain administrator credentials, they can temporarily disable essential security audit policy settings so that their other activities on the network cannot be detected.
-
- Policy Change\\[Audit Filtering Platform Policy Change](audit-filtering-platform-policy-change.md). This policy setting can be used to monitor a large variety of changes to an organization's IPsec policies.
-
- Policy Change\\[Audit MPSSVC Rule-Level Policy Change](audit-mpssvc-rule-level-policy-change.md). This policy setting determines if the operating system generates audit events when changes are made to policy rules for the Microsoft Protection Service (MPSSVC.exe), which is used by Windows Firewall. Changes to firewall rules are important for understanding the security state of the computer and how well it is protected against network attacks.
-
### Confirm operating system version compatibility
-
Not all versions of Windows support advanced audit policy settings or the use of Group Policy to apply and manage these settings. For more info, see [Which editions of Windows support advanced audit policy configuration](which-editions-of-windows-support-advanced-audit-policy-configuration.md).
-
The audit policy settings under **Local Policies\\Audit Policy** overlap with audit policy settings under **Security Settings\\Advanced Audit Policy Configuration**. However, the advanced audit policy categories and subcategories make it possible to focus your auditing efforts on the most critical activities while reducing the amount of audit data that is less important to your organization.
-
For example, **Local Policies\\Audit Policy** contains a single setting called [Audit account logon events](http://technet.microsoft.com/library/cc787176.aspx). When this setting is configured, it generates at least 10 types of audit events.
-
In comparison, the Account Logon category under **Security Settings\\Advanced Audit Policy Configuration** provides the following advanced settings, which allow you to focus your auditing:
-
- Credential Validation
-
- Kerberos Authentication Service
-
- Kerberos Service Ticket Operations
-
- Other Account Logon Events
-
These settings allow you to exercise much tighter control over which activities or events generate event data. Some activities and events will be more important to your organization, so define the scope of your security audit policy as narrowly as possible.
-
### Success, failure, or both
-
Whichever event settings you include in your plan, you also have to decide whether you want to log an event when the activity fails, when an activity succeeds, or both successes and failures. This is an important question, and the answer will be based on the criticality of the event and the implications of the decision on event volume.
-
For example, on a file server that is accessed frequently by legitimate users, you may be interested in logging an event only when an unsuccessful attempt to access data takes place, because this could be evidence of an unauthorized or malicious user. And in this instance, logging successful attempts to access the server would quickly fill the event log with benign events.
-
On the other hand, if the file share has extremely sensitive and valuable information, such as trade secrets, you may want to log every access attempt, whether successful or unsuccessful, so that you have an audit trail of every user who accessed the resource.
-
## Planning for security audit monitoring and management
-
-
Networks can contain hundreds of servers running critical services or storing critical data, all of which need to be monitored. The number of client computers on the network can easily range into the tens or even hundreds of thousands. This may not be an issue if the ratio of servers or client computers per administrator is low. Even if an administrator who is responsible for auditing security and performance issues has relatively few computers to monitor, you need to decide how an administrator will obtain event data to review. Following are some options for obtaining the event data.
-
- Will you keep event data on a local computer until an administrator logs on to review this data? If so, then the administrator needs to have physical or remote access to the Event Viewer on each client computer or server, and the remote access and firewall settings on each client computer or server need to be configured to enable this access. In addition, you need to decide how often an administrator can visit each computer, and adjust the size of the audit log so that critical information is not deleted if the log reaches its maximum capacity.
-
- Will you collect event data so that it can be reviewed from a central console? If so, there are a number of computer management products, such as the Audit Collection Services in Operations Manager 2007 and 2012, which can be used to collect and filter event data. Presumably this solution enables a single administrator to review larger amounts of data than using the local storage option. But in some cases, this can make it more difficult to detect clusters of related events that can occur on a single computer.
-
In addition, whether you choose to leave audit data on an individual computer or consolidate it at a central location, you need to decide how large the log file should be and what should happen when the log reaches its maximum size. To configure these options, open Event Viewer, expand **Windows Logs**, right-click **Security**, and click **Properties**. You can configure the following properties:
-
- **Overwrite events as needed (oldest events first)**. This is the default option, which is an acceptable solution in most situations.
-
- **Archive the log when full, do not overwrite events**. This option can be used when all log data needs to be saved, but it also suggests that you may not be reviewing audit data frequently enough.
-
- **Do not overwrite events (Clear logs manually)**. This option stops the collection of audit data when the log file reaches its maximum size. Older data is retained at the expense of the most recent audit events. Use this option only if you do not want to lose any audit data, do not want to create an archive of the event log, and are committed to reviewing data before the maximum log size is reached.
-
You can also configure the audit log size and other key management options by using Group Policy settings. You can configure the event log settings in the following locations within the GPMC: **Computer Configuration\\Administrative Templates\\Windows Components\\Event Log Service\\Security**. These options include:
-
- **Maximum Log Size (KB)**. This policy setting specifies the maximum size of the log files. The user interfaces in the Local Group Policy Editor and Event Viewer allow you to enter values as large as 2 TB. If this setting is not configured, event logs have a default maximum size of 20 megabytes.
-
- **Log Access**. This policy setting determines which user accounts have access to log files and what usage rights are granted.
-
- **Retain old events**. This policy setting controls event log behavior when the log file reaches its maximum size. When this policy setting is enabled and a log file reaches its maximum size, new events are not written to the log and are lost. When this policy setting is disabled and a log file reaches its maximum size, new events overwrite old events.
-
- **Backup log automatically when full**. This policy setting controls event log behavior when the log file reaches its maximum size and takes effect only if the **Retain old events** policy setting is enabled. If you enable these policy settings, the event log file is automatically closed and renamed when it is full. A new file is then started. If you disable or do not configure this policy setting and the **Retain old events** policy setting is enabled, new events are discarded and the old events are retained.
-
In addition, a growing number of organizations are being required to store archived log files for a number of years. You should consult with regulatory compliance officers in your organization to determine whether such guidelines apply to your organization. For more information, see the [IT Compliance Management Guide](http://go.microsoft.com/fwlink/p/?LinkId=163435).
-
## Deploying the security audit policy
-
-
Before deploying the audit policy in a production environment, it is critical that you determine the effects of the policy settings that you have configured.
-
The first step in assessing your audit policy deployment is to create a test environment in a lab and use it to simulate the various use scenarios that you have identified to confirm that the audit settings you have selected are configured correctly and generate the type of results you intend.
-
However, unless you are able to run fairly realistic simulations of network usage patterns, a lab setup cannot provide you with accurate information about the volume of audit data that the audit policy settings you selected will generate and how effective your plan for monitoring audit data will be. To provide this type of information, you need to conduct one or more pilot deployments. These pilot deployments could involve:
-
- A single OU that contains critical data servers or an OU that contains all desktop computers in a specified location.
-
- A limited set of security audit policy settings, such as **Logon/Logoff** and **Account Logon**.
-
- A combination of limited OUs and audit policy settings—for example, targeting servers in only the Accounting OU with **Object Access** policy settings.
-
After you have successfully completed one or more limited deployments, you should confirm that the audit data that is collected is manageable with your management tools and administrators. When you have confirmed that the pilot deployment is effective, you need to confirm that you have the necessary tools and staff to expand the deployment to include additional OUs and sets of audit policy settings until the production deployment is complete.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/prepare-people-to-use-microsoft-passport.md b/windows/keep-secure/prepare-people-to-use-microsoft-passport.md
index e0d3c44e7e..74cebb3914 100644
--- a/windows/keep-secure/prepare-people-to-use-microsoft-passport.md
+++ b/windows/keep-secure/prepare-people-to-use-microsoft-passport.md
@@ -2,18 +2,17 @@
title: Prepare people to use Microsoft Passport (Windows 10)
description: When you set a policy to require Microsoft Passport in the workplace, you will want to prepare people in your organization.
ms.assetid: 5270B416-CE31-4DD9-862D-6C22A2AE508B
-keywords: ["identity", "PIN", "biometric", "Hello"]
+keywords: identity, PIN, biometric, Hello
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: jdeckerMS
---
# Prepare people to use Microsoft Passport
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
@@ -27,7 +26,6 @@ People who are currently using virtual smart cards for authentication can use th
## On devices owned by the organization
-
When someone sets up a new device, they are prompted to choose who owns the device. For corporate devices, they select **This device belongs to my organization**.
@@ -42,7 +40,6 @@ After Passport is set up, people use their PIN to unlock the device, and that wi
## On personal devices
-
People who want to access work resources on their personal devices can add a work or school account in **Settings** > **Accounts** > **Work or school**, and then sign in with work credentials. The person selects the method for receiving the verification code, such as text message or email. The verification code is sent and the person then enters the verification code. After verification, the person enters and confirms new PIN. The person can access any token-based resource using this device without being asked for credentials. (This work account gesture doesn't affect the device unlock PIN.)
Assure people that their work credentials and personal credentials are stored in separate containers; the enterprise has no access to their personal credentials.
@@ -51,55 +48,38 @@ People can go to **Settings** > **Accounts** > **Work or school**, select
## Using Windows Hello and biometrics
-
If your policy allows it, people can add Windows Hello to their Passport. Windows Hello can be fingerprint, iris, and facial recognition, and is available to users only if the hardware supports it.
## Use a phone to sign in to a PC
-
If your enterprise enables phone sign-in, users can pair a phone running Windows 10 Mobile to a PC running Windows 10 and then use an app on the phone to sign in to the PC using their Microsoft Passport credentials.
-
-**Note** Phone sign-in is currently limited to select Technology Adoption Program (TAP) participants.
-
+> **Note:** Phone sign-in is currently limited to select Technology Adoption Program (TAP) participants.
-
**Prerequisites:**
-
- The PC must be joined to the Active Directory domain or Azure AD cloud domain.
-
- The PC must have Bluetooth connectivity.
-
- The phone must be joined to the Azure AD cloud domain, or the user must have added a work account to their personal phone.
-
- The free **Phone Sign-in** app must be installed on the phone.
-
**Pair the PC and phone**
-
1. On the PC, go to **Settings** > **Devices** > **Bluetooth**. Tap the name of the phone and then tap **Pair** to begin pairing.
-
+
2. On the phone, go to **Settings** > **Devices** > **Bluetooth**, and verify that the passcode for **Pairing accessory** on the phone matches the passcode displayed on the PC, and then tap **ok**.
-
+
3. On the PC, tap **Yes**.
-
**Sign in to PC using the phone**
-
1. Open the **Phone Sign-in** app and tap the name of the PC to sign in to.
-
- **Note** The first time that you run the Phone-Sign app, you must add an account.
-
+ > **Note: ** The first time that you run the Phone-Sign app, you must add an account.
-
2. Enter the work PIN that you set up when you joined the phone to the cloud domain or added a work account.
## Related topics
-
[Manage identity verification using Microsoft Passport](manage-identity-verification-using-microsoft-passport.md)
[Implement Microsoft Passport in your organization](implement-microsoft-passport-in-your-organization.md)
@@ -111,12 +91,3 @@ If your enterprise enables phone sign-in, users can pair a phone running Windows
[Microsoft Passport errors during PIN creation](microsoft-passport-errors-during-pin-creation.md)
[Event ID 300 - Passport successfully created](passport-event-300.md)
-
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/prepare-your-organization-for-bitlocker-planning-and-policies.md b/windows/keep-secure/prepare-your-organization-for-bitlocker-planning-and-policies.md
index 2a4deccef8..56db3e6526 100644
--- a/windows/keep-secure/prepare-your-organization-for-bitlocker-planning-and-policies.md
+++ b/windows/keep-secure/prepare-your-organization-for-bitlocker-planning-and-policies.md
@@ -2,77 +2,43 @@
title: Prepare your organization for BitLocker Planning and policies (Windows 10)
description: This topic for the IT professional explains how can you plan your BitLocker deployment.
ms.assetid: 6e3593b5-4e8a-40ac-808a-3fdbc948059d
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Prepare your organization for BitLocker: Planning and policies
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional explains how can you plan your BitLocker deployment.
-
When you design your BitLocker deployment strategy, define the appropriate policies and configuration requirements based on the business requirements of your organization. The following topics will help you collect information that you can use to frame your decision-making process about deploying and managing BitLocker systems.
-
- [Audit your environment](#bkmk-audit)
-
- [Encryption keys and authentication](#bkk-encrypt)
-
- [TPM hardware configurations](#bkmk-tpmconfigurations)
-
- [Non-TPM hardware configurations](#bkmk-nontpm)
-
- [Disk configuration considerations](#bkmk-disk)
-
- [BitLocker provisioning](#bkmk-prov)
-
- [Used Disk Space Only encryption](#bkk-used)
-
- [Active Directory Domain Services considerations](#bkmk-addscons)
-
- [FIPS support for recovery password protector](#bkmk-fipssupport)
-
- [BitLocker Group Policy settings](bitlocker-group-policy-settings.md)
-
## Audit your environment
-
-
To plan your enterprise deployment of BitLocker, you must first understand your current environment. Conduct an informal audit to define your current policies, procedures, and hardware environment. Begin by reviewing your existing corporate security policies as they relate to disk encryption software. If your organization is not currently using disk encryption software, none of these policies will exist. If you are using disk encryption software, then you might need to modify your organization's policies to address the capabilities of BitLocker.
-
Use the following questions to help you document your organization's current disk encryption security policies:
-
1. Are there policies to address which computers will use BitLocker and which computers will not use BitLocker?
-
2. What policies exist to control recovery password and recovery key storage?
-
3. What are the policies for validating the identity of users that need to perform BitLocker recovery?
-
4. What policies exist to control who in the organization has access to recovery data?
-
5. What policies exist to control computer decommissioning or retirement?
-
## Encryption keys and authentication
-
-
BitLocker helps prevent unauthorized access to data on lost or stolen computers by:
-
- Encrypting the entire Windows operating system volume on the hard disk.
-
- Verifying the boot process integrity.
-
The trusted platform module (TPM)is a hardware component installed in many newer computers by the computer manufacturers. It works with BitLocker to help protect user data and to ensure that a computer has not been tampered with while the system was offline.
-
In addition, BitLocker offers the option to lock the normal startup process until the user supplies a personal identification number (PIN) or inserts a removable USB device, such as a flash drive, that contains a startup key. These additional security measures provide multifactor authentication and assurance that the computer will not start or resume from hibernation until the correct PIN or startup key is presented.
-
On computers that do not have a TPM version 1.2 or higher, you can still use BitLocker to encrypt the Windows operating system volume. However, this implementation will require the user to insert a USB startup key to start the computer or resume from hibernation, and does not provide the pre-startup system integrity verification offered by BitLocker working with a TPM.
-
**BitLocker key protectors**
-
@@ -111,11 +77,8 @@ On computers that do not have a TPM version 1.2 or higher, you can still use Bi
-
-
**BitLocker authentication methods**
-
@@ -157,36 +120,20 @@ On computers that do not have a TPM version 1.2 or higher, you can still use Bi
-
-
**Will you support computers without TPM version 1.2 or higher?**
-
Determine whether you will support computers that do not have a TPM version 1.2 or higher in your environment. If you choose to support BitLocker on this type of computer, a user must use a USB startup key to boot the system. This requires additional support processes similar to multifactor authentication.
-
**What areas of your organization need a baseline level of data protection?**
-
The TPM-only authentication method will provide the most transparent user experience for organizations that need a baseline level of data protection to meet security policies. It has the lowest total cost of ownership. TPM-only might also be more appropriate for computers that are unattended or that must reboot unattended.
-
However, TPM-only authentication method offers the lowest level of data protection. This authentication method protects against attacks that modify early boot components, but the level of protection can be affected by potential weaknesses in hardware or in the early boot components. BitLocker’s multifactor authentication methods significantly increase the overall level of data protection.
-
**What areas of your organization need a more secure level of data protection?**
-
If there are areas of your organization where data residing on user computers is considered highly-sensitive, consider the best practice of deploying BitLocker with multifactor authentication on those systems. Requiring the user to input a PIN significantly increases the level of protection for the system. You can also use BitLocker Network Unlock to allow these computers to automatically unlock when connected to a trusted wired network that can provide the Network Unlock key.
-
**What multifactor authentication method does your organization prefer?**
-
The protection differences provided by multifactor authentication methods cannot be easily quantified. Consider each authentication method's impact on Helpdesk support, user education, user productivity, and automated systems management processes.
-
## TPM hardware configurations
-
-
In your deployment plan, identify what TPM-based hardware platforms will be supported. Document the hardware models from an OEM of your choice, so that their configurations can be tested and supported. TPM hardware requires special consideration during all aspects of planning and deployment.
-
### TPM states of existence
-
For each of the TPM states of existence, the TPM can transition into another state (for example, moving from disabled to enabled). The states are not exclusive.
-
@@ -227,85 +174,43 @@ For each of the TPM states of existence, the TPM can transition into another sta
-
-
**Important**
BitLocker cannot use the TPM until it is in the following state: enabled, activated, and owned. When the TPM is in this state and only when it is in this state, all operations are available.
-
-
The state of the TPM exists independent of the computer’s operating system. Once the TPM is enabled, activated, and owned, the state of the TPM is preserved if the operating system is reinstalled.
-
### Endorsement keys
-
For a TPM to be usable by BitLocker, it must contain an endorsement key, which is an RSA key pair. The private half of the key pair is held inside the TPM and is never revealed or accessible outside the TPM. If the TPM does not contain an endorsement key, BitLocker will force the TPM to generate one automatically as part of BitLocker setup.
-
An endorsement key can be created at various points in the TPM’s lifecycle, but needs to be created only once for the lifetime of the TPM. If an endorsement key does not exist for the TPM, it must be created before TPM ownership can be taken.
-
For more information about the TPM and the TCG, see the Trusted Computing Group: Trusted Platform Module (TPM) Specifications ().
-
## Non-TPM hardware configurations
-
-
Devices that do not include a TPM can still be protected by drive encryption. Windows To Go workspaces can be BitLocker protected using a startup password and PCs without a TPM can use a startup key.
-
Use the following questions to identify issues that might affect your deployment in a non-TPM configuration:
-
- Are password complexity rules in place?
-
- Do you have budget for USB flash drives for each of these computers?
-
- Do your existing non-TPM devices support USB devices at boot time?
-
Test your individual hardware platforms with the BitLocker system check option while you are enabling BitLocker. The system check will ensure that BitLocker can read the recovery information from a USB device and encryption keys correctly before it encrypts the volume. CD and DVD drives cannot act as a block storage device and cannot be used to store the BitLocker recovery material.
-
## Disk configuration considerations
-
-
To function correctly, BitLocker requires a specific disk configuration. BitLocker requires two partitions that meet the following requirements:
-
- The operating system partition contains the operating system and its support files; it must be formatted with the NTFS file system
-
- The system partition (or boot partition) contains the files that are needed to load Windows after the BIOS or UEFI firware has prepared the system hardware. BitLocker is not enabled on this partition. For BitLocker to work, the system partition must not be encrypted and must be on a different partition than the operating system. On UEFI platforms the system partition must be formatted with the FAT 32 file system. On BIOS platforms the system partition must be formatted with the NTFS file system. It should be at least 350 MB in size
-
Windows setup will automatically configure the disk drives of your computer to support BitLocker encryption.
-
Windows Recovery Environment (Windows RE) is an extensible recovery platform that is based on Windows Pre-installation Environment (Windows PE). When the computer fails to start, Windows automatically transitions into this environment, and the Startup Repair tool in Windows RE automates the diagnosis and repair of an unbootable Windows installation. Windows RE also contains the drivers and tools that are needed to unlock a volume protected by BitLocker by providing a recovery key or recovery password. To use Windows RE in conjunction with BitLocker, the Windows RE boot image must reside on a volume that is not protected by BitLocker.
-
Windows RE can also be used from boot media other than the local hard disk. If you choose not to install Windows RE on the local hard disk of BitLocker-enabled computers, you can use alternate boot methods, such as Windows Deployment Services, CD-ROM, or USB flash drive, for recovery.
-
## BitLocker provisioning
-
-
In Windows Vista and Windows 7, BitLocker was provisioned post installation for system and data volumes through either the manage-bde command line interface or the Control Panel user interface. With newer operating systems, BitLocker can be easily provisioned before the operating system is installed. Preprovisioning requires that the computer have a TPM.
-
To check the BitLocker status of a particular volume, administrators can look at the status of the drive in the BitLocker control panel applet or Windows Explorer. A status of "Waiting For Activation" with a yellow exclamation icon means that the drive was preprovisioned for BitLocker. This status means that there was only a clear protector used when encrypting the volume. In this case, the volume is not protected and needs to have a secure key added to the volume before the drive is considered fully protected. Administrators can use the control panel options, manage-bde tool or WMI APIs to add an appropriate key protector and the volume status will be updated.
-
When using the control panel options, administrators can choose to **Turn on BitLocker** and follow the steps in the wizard to add a protector, such as a PIN for an operating system volume (or a password if no TPM exists), or a password or smart card protector to a data volume. Then the drive security window is presented prior to changing the volume status.
-
Administrators can enable BitLocker prior to operating system deployment from the Windows Pre-installation Environment (WinPE). This is done with a randomly generated clear key protector applied to the formatted volume and encrypting the volume prior to running the Windows setup process. If the encryption uses the Used Disk Space Only option this step takes only a few seconds and so incorporates well into regular deployment processes.
-
## Used Disk Space Only encryption
-
-
The BitLocker Setup wizard provides administrators the ability to choose the Used Disk Space Only or Full encryption method when enabling BitLocker for a volume. Administrators can use the new BitLocker Group Policy setting to enforce either Used Disk Space Only or Full disk encryption.
-
Launching the BitLocker Setup wizard prompts for the authentication method to be used (password and smart card are available for data volumes). Once the method is chosen and the recovery key is saved, you are asked to choose the drive encryption type, either Used Disk Space Only or Full drive encryption.
-
Used Disk Space Only means that only the portion of the drive that contains data will be encrypted, unused space will remain unencrypted. This causes the encryption process to be much faster, especially for new PCs and data drives. When BitLocker is enabled with this method as data is added to the drive the portion of the drive used will be encrypted, so there is never unencrypted data stored on the drive.
-
Full drive encryption means that the entire drive will be encrypted, regardless of whether data is stored on it or not. This is useful for drives that have been repurposed and may contain data remnants from their previous use.
-
## Active Directory Domain Services considerations
-
-
BitLocker integrates with Active Directory Domain Services (AD DS) to provide centralized key management. By default, no recovery information is backed up to Active Directory. Administrators can configure Group Policy settings to enable backup of BitLocker or TPM recovery information. Before configuring these settings verify that access permissions have been granted to perform the backup.
-
By default, domain administrators are the only users that will have access to BitLocker recovery information. When you plan your support process, define what parts of your organization need access to BitLocker recovery information. Use this information to define how the appropriate rights will be delegated in your AD DS environment.
-
It is a best practice to require backup of recovery information for both the TPM and BitLocker to AD DS. You can implement this practice by configuring the Group Policy settings below for your BitLocker-protected computers.
-
@@ -328,127 +233,63 @@ It is a best practice to require backup of recovery information for both the TPM
-
-
The following recovery data will be saved for each computer object:
-
- **Recovery password**
-
A 48-digit recovery password used to recover a BitLocker-protected volume. Users enter this password to unlock a volume when BitLocker enters recovery mode.
-
- **Key package data**
-
With this key package and the recovery password, you will be able decrypt portions of a BitLocker-protected volume if the disk is severely damaged. Each key package will only work with the volume it was created on, which can be identified by the corresponding volume ID.
-
- **TPM owner authorization password hash**
-
When ownership of the TPM is taken a hash of the ownership password can be taken and stored in AD DS. This information can then be used to reset ownership of the TPM.
-
Starting in Windows 8, a change to how the TPM owner authorization value is stored in AD DS was implemented in the AD DS schema. The TPM owner authorization value is now stored in a separate object which is linked to the Computer object. This value was stored as a property in the Computer object itself for the default Windows Server 2008 R2 and later schemas.
-
To take advantage of this integration, you must upgrade your domain controllers to Windows Server 2012 or extend the Active Directory schema and configure BitLocker-specific Group Policy objects.
-
**Note**
The account that you use to update the Active Directory schema must be a member of the Schema Admins group.
-
-
Windows Server 2012 domain controllers have the default schema to backup TPM owner authorization information in the separate object. If you are not upgrading your domain controller to Windows Server 2012 you need to extend the schema to support this change.
-
**To support Windows 8 and later computers that are managed by a Windows Server 2003 or Windows 2008 domain controller**
-
There are two schema extensions that you can copy down and add to your AD DS schema:
-
- **TpmSchemaExtension.ldf**
-
This schema extension brings parity with the Windows Server 2012 schema. With this change, the TPM owner authorization information is stored in a separate TPM object linked to the corresponding computer object. Only the Computer object that has created the TPM object can update it. This means that any subsequent updates to the TPM objects will not succeed in dual boot scenarios or scenarios where the computer is reimaged resulting in a new AD computer object being created. To support such scenarios, an update to the schema was created.
-
- **TpmSchemaExtensionACLChanges.ldf**
-
This schema update modifies the ACLs on the TPM object to be less restrictive so that any subsequent operating system which takes ownership of the computer object can update the owner authorization value in AD DS. However, this is less secure as any computer in the domain can now update the OwnerAuth of the TPM object (although it cannot read the OwnerAuth) and DOS attacks can be made from within the enterprise. The recommended mitigation in such a scenario is to do regular backup of TPM objects and enable auditing to track changes for these objects.
-
To download the schema extensions, see [AD DS schema extensions to support TPM backup](ad-ds-schema-extensions-to-support-tpm-backup.md).
-
If you have a Windows Server 2012 domain controller in your environment, the schema extensions are already in place and do not need to be updated.
-
**Caution**
To configure Group Policy objects to backup TPM and BitLocker information in AD DS at least one of the domain controllers in your forest must be running at least Windows Server 2008 R2.
-
If Active Directory backup of the TPM owner authorization value is enabled in an environment without the required schema extensions, the TPM provisioning will fail and the TPM will remain in a Not Ready state for computers running Windows 8 and later.
-
-
**Setting the correct permissions in AD DS**
-
To initialize the TPM successfully so that you can turn on BitLocker requires that the correct permissions for the SELF account in be set in AD DS for the **ms-TPMOwnerInformation** attribute. The following steps detail setting these permissions as required by BitLocker:
-
1. Open **Active Directory Users and Computers**.
-
2. Select the organizational unit (OU) which contains the computer accounts that will have BitLocker turned on.
-
3. Right-click the OU and click **Delegate Control** to open the **Delegation of Control** wizard.
-
4. Click **Next** to go to the **Users or Groups** page and then click **Add**.
-
5. In the **Select Users, Computers, or Groups** dialog box, type **SELF** as the object name and then click **OK** Once the object has been validated you will be returned to the **Users or Groups** wizard page and the SELF account will be listed. Click **Next**.
-
6. On the **Tasks to Delegate** page, choose **Create a custom task to delegate** and then click **Next**.
-
7. On the **Active Directory Object Type** page, choose **Only the following objects in the folder** and then check **Computer Objects** and then click **Next**.
-
8. On the **Permissions** page, for **Show these permissions**, check **General**, **Property-specific**, and **Creation/deletion of specific child objects**. Scroll down the **Permissions** list and check both **Write msTPM-OwnerInformation** and **Write msTPM-TpmInformationForComputer** then click **Next**.
-
9. Click **Finish** to apply the permissions settings.
-
## FIPS support for recovery password protector
-
-
Functionality introduced in Windows Server 2012 R2 and Windows 8.1, allows BitLocker to be fully functional in FIPS mode.
-
**Note**
The United States Federal Information Processing Standard (FIPS) defines security and interoperability requirements for computer systems that are used by the U.S. federal government. The FIPS 140 standard defines approved cryptographic algorithms. The FIPS 140 standard also sets forth requirements for key generation and for key management. The National Institute of Standards and Technology (NIST) uses the Cryptographic Module Validation Program (CMVP) to determine whether a particular implementation of a cryptographic algorithm is compliant with the FIPS 140 standard. An implementation of a cryptographic algorithm is considered FIPS 140-compliant only if it has been submitted for and has passed NIST validation. An algorithm that has not been submitted cannot be considered FIPS-compliant even if the implementation produces identical data as a validated implementation of the same algorithm.
-
-
Prior to these supported versions of Windows, when Windows was in FIPS mode, BitLocker prevented the creation or use of recovery passwords and instead forced the user to use recovery keys. For more information about these issues, see the support article [kb947249](http://support.microsoft.com/kb/947249).
-
But on computers running these supported systems with BitLocker enabled:
-
- FIPS-compliant recovery password protectors can be created when Windows is in FIPS mode. These protectors use the FIPS 140 NIST SP800-132 algorithm.
-
- Recovery passwords created in FIPS mode on Windows 8.1 can be distinguished from recovery passwords created on other systems.
-
- Recovery unlock using the FIPS-compliant algorithm based recovery password protector work in all cases that currently work for recovery passwords.
-
- When FIPS-compliant recovery passwords unlock volumes, the volume is unlocked to allow read/write access even while in FIPS mode.
-
- FIPS-compliant recovery password protectors can be exported and stored in AD a while in FIPS mode.
-
The BitLocker Group Policy settings for recovery passwords work the same for all Windows versions that support BitLocker, whether in FIPs mode or not.
-
However, you cannot use recovery passwords generated on a system in FIPS mode for systems earlier than Windows Server 2012 R2 and Windows 8.1. Recovery passwords created on Windows Server 2012 R2 and Windows 8.1 are incompatible with BitLocker on operating systems prior to Windows Server 2012 R2 and Windows 8.1; so recovery keys should be used instead.
-
## More information
-
-
[Trusted Platform Module](trusted-platform-module-overview.md)
-
[TPM Group Policy settings](trusted-platform-module-services-group-policy-settings.md)
-
[BitLocker frequently asked questions (FAQ)](bitlocker-frequently-asked-questions.md)
-
[BitLocker](bitlocker-overview.md)
-
[BitLocker Group Policy settings](bitlocker-group-policy-settings.md)
-
[BitLocker basic deployment](bitlocker-basic-deployment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/profile-single-process.md b/windows/keep-secure/profile-single-process.md
index 5144e6d70c..bcdfcfa6c0 100644
--- a/windows/keep-secure/profile-single-process.md
+++ b/windows/keep-secure/profile-single-process.md
@@ -2,50 +2,30 @@
title: Profile single process (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Profile single process security policy setting.
ms.assetid: c0963de4-4f5e-430e-bfcd-dfd68e66a075
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Profile single process
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Profile single process** security policy setting.
-
## Reference
-
-
This policy setting determines which users can view a sample performance of an application process. Typically, you do not need this user right to use the performance reporting tools included in the operating system. However, you do need this user right if the system’s monitor components are configured to collect data through Windows Management Instrumentation (WMI).
-
Constant: SeProfileSingleProcessPrivilege
-
### Possible values
-
- User-defined list of accounts
-
- Administrators
-
- Not Defined
-
### Best practices
-
- This right should not be granted to individual users. It should be granted only for trusted applications that monitor other programs.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
By default this setting is Administrators on domain controllers and on stand-alone servers.
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -84,59 +64,27 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
A restart of the device is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
### Group Policy
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
The **Profile single process** user right presents a moderate vulnerability. Attackers with this user right could monitor a computer's performance to help identify critical processes that they might want to attack directly. Attackers may be able to determine what processes run on the computer so that they could identify countermeasures that they may need to avoid, such as anti-virus software or an intrusion-detection system. They could also identify other users who are logged on to a computer.
-
### Countermeasure
-
Ensure that only the local Administrators group is assigned the **Profile single process** user right.
-
### Potential impact
-
If you remove the **Profile single process** user right from the Power Users group or other accounts, you could limit the abilities of users who are assigned to specific administrative roles in your environment. You should ensure that delegated tasks are not negatively affected.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/profile-system-performance.md b/windows/keep-secure/profile-system-performance.md
index e9fdad2be0..c35951cd49 100644
--- a/windows/keep-secure/profile-system-performance.md
+++ b/windows/keep-secure/profile-system-performance.md
@@ -2,50 +2,30 @@
title: Profile system performance (Windows 10)
description: This security policy reference topic for the IT professional describes the best practices, location, values, policy management, and security considerations for the Profile system performance security policy setting.
ms.assetid: ffabc3c5-9206-4105-94ea-84f597a54b2e
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Profile system performance
-
-
**Applies to**
-
- Windows 10
-
This security policy reference topic for the IT professional describes the best practices, location, values, policy management, and security considerations for the **Profile system performance** security policy setting.
-
## Reference
-
-
This security setting determines which users can use Windows performance monitoring tools to monitor the performance of system processes.
-
Constant: SeSystemProfilePrivilege
-
### Possible values
-
- User-defined list of accounts
-
- Administrators
-
- Not defined
-
### Best practices
-
- Ensure that only the local Administrators group is assigned the **Profile system performance** user right.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
By default this setting is Administrators on domain controllers and on stand-alone servers.
-
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
-
@@ -84,61 +64,28 @@ The following table lists the actual and effective default policy values for the
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
A restart of the device is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
Depending on your version of Windows and your environment, you might need to add this user right to the Local System account or the Local Service account if you encounter access errors when you use the Administrators account.
-
### Group Policy
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
The **Profile system performance** user right poses a moderate vulnerability. Attackers with this user right could monitor a computer's performance to help identify critical processes that they might want to attack directly. Attackers might also be able to determine what processes are active on the computer so that they could identify countermeasures to avoid, such as anti-virus software or an intrusion detection system.
-
### Countermeasure
-
Ensure that only the local Administrators group is assigned the **Profile system performance** user right.
-
### Potential impact
-
None. Restricting the **Profile system performance** user right to the local Administrators group is the default configuration.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/protect-bitlocker-from-pre-boot-attacks.md b/windows/keep-secure/protect-bitlocker-from-pre-boot-attacks.md
index 028698ebd6..8edf687f07 100644
--- a/windows/keep-secure/protect-bitlocker-from-pre-boot-attacks.md
+++ b/windows/keep-secure/protect-bitlocker-from-pre-boot-attacks.md
@@ -2,52 +2,27 @@
title: Protect BitLocker from pre-boot attacks (Windows 10)
description: This detailed guide will help you understand the circumstances under which the use of pre-boot authentication is recommended for devices running Windows 10, Windows 8.1, Windows 8, or Windows 7; and when it can be safely omitted from a device’s configuration.
ms.assetid: 24d19988-fc79-4c45-b392-b39cba4ec86b
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Protect BitLocker from pre-boot attacks
-
-
**Applies to**
-
- Windows 10
-
This detailed guide will help you understand the circumstances under which the use of pre-boot authentication is recommended for devices running Windows 10, Windows 8.1, Windows 8, or Windows 7; and when it can be safely omitted from a device’s configuration.
-
BitLocker uses encryption to protect the data on your drive, but BitLocker security is only effective when the encryption key is protected. Many users have relied on pre-boot authentication to protect the operating system’s integrity, disk encryption solution (for example, encryption keys), and the PC’s data from offline attacks. With pre-boot authentication, users must provide some form of credential before unlocking encrypted volumes and starting Windows. Typically, they authenticate themselves using a PIN or a USB flash drive as a key.
-
Full-volume encryption using BitLocker Drive Encryption is vital for protecting data and system integrity on devices running the Windows 10, Windows 8.1, Windows 8, or Windows 7 operating system. It is equally important to protect the BitLocker encryption key. On Windows 7 devices, sufficiently protecting that key often required pre-boot authentication, which many users find inconvenient and complicates device management.
-
Pre-boot authentication provides excellent startup security, but it inconveniences users and increases IT management costs. Every time the PC is unattended, the device must be set to hibernate (in other words, shut down and powered off); when the computer restarts, users must authenticate before the encrypted volumes are unlocked. This requirement increases restart times and prevents users from accessing remote PCs until they can physically access the computer to authenticate, making pre-boot authentication unacceptable in the modern IT world, where users expect their devices to turn on instantly and IT requires PCs to be constantly connected to the network.
-
If users lose their USB key or forget their PIN, they can’t access their PC without a recovery key. With a properly configured infrastructure, the organization’s support will be able to provide the recovery key, but doing so increases support costs, and users might lose hours of productive work time.
-
Starting with Windows 8, Secure Boot and Windows Trusted Boot startup process ensures operating system integrity, allowing Windows to start automatically while minimizing the risk of malicious startup tools and rootkits. In addition, many modern devices are fundamentally physically resistant to sophisticated attacks against the computer’s memory, and now Windows authenticates the user before making devices that may represent a threat to the device and encryption keys available for use.
-
## In this topic
-
-
The sections that follow help you understand which PCs still need pre-boot authentication and which can meet your security requirements without the inconvenience of it.
-
- [Types of attacks for volume encryption keys](types-of-attacks-for-volume-encryption-keys.md)
-
- [BitLocker countermeasures](bitlocker-countermeasures.md)
-
- [Choose the right BitLocker countermeasure](choose-the-right-bitlocker-countermeasure.md)
-
## See also
-
-
- [BitLocker overview](bitlocker-overview.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/protect-enterprise-data-using-edp.md b/windows/keep-secure/protect-enterprise-data-using-edp.md
index 132514c566..d647af4367 100644
--- a/windows/keep-secure/protect-enterprise-data-using-edp.md
+++ b/windows/keep-secure/protect-enterprise-data-using-edp.md
@@ -19,7 +19,7 @@ author: eross-msft
With the increase of employee-owned devices in the enterprise, there’s also an increasing risk of accidental data leak through apps and services, like email, social media, and the public cloud, which are outside of the enterprise’s control. For example, when an employee sends the latest engineering pictures from their personal email account, copies and pastes product info into a tweet, or saves an in-progress sales report to their public cloud storage.
-Enterprise data protection (EDP) helps to protect against this potential data leakage without otherwise interfering with the employee experience. EDP also helps to protect enterprise apps and data against accidental data leak on enterprise-owned devices and personal devices that employees bring to work without requiring changes to your environment or other apps. Finally, another data protection technology, Azure Rights Management also works alongside EDP to extend data protection for data that leaves the device, such as when email attachments are sent from an enterprise aware version of a rights management mail client.
+Enterprise data protection (EDP) helps to protect against this potential data leakage without otherwise interfering with the employee experience. EDP also helps to protect enterprise apps and data against accidental data leak on enterprise-owned devices and personal devices that employees bring to work without requiring changes to your environment or other apps.
## Prerequisites
You’ll need this software to run EDP in your enterprise:
@@ -37,23 +37,23 @@ EDP helps address your everyday challenges in the enterprise. Including:
- Helping to maintain the ownership and control of your enterprise data.
-- Managing apps that aren’t enterprise aware.
+- Helping control the network and data access and data sharing for apps that aren’t enterprise aware.
### EDP-protection modes
You can set EDP to 1 of 4 protection and management modes:
|Mode|Description|
|----|-----------|
-|Block |EDP looks for inappropriate data sharing practices and stops the employee from completing the action. This can include sharing info across non-enterprise-protected apps in addition to sharing enterprise data between other people and devices outside of your enterprise.|
+|Block |EDP looks for inappropriate data sharing practices and stops the employee from completing the action. This can include sharing info across non-enterprise-protected apps in addition to sharing enterprise data between apps or attempting to share outside of your organization’s network.|
|Override |EDP looks for inappropriate data sharing, warning employees if they do something deemed potentially unsafe. However, this management mode lets the employee override the policy and share the data, logging the action to your audit log, accessible through the [Reporting CSP](http://go.microsoft.com/fwlink/p/?LinkID=746459). |
-|Silent |EDP runs silently, logging inappropriate data sharing, without blocking anything.|
+|Silent |EDP runs silently, logging inappropriate data sharing, without blocking anything that would’ve been prompted for employee interaction while in Override mode. Unallowed actions, like apps inappropriately trying to access a network resource or EDP-protected data, are still blocked.|
|Off |EDP is turned off and doesn't help to protect or audit your data.After you turn off EDP, an attempt is made to decrypt any closed EDP-tagged files on the locally attached drives. |
**Note**
For more info about setting your EDP-protection modes, see either [Create an enterprise data protection (EDP) policy using Intune](create-edp-policy-using-intune.md) or [Create and deploy an enterprise data protection (EDP) policy using Configuration Manager](create-edp-policy-using-sccm.md), depending on your management solution.
## Why use EDP?
-EDP gives you a new way to manage data security for apps and documents, along with the ability to remove access to enterprise data from both enterprise and personal devices (after enrollment in an enterprise management solution, like Intune).
+EDP gives you a new way to manage data policy enforcement for apps and documents, along with the ability to remove access to enterprise data from both enterprise and personal devices (after enrollment in an enterprise management solution, like Intune).
-- **Change the way you think about data security.** As an enterprise admin, you need to maintain the security and confidentiality of your enterprise data. EDP helps make sure that your enterprise data is protected on employee-owned devices, even when the employee isn’t using the device. When employees create content on an enterprise-protected device, they can choose to save it as a work document. If it's a work document, it becomes locally-maintained as enterprise data.
+- **Change the way you think about data policy enforcement.** As an enterprise admin, you need to maintain compliance in your data policy and data access. EDP helps make sure that your enterprise data is protected on both corporate and employee-owned devices, even when the employee isn’t using the device. When employees create content on an enterprise-protected device, they can choose to save it as a work document. If it's a work document, it becomes locally-maintained as enterprise data.
- **Manage your enterprise documents, apps, and encryption modes.**
@@ -61,17 +61,17 @@ EDP gives you a new way to manage data security for apps and documents, along wi
- **Using protected apps.** Managed apps (apps that you've included on the **Protected Apps** list in your EDP policy) are allowed to access your enterprise data and will interact differently when used with unallowed, non-enterprise aware, or personal-only apps. For example, if EDP management is set to **Block**, your employees can copy and paste from one protected app to another protected app, but not to personal apps. Imagine an HR person wants to copy a job description from a protected app to the internal career website, an enterprise-protected location, but goofs and tries to paste into a personal app instead. The paste action fails and a notification pops up, saying that the app couldn’t paste because of a policy restriction. The HR person then correctly pastes to the career website without a problem.
- - **Managed apps and restrictions.** With EDP you can control which apps can access and use your enterprise data. After adding an app to your **Protected App** list, the app is trusted with enterprise data. All apps not on this list are potentially blocked from accessing your enterprise data, depending on your EDP management-mode.
+ - **Managed apps and restrictions.** With EDP you can control which apps can access and use your enterprise data. After adding an app to your **Protected App** list, the app is trusted with enterprise data. All apps that aren’t on this list are blocked from accessing your enterprise network resources and your EDP-protected data.
You don’t have to modify line-of-business apps that never touch personal data to list them as protected apps; just include them in the **Protected App** list.
- - **Deciding your level of data access.** EDP lets you block, allow overrides, or audit employees' data sharing actions. Blocking the action stops it immediately. Allowing overrides let the employee know there's a risk, but lets him or her continue to share the data while recording and auditing the action. Silent just logs the action without stopping it; collecting info that can help you to see patterns of inappropriate sharing so you can take educative action or find apps that should be added to your **Protected App** list.
+ - **Deciding your level of data access.** EDP lets you block, allow overrides, or audit employees' data sharing actions. Blocking the action stops it immediately. Allowing overrides let the employee know there's a risk, but lets him or her continue to share the data while recording and auditing the action. Silent just logs the action without blocking anything that the employee could've overridden while using that setting; collecting info that can help you to see patterns of inappropriate sharing so you can take educative action or find apps that should be added to your **Protected App** list.
- - **Continuous data encryption.** EDP helps protect enterprise data when it leaves a device. For example, when an employee saves to public cloud storage, or synchronizes with another device.
- Apps such as Microsoft Word work with EDP to continue your data encryption across locations and services. These apps are being referred to as, *enterprise aware*. For example, if an employee opens EDP-encrypted content from Word, edits the content, and then tries to save the edited version with a different name, Word automatically applies EDP to the new document, maintaining the encryption.
+ - **Continuous data encryption.** EDP helps protect enterprise data on local files and on removable media.
+ Apps such as Microsoft Word work with EDP to help continue your data protection across local files and removable media. These apps are being referred to as, enterprise aware. For example, if an employee opens EDP-encrypted content from Word, edits the content, and then tries to save the edited version with a different name, Word automatically applies EDP to the new document.
- **Helping prevent accidental data disclosure to public spaces.** EDP helps protect your enterprise data from being accidentally shared to public spaces, such as public cloud storage. For example, if Dropbox™ isn’t on your **Protected App** list, employees won’t be able to sync encrypted files to their personal cloud storage. Instead, if the employee stores the content to an app on your **Protected Apps** list, like Microsoft OneDrive for Business, the encrypted files can sync freely to the cloud, while maintaining the encryption.
- - **Helping prevent accidental data disclosure to other devices.** EDP helps prevent enterprise data from leaking when it's copied or transferred to other devices. For example, if an employee puts enterprise data on a Universal Serial Bus (USB) drive that also has personal data, the enterprise data remains encrypted while the personal data doesn’t.
+ - **Helping prevent accidental data disclosure to removable media.** EDP helps prevent enterprise data from leaking when it's copied or transferred to removable media. For example, if an employee puts enterprise data on a Universal Serial Bus (USB) drive that also has personal data, the enterprise data remains encrypted while the personal data doesn’t.
- **Remove access to enterprise data from enterprise-protected devices.** EDP gives admins the ability to revoke enterprise data from one or many MDM-enrolled devices, while leaving personal data alone. This is a benefit when an employee leaves your company, or in the case of a stolen device. After determining that the data access needs to be removed, you can unenroll the device so when it connects to the network, the user's encryption key for the device is revoked and the enterprise data becomes unreadable.
**Note**
System Center Configuration Manager also allows you to revoke enterprise data. However, it does it by performing a factory reset of the device.
@@ -83,7 +83,6 @@ Use the following table to identify the scenarios that require Azure Rights Mana
|EDP scenario |Without Azure Rights Management |Workaround |
|-------------|--------------------------------|-----------|
|Saving enterprise data to USB drives |Data in the new location remains encrypted, but becomes inaccessible on other devices or for other users. For example, the file won't open or the file opens, but doesn't contain readable text. |Share files with fellow employees through enterprise file servers or enterprise cloud locations. If data must be shared via USB, employees can decrypt protected files, but it will be audited.
We strongly recommend educating employees about how to limit or eliminate the need for this decryption. |
-|Sharing enterprise data through email attachments |The attachment is sent unprotected. |Store documents on enterprise cloud or network sites, and share links. |
|Synchronizing data to other services or public cloud storage |Synchronized files aren't protected on additional services or as part of public cloud storage. |Stop the app from synchronizing or don't add the app to your **Protected App** list.
For more info about adding apps to the **Protected App** list, see either the [Create an enterprise data protection (EDP) policy using Intune](create-edp-policy-using-intune.md) or the [Create and deploy an enterprise data protection (EDP) policy using Configuration Manager](create-edp-policy-using-sccm.md) topic, depending on your management solution.
## Next steps
diff --git a/windows/keep-secure/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.md b/windows/keep-secure/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.md
index 5d96128049..bc3658f201 100644
--- a/windows/keep-secure/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.md
+++ b/windows/keep-secure/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.md
@@ -2,98 +2,54 @@
title: Control the health of Windows 10-based devices (Windows 10)
description: This article details an end-to-end solution that helps you protect high-value assets by enforcing, controlling, and reporting the health of Windows 10-based devices.
ms.assetid: 45DB1C41-C35D-43C9-A274-3AD5F31FE873
+ms.pagetype: security; devices
keywords: ["security", "BYOD", "malware", "device health attestation", "mobile"]
ms.prod: W10
ms.mktglfcycl: manage
ms.sitesec: library
author: arnaudjumelet
---
-
# Control the health of Windows 10-based devices
-
-
**Applies to**
-
- Windows 10
-
This article details an end-to-end solution that helps you protect high-value assets by enforcing, controlling, and reporting the health of Windows 10-based devices.
-
## Introduction
-
-
In Bring Your Own Device (BYOD) scenarios, employees bring commercially available devices to access both work-related resources and their personal data. Users want to use the device of their choice to access the organization’s applications, data, and resources not only from the internal network but also from anywhere. This phenomenon is also known as the consumerization of IT.
-
Users want to have the best productivity experience when accessing corporate applications and working on organization data from their devices. That means they will not tolerate being prompted to enter their work credentials each time they access an application or a file server. From a security perspective, it also means that users will manipulate corporate credentials and corporate data on unmanaged devices.
-
With the increased use of BYOD, there will be more unmanaged and potentially unhealthy systems accessing corporate services, internal resources, and cloud apps.
-
Even managed devices can be compromised and become harmful. Organizations need to detect when security has been breached and react as early as possible in order to protect high-value assets.
-
As Microsoft moves forward, security investments are increasingly focused on security preventive defenses and also on detection and response capabilities.
-
Windows 10 is an important component of an end-to-end security solution that focuses not only on the implementation of security preventive defenses, but adds device health attestation capabilities to the overall security strategy.
-
## Description of a robust end-to-end security solution
-
-
Today’s computing threat landscape is increasing at a speed never encountered before. The sophistication of criminal attacks is growing, and there is no doubt that malware now targets both consumers and professionals in all industries.
-
During recent years, one particular category of threat has become prevalent: advanced persistent threats (APTs). The term APT is commonly used to describe any attack that seems to target individual organizations on an on-going basis. In fact, this type of attack typically involves determined adversaries who may use any methods or techniques necessary.
-
With the BYOD phenomena, a poorly maintained device represents a target of choice. For an attacker, it’s an easy way to breach the security network perimeter, gain access to, and then steal high-value assets.
-
The attackers target individuals, not specifically because of who they are, but because of who they work for. An infected device will bring malware into an organization, even if the organization has hardened the perimeter of networks or has invested in its defensive posture. A defensive strategy is not sufficient against these threats.
-
### A different approach
-
Rather than the traditional focus on the prevention of compromise, an effective security strategy assumes that determined adversaries will successfully breach any defenses. It means that it’s necessary to shift focus away from preventative security controls to detection of, and response to, security issues. The implementation of the risk management strategy, therefore, balances investment in prevention, detection, and response.
-
Because mobile devices are increasingly being used to access corporate information, some way to evaluate device security or health is required. This section describes how to provision device health assessment in such a way that high-value assets can be protected from unhealthy devices.
-
Devices that are used to access corporate resources must be trusted. An efficient end-to-end security approach is able to evaluate device health and use the current security state when granting access to a high-value asset.
-
-
A robust design needs to establish the user’s identity, strengthen the authentication method if needed, and learn behavior like the network location the user regularly connects from. Also, a modern approach must be able to release sensitive content only if user devices are determined to be healthy and secure.
-
The following figure shows a solution built to assess device health from the cloud. The device authenticates the user through a connection to an identity provider in the cloud. If the managed asset contains highly confidential information, the conditional access engine of the identity provider may elect to verify the security compliance of the mobile device before access is granted. The user’s device is able to prove its health status that can be sent at any time or when mobile device management (MDM) requests it.
-
-
Windows devices can be protected from low-level rootkits and bootkits by using low-level hardware technologies such as Unified Extensible Firmware Interface (UEFI) Secure Boot.
-
Secure Boot is a firmware validation process that helps prevent rootkit attacks; it is part of the UEFI specification. The intent of UEFI is to define a standard way for the operating system to communicate with modern hardware, which can perform faster and with more efficient input/output (I/O) functions than older, software interrupt-driven BIOS systems.
-
A device health attestation module can communicate measured boot data that is protected by a Trusted Platform Module (TPM) to a remote service. After the device successfully boots, boot process measurement data is sent to a trusted cloud service (Health Attestation Service) using a more secure and tamper-resistant communication channel.
-
Remote health attestation service performs a series of checks on the measurements. It validates security related data points, including boot state (Secure Boot, Debug Mode, and so on), and the state of components that manage security (BitLocker, Device Guard, and so on). It then conveys the health state of the device by sending a health encrypted blob back to the device.
-
An MDM solution typically applies configuration policies and deploys software to devices. MDM defines the security baseline and knows the level of compliance of the device with regular checks to see what software is installed and what configuration is enforced, as well as determining the health status of the device.
-
An MDM solution asks the device to send device health information and forward the health encrypted blob to the remote health attestation service. The remote health attestation service verifies device health data, checks that MDM is communicating to the same device, and then issues a device health report back to the MDM solution.
-
An MDM solution evaluates the health assertions and, depending on the health rules belonging to the organization, can decide if the device is healthy. If the device is healthy and compliant, MDM passes that information to the identity provider so the organization’s access control policy can be invoked to grant access.
-
Access to content is then authorized to the appropriate level of trust for whatever the health status and other conditional elements indicate.
-
Depending on the requirements and the sensitivity of the managed asset, device health status can be combined with user identity information when processing an access request. Access to content is then authorized to the appropriate level of trust. The Conditional Access engine may be structured to allow additional verification as needed by the sensitivity of the managed asset. For example, if access to high-value data is requested, additional security authentication may need to be established by querying the user to answer a phone call before access is granted.
-
### Microsoft’s security investments in Windows 10
-
In Windows 10, there are three pillars of investments:
-
- **Secure identities.** Microsoft is part of the FIDO Alliance which aims to provide an interoperable method of secure authentication by moving away from the use of passwords for authentication, both on the local system as well as for services like on-premises resources and cloud resources.
-
- **Information protection.** Microsoft is making investments to allow organizations to have better control over who has access to important data and what they can do with that data. With Windows 10, organizations can take advantage of policies that specify which applications are considered to be corporate applications and can be trusted to access secure data.
-
- **Threat resistance.** Microsoft is helping organizations to better secure enterprise assets against the threats of malware and attacks by using security defenses relying on hardware.
-
### Protect, control, and report on the security status of Windows 10-based devices
-
This section is an overview that describes different parts of the end-to-end security solution that helps protect high-value assets and information from attackers and malware.
-
-
@@ -140,266 +96,138 @@ This section is an overview that describes different parts of the end-to-end sec
-
-
The combination of Windows 10-based devices, identity provider, MDM, and remote health attestation creates a robust end-to-end-solution that provides validation of health and compliance of devices that access high-value assets.
-
## Protect devices and enterprise credentials against threats
-
-
This section describes what Windows 10 offers in terms of security defenses and what control can be measured and reported to.
-
### Windows 10 hardware-based security defenses
-
The most aggressive forms of malware try to insert themselves into the boot process as early as possible so that they can take control of the operating system early and prevent protection mechanisms and antimalware software from working. This type of malicious code is often called a rootkit or bootkit. The best way to avoid having to deal with low-level malware is to secure the boot process so that the device is protected from the very start.
-
Windows 10 supports multiple layers of boot protection. Some of these features are available only if specific types of hardware are installed. For more information, see the [Hardware requirements](#hardware-req) section.
-
-
Windows 10 supports features to help prevent sophisticated low-level malware like rootkits and bootkits from loading during the startup process:
-
- **Trusted Platform Module.** A Trusted Platform Module (TPM) is a hardware component that provides unique security features.
-
Windows 10 leverages security characteristics of a TPM for measuring boot integrity sequence (and based on that, unlocking automatically BitLocker protected drives), for protecting credentials or for health attestation.
-
A TPM implements controls that meet the specification described by the Trusted Computing Group (TCG). At the time of this writing, there are two versions of TPM specification produced by TCG that are not compatible with each other:
-
- The first TPM specification, version 1.2, was published in February 2005 by the TCG and standardized under ISO / IEC 11889 standard.
-
- The latest TPM specification, referred to as TPM 2.0, was released in April 2014 and has been approved by the ISO/IEC Joint Technical Committee (JTC) as ISO/IEC 11889:2015.
-
Windows 10 uses the TPM for cryptographic calculations as part of health attestation and to protect the keys for BitLocker, Microsoft Passport, virtual smart cards, and other public key certificates. For more information, see [TPM requirements in Windows 10](http://go.microsoft.com/fwlink/p/?LinkId=733948).
-
Windows 10 recognizes versions 1.2 and 2.0 TPM specifications produced by the TCG. For the most recent and modern security features, Windows 10 supports only TPM 2.0. TPM 2.0 is required for device health attestation.
-
TPM 2.0 provides a major revision to the capabilities over TPM 1.2:
-
- Update crypto strength to meet modern security needs
-
- Support for SHA-256 for PCRs
-
- Support for HMAC command
-
- Cryptographic algorithms flexibility to support government needs
-
- TPM 1.2 is severely restricted in terms of what algorithms it can support
-
- TPM 2.0 can support arbitrary algorithms with minor updates to the TCG specification documents
-
- Consistency across implementations
-
- The TPM 1.2 specification allows vendors wide latitude when choosing implementation details
-
- TPM 2.0 standardizes much of this behavior
-
- **Secure Boot.** Devices with UEFI firmware can be configured to load only trusted operating system bootloaders. Secure Boot does not require a TPM.
-
The most basic protection is the Secure Boot feature, which is a standard part of the UEFI 2.2+ architecture. On a PC with conventional BIOS, anyone who can take control of the boot process can boot by using an alternative OS loader, and potentially gain access to system resources. When Secure Boot is enabled, you can boot using only an OS loader that’s signed using a certificate stored in the UEFI Secure Boot DB. Naturally, the Microsoft certificate used to digitally sign the Windows 10 OS loaders are in that store, which allows UEFI to validate the certificate as part of its security policy. Secure Boot must be enabled by default on all computers that are certified for Windows 10 under the Windows Hardware Compatibility Program.
-
Secure Boot is a UEFI firmware-based feature, which allows for the signing and verification of critical boot files and drivers at boot time. Secure Boot checks signature values of the Windows Boot Manager, BCD store, Windows OS loader file, and other boot critical DLLs at boot time before the system is allowed to fully boot into a usable operating system by using policies that are defined by the OEM at build time. Secure Boot prevents many types of boot-based rootkit, malware, and other security-related attacks against the Windows platform. Secure Boot protects the operating system boot process whether booting from local hard disk, USB, PXE, or DVD, or into full Windows or Windows Recovery Environment (RE).
-
Secure Boot protects the boot environment of a Windows 10 installation by verifying the signatures of the critical boot components to confirm malicious activity did not compromise them. Secure Boot protection ends after the Windows kernel file (ntoskrnl.exe) has been loaded.
-
**Note**
Secure Boot protects the platform until the Windows kernel is loaded. Then protections like ELAM take over.
-
-
- **Secure Boot configuration policy.** Extends Secure Boot functionality to critical Windows 10 configuration.
-
Examples of protected configuration information include protecting Disable Execute bit (NX option) or ensuring that the test signing policy (code integrity) cannot be enabled. This ensures that the binaries and configuration of the computer can be trusted after the boot process has completed.
-
Secure Boot configuration policy does this with UEFI policy. These signatures for these policies are signed in the same way that operating system binaries are signed for use with Secure Boot.
-
The Secure Boot configuration policy must be signed by a private key that corresponds to one of the public keys stored in the Key Exchange Key (KEK) list. The Microsoft Certificate Authority (CA) will be present in the KEK list of all Windows certified Secure Boot systems. By default, a policy signed by the Microsoft KEK shall be work on all Secure Boot systems. BootMgr must verify the signature against the KEK list before applying a signed policy. With Windows 10, the default Secure Boot configuration policy is embedded in bootmgr.
-
The bootloader verifies the digital signature of the Windows 10 kernel before loading it. The Windows 10 kernel, in turn, verifies every other component of the Windows startup process, including the boot drivers, startup files, and the ELAM component. This step is important and protects the rest of the boot process by verifying that all Windows boot components have integrity and can be trusted.
-
- **Early Launch Antimalware (ELAM).** ELAM tests all drivers before they load and prevents unapproved drivers from loading.
-
Traditional antimalware apps don’t start until after the boot drivers have been loaded, which gives a rootkit that is disguised as a driver the opportunity to work. ELAM is a Windows mechanism introduced in a previous version of Windows that allows antimalware software to run very early in the boot sequence. Thus, the antimalware component is the first third-party component to run and control the initialization of other boot drivers until the Windows operating system is operational. When the system is started with a complete runtime environment (network access, storage, and so on), then a full-featured antimalware is loaded.
-
ELAM can load a Microsoft or non-Microsoft antimalware driver before all non-Microsoft boot drivers and applications, thus continuing the chain of trust established by Secure Boot and Trusted Boot. Because the operating system hasn’t started yet, and because Windows needs to boot as quickly as possible, ELAM has a simple task: Examine every boot driver and determine whether it is on the list of trusted drivers. If it’s not trusted, Windows won’t load it.
-
**Note**
Windows Defender, Microsoft's antimalware included by default in Windows 10, supports ELAM; it can be replaced with a third-party antimalware compatible solution. The name of the Windows Defender ELAM driver is WdBoot.sys. Windows Defender in Windows 10 uses its ELAM driver to roll back any malicious changes made to the Windows Defender driver at the next reboot. This prevents kernel mode malware making lasting changes to Windows Defender’s mini-filter driver before shutdown or reboot.
-
-
The ELAM signed driver is loaded before any other third-party drivers or applications, which allows the antimalware software to detect and block any attempts to tamper with the boot process by trying to load unsigned or untrusted code.
-
The ELAM driver is a small driver with a small policy database that has a very narrow scope, focused on drivers that are loaded early at system launch. The policy database is stored in a registry hive that is also measured to the TPM, to record the operational parameters of the ELAM driver. An ELAM driver must be signed by Microsoft and the associated certificate must contain the complementary EKU (1.3.6.1.4.1.311.61.4.1).
-
- **Virtualization-based security (Hyper-V + Secure Kernel).** Virtualization-based security is a completely new enforced security boundary that allows you to protect critical parts of Windows 10.
-
Virtualization-based security isolates sensitive code like Kernel Mode Code Integrity or sensitive corporate domain credentials from the rest of the Windows operating system. For more information, refer to the [Virtualization-based security](#virtual) section.
-
- **Hyper-V Code Integrity (HVCI).** Hyper-V Code Integrity is a feature of Device Guard that ensures only drivers, executables, and DLLs that comply with the Device Guard Code Integrity policy are allowed to run.
-
When enabled and configured, Windows 10 can start the Hyper-V virtualization-based security services, including Hyper-V Code Integrity (HVCI). HVCI helps protect the system core (kernel), privileged drivers, and system defenses, like antimalware solutions, by preventing malware from running early in the boot process, or after startup.
-
HVCI uses virtualization-based security to isolate Code Integrity, the only way kernel memory can become executable is through a Code Integrity verification. This means that kernel memory pages can never be Writable and Executable (W+X) and executable code cannot be directly modified.
-
**Note**
Device Guard devices that run Kernel Mode Code Integrity with virtualization-based security must have compatible drivers. For additional information, please read the [Driver compatibility with Device Guard in Windows 10](http://go.microsoft.com/fwlink/p/?LinkId=691612) blog post.
-
-
The Device Guard Code Integrity feature lets organizations control what code is trusted to run into the Windows kernel and what applications are approved to run in user mode. It’s configurable by using a policy.
-
Device Guard Code Integrity policy is a binary file that Microsoft recommends you sign. The signing of the Code Integrity policy aids in the protection against a malicious user with Administrator privileges trying to modify or remove the current Code Integrity policy.
-
- **Credential Guard.** Credential Guard protects corporate credentials with hardware-based credential isolation.
-
In Windows 10, Credential Guard aims to protect domain corporate credentials from theft and reuse by malware. With Credential Guard, Windows 10 implemented an architectural change that fundamentally prevents the current forms of the pass-the-hash (PtH) attack.
-
This is accomplished by leveraging Hyper-V and the new virtualization-based security feature to create a protected container where trusted code and secrets are isolated from the Windows kernel. That means that even if the Windows kernel is compromised an attacker has no way to read and extract the data required to initiate a PtH attack. Credential Guard prevents this because the memory where secrets are stored is no longer accessible from the regular OS, even in kernel mode - the hypervisor controls who can access the memory.
-
- **Health attestation.** The device’s firmware logs the boot process, and Windows 10 can send it to a trusted server that can check and assess the device’s health.
-
Windows 10 takes measurements of the UEFI firmware and each of the Windows and antimalware components are made as they load during the boot process. Additionally, they are taken and measured sequentially, not all at once. When these measurements are complete, their values are digitally signed and stored securely in the TPM and cannot be changed unless the system is reset.
-
For more information, see [Secured Boot and Measured Boot: Hardening Early Boot Components Against Malware](http://go.microsoft.com/fwlink/p/?LinkId=733950).
-
During each subsequent boot, the same components are measured, which allows comparison of the measurements against an expected baseline. For additional security, the values measured by the TPM can be signed and transmitted to a remote server, which can then perform the comparison. This process, called *remote device health attestation*, allows the server to verify health status of the Windows device.
-
Health attestation requires the presence of TPM 2.0. On Windows 10, TPM 2.0 also requires UEFI firmware.
-
Although Secure Boot is a proactive form of protection, health attestation is a reactive form of boot protection. Health attestation ships disabled in Windows and is enabled by an antimalware or an MDM vendor. Unlike Secure Boot, health attestation will not stop the boot process and enter remediation when a measurement does not work. But with conditional access control, health attestation will help to prevent access to high-value assets.
-
### Virtualization-based security
-
Virtualization-based security provides a new trust boundary for Windows 10. leverages Hyper-V hypervisor technology to enhance platform security. Virtualization-based security provides a secure execution environment to run specific Windows trusted code (trustlet) and to protect sensitive data.
-
Virtualization-based security helps to protect against a compromised kernel or a malicious user with Administrator privileges. Note that virtualization-based security is not trying to protect against a physical attacker.
-
The following Windows 10 services are protected with virtualization-based security:
-
- **Credential Guard** (LSA Credential Isolation): prevents pass-the-hash attacks and enterprise credential theft that happens by reading and dumping the content of lsass memory
-
- **Device Guard** (Hyper-V Code Integrity): Device Guard uses the new virtualization-based security in Windows 10 to isolate the Code Integrity service from the Windows kernel itself, which lets the service use signatures defined by your enterprise-controlled policy to help determine what is trustworthy. In effect, the Code Integrity service runs alongside the kernel in a Windows hypervisor-protected container.
-
- **Other isolated services**: for example, on Windows Server Technical Preview 2016, there is the vTPM feature that allows you to have encrypted virtual machines (VMs) on servers.
-
**Note**
Virtualization-based security is only available with Windows 10 Enterprise. Virtualization-based security requires devices with UEFI (2.3.1 or higher) with Secure Boot enabled, x64 processor with Virtualization Extensions and SLAT enabled. IOMMU, TPM 2.0. and support for Secure Memory overwritten are optional, but recommended.
-
-
The schema below is a high-level view of Windows 10 with virtualization-based security.
-
-
### Credential Guard
-
In Windows 10, when Credential Guard is enabled, Local Security Authority Subsystem Service (lsass.exe) runs sensitive code in an Isolated user mode to help protect data from malware that may be running in the normal user mode. This helps ensure that protected data is not stolen and reused on remote machines, which mitigates many PtH-style attacks.
-
Credential Guard helps protect credentials by encrypting them with either a per-boot or persistent key:
-
- **The per-boot key** is used for any in-memory credentials that do not require persistence. An example of such a credential would be a ticket-granting ticket (TGT) session key. This key is negotiated with a Key Distribution Center (KDC) every time authentication occurs and is protected with a per-boot key.
-
- **The persistent key**, or some derivative, is used to help protect items that are stored and reloaded after a reboot. Such protection is intended for long-term storage, and must be protected with a consistent key.
-
Credential Guard is activated by a registry key and then enabled by using an UEFI variable. This is done to protect against remote modifications of the configuration. The use of a UEFI variable implies that physical access is required to change the configuration. When lsass.exe detects that credential isolation is enabled, it then spawns LsaIso.exe as an isolated process, which ensures that it runs within isolated user mode. The startup of LsaIso.exe is performed before initialization of a security support provider, which ensures that the secure mode support routines are ready before any authentication begins.
-
### Device Guard
-
Device Guard is a new feature of Windows 10 Enterprise that allows organizations to lock down a device to help protect it from running untrusted software. In this configuration, the only applications allowed to run are those that are trusted by the organization.
-
The trust decision to execute code is performed by using Hyper-V Code Integrity, which runs in virtualization-based security, a Hyper-V protected container that runs alongside regular Windows.
-
Hyper-V Code Integrity is a feature that validates the integrity of a driver or system file each time it is loaded into memory. Code integrity detects whether an unsigned driver or system file is being loaded into the kernel, or whether a system file has been modified by malicious software that is being run by a user account with Administrator privileges. On x64-based versions of Windows 10 kernel-mode drivers must be digitally signed.
-
**Note**
Independently of activation of Device Guard Policy, [Windows 10 by default raises the bar for what runs in the kernel](http://go.microsoft.com/fwlink/p/?LinkId=691613). Windows 10 drivers must be signed by Microsoft, and more specifically, by the WHQL (Windows Hardware Quality Labs) portal. Additionally, starting in October 2015, the WHQL portal will only accept driver submissions, including both kernel and user mode driver submissions, that have a valid Extended Validation (“EV”) Code Signing Certificate.
-
-
With Device Guard in Windows 10, organizations are now able to define their own Code Integrity policy for use on x64 systems running Windows 10 Enterprise. Organizations have the ability to configure the policy that determines what is trusted to run. These include drivers and system files, as well as traditional desktop applications and scripts. The system is then locked down to only run applications that the organization trusts.
-
Device Guard is a built-in feature of Windows 10 Enterprise that prevents the execution of unwanted code and applications. Device Guard can be configured using two rule actions - allow and deny:
-
- **Allow** limits execution of applications to an allowed list of code or trusted publisher and blocks everything else.
-
- **Deny** completes the allow trusted publisher approach by blocking the execution of a specific application.
-
At the time of this writing, and according to Microsoft’s latest research, more than 90 percent of malware is unsigned completely. So implementing a basic Device Guard policy can simply and effectively help block the vast majority of malware. In fact, Device Guard has the potential to go further, and can also help block signed malware.
-
Device Guard needs to be planned and configured to be truly effective. It is not just a protection that is enabled or disabled. Device Guard is a combination of hardware security features and software security features that, when configured together, can lock down a computer to help ensure the most secure and resistant system possible.
-
There are three different parts that make up the Device Guard solution in Windows 10:
-
- The first part is a base **set of hardware security features** introduced with the previous version of Windows. TPM for hardware cryptographic operations and UEFI with modern firmware, along with Secure Boot, allows you to control what the device is running when the systems start.
-
- After the hardware security feature, there is the code integrity engine. In Windows 10, **Code Integrity is now fully configurable** and now resides in Isolated user mode, a part of the memory that is protected by virtualization-based security.
-
- The last part of Device Guard is **manageability**. Code Integrity configuration is exposed through specific Group Policy Objects, PowerShell cmdlets, and MDM configuration service providers (CSPs).
-
For more information on how to deploy Device Guard in an enterprise, see the [Device Guard deployment guide](device-guard-deployment-guide.md).
-
### Device Guard scenarios
-
As previously described, Device Guard is a powerful way to lock down systems. Device Guard is not intended to be used broadly and it may not always be applicable, but there are some high-interest scenarios.
-
Device Guard is useful and applicable on fixed workloads systems like cash registers, kiosk machines, Secure Admin Workstations (SAWs), or well managed desktops. Device Guard is highly relevant on systems that have very well-defined software that are expected to run and don’t change too frequently. It could also help protect Information Workers (IWs) beyond just SAWs, as long as what they need to run is known and the set of applications is not going to change on a daily basis.
-
SAWs are computers that are built to help significantly reduce the risk of compromise from malware, phishing attacks, bogus websites, and PtH attacks, among other security risks. Although SAWs can’t be considered a “silver bullet” security solution to these attacks, these types of clients are helpful as part of a layered, defense-in-depth approach to security.
-
To protect high-value assets, SAWs are used to make secure connections to those assets.
-
Similarly, on corporate fully-managed workstations, where applications are installed by using a distribution tool like System Center Configuration Manager, Intune, or any third-party device management, then Device Guard is very applicable. In that type of scenario, the organization has a good idea of the software that an average user is running.
-
It could be challenging to use Device Guard on corporate, lightly-managed workstations where the user is typically allowed to install software on their own. When an organization offers great flexibility, it’s quite difficult to run Device Guard in enforcement mode. Nevertheless, Device Guard can be run in Audit mode, and in that case, the event log will contain a record of any binaries that violated the Device Guard policy. When Device Guard is used in Audit mode, organizations can get rich data about drivers and applications that users install and run.
-
Before you can benefit from the protection included in Device Guard, Code Integrity policy must be created by using tools provided by Microsoft, but the policy can be deployed with common management tools, like Group Policy. The Code Integrity policy is a binary-encoded XML document that includes configuration settings for both the User and Kernel-modes of Windows 10, along with restrictions on Windows 10 script hosts. Device Guard Code Integrity policy restricts what code can run on a device.
-
**Note**
Device Guard policy can be signed in Windows 10, which adds additional protection against administrative users changing or removing this policy.
-
-
Signed Device Guard policy offers stronger protection against a malicious local administrator trying to defeat Device Guard.
-
When the policy is signed, the GUID of the policy is stored in a UEFI pre-OS secure variable which offers tampering protection. The only way to update the Device Guard policy subsequently is to provide a new version of the policy signed by the same signer or from a signer specified as part of the Device Guard policy into the UpdateSigner section.
-
### The importance of signing applications
-
On computers with Device Guard, Microsoft proposes to move from a world where unsigned apps can be run without restriction to a world where only signed and trusted code is allowed to run on Windows 10.
-
With Windows 10, organizations will make line-of-business (LOB) apps available to members of the organization through the Windows Store infrastructure. More specifically, LOB apps will be available in a private store within the public Windows Store. Windows Store signs and distributes Universal Windows apps and Classic Windows apps. All apps downloaded from the Windows Store are signed.
-
In organizations today, the vast majority of LOB applications are unsigned. Code signing is frequently viewed as a tough problem to solve for a variety of reasons, like the lack of code signing expertise. Even if code signing is a best practice, a lot of internal applications are not signed.
-
Windows 10 includes tools that allow IT pros to take applications that have been already packaged and run them through a process to create additional signatures that can be distributed along with existing applications.
-
### Why are antimalware and device management solutions still necessary?
-
Although allow-list mechanisms are extremely efficient at ensuring that only trusted applications can be run, they cannot prevent the compromise of a trusted (but vulnerable) application by malicious content designed to exploit a known vulnerability. Device Guard doesn’t protect against user mode malicious code run by exploiting vulnerabilities.
-
Vulnerabilities are weaknesses in software that could allow an attacker to compromise the integrity, availability, or confidentiality of the device. Some of the worst vulnerabilities allow attackers to exploit the compromised device by causing it to run malicious code without the user’s knowledge.
-
It’s common to see attackers distributing specially crafted content in an attempt to exploit known vulnerabilities in user mode software like web browsers (and their plug-ins), Java virtual machines, PDF readers, or document editors. As of today, 90 percent of discovered vulnerabilities affect user mode applications compared to the operating system and kernel mode drivers that host them.
-
To combat these threats, patching is the single most effective control, with antimalware software forming complementary layers of defense.
-
Most application software has no facility for updating itself, so even if the software vendor publishes an update that fixes the vulnerability, the user may not know that the update is available or how to obtain it, and therefore remains vulnerable to attack. Organizations still need to manage devices and to patch vulnerabilities.
-
MDM solutions are becoming prevalent as a light-weight device management technology. Windows 10 extends the management capabilities that have become available for MDMs. One key feature Microsoft has added to Windows 10 is the ability for MDMs to acquire a strong statement of device health from managed and registered devices.
-
### Device health attestation
-
Device health attestation leverages the TPM 2.0 to provide cryptographically strong and verifiable measurements of the chain of software used to boot the device.
-
For Windows 10-based devices, Microsoft introduces a new public API that will allow MDM software to access a remote attestation service called Windows Health Attestation Service. A health attestation result, in addition with other elements, can be used to allow or deny access to networks, apps, or services, based on whether devices prove to be healthy.
-
For more information on device health attestation, see the [Detect an unhealthy Windows 10-based device](#detect-unhealthy) section.
-
### Hardware requirements
-
The following table details the hardware requirements for both virtualization-based security services and the health attestation feature. For more information, see [Minimum hardware requirements](http://go.microsoft.com/fwlink/p/?LinkId=733951).
-
@@ -444,264 +272,137 @@ The following table details the hardware requirements for both virtualization-ba
-
-
This section presented information about several closely related controls in Windows 10. The multi-layer defenses and in-depth approach helps to eradicate low-level malware during boot sequence. Virtualization-based security is a fundamental operating system architecture change that adds a new security boundary. Device Guard and Credential Guard respectively help to block untrusted code and protect corporate domain credentials from theft and reuse. This section also briefly discussed the importance of managing devices and patching vulnerabilities. All these technologies can be used to harden and lock down devices while limiting the risk of attackers compromising them.
-
## Detect an unhealthy Windows 10-based device
-
-
As of today, many organizations only consider devices to be compliant with company policy after they’ve passed a variety of checks that show, for example, that the operating system is in the correct state, properly configured, and has security protection enabled. Unfortunately, with today’s systems, this form of reporting is not entirely reliable because malware can spoof a software statement about system health. A rootkit, or a similar low-level exploit, can report a false healthy state to traditional compliance tools.
-
The biggest challenge with rootkits is that they can be undetectable to the client. Because they start before antimalware, and they have system-level privileges, they can completely disguise themselves while continuing to access system resources. As a result, traditional computers infected with rootkits appear to be healthy, even with antimalware running.
-
As previously discussed, the health attestation feature of Windows 10 uses the TPM 2.0 hardware component to securely record a measurement of every boot-related component, including firmware, Windows 10 kernel, and even early boot drivers. Because, health attestation leverages the hardware-based security capabilities of TPM, the log of all boot measured components remains out of the reach of any malware.
-
By attesting a trusted boot state, devices can prove that they are not running low-level malware that could spoof later compliance checks. TPM-based health attestation provides a reliable anchor of trust for assets that contain high-value data.
-
### What is the concept of device health?
-
To understand the concept of device health, it’s important to know traditional measures that IT pros have taken to prevent the breach of malware. Malware control technologies are highly focused on the prevention of installation and distribution.
-
However, the use of traditional malware prevention technologies like antimalware or patching solutions brings a new set of issues for IT pros: the ability to monitor and control the compliance of devices accessing organization’s resources.
-
The definition of device compliance will vary based on an organization’s installed antimalware, device configuration settings, patch management baseline, and other security requirements. But health of the device is part of the overall device compliance policy.
-
The health of the device is not binary and depends on the organization’s security implementation. The Health Attestation Service provides information back to the MDM on which security features are enabled during the boot of the device by leveraging trustworthy hardware TPM.
-
But health attestation only provides information, which is why an MDM solution is needed to take and enforce a decision.
-
### Remote device health attestation
-
In Windows 10, health attestation refers to a feature where Measured Boot data generated during the boot process is sent to a remote device health attestation service operated by Microsoft.
-
This is the most secure approach available for Windows 10-based devices to detect when security defenses are down. During the boot process, the TCG log and PCRs values are sent to a remote Microsoft cloud service. Logs are then checked by the Health Attestation Service to determine what changes have occurred on the device.
-
A relying party like an MDM can inspect the report generated by the remote health attestation service.
-
**Note**
To use the health attestation feature of Windows 10, the device must be equipped with a discrete or firmware TPM 2.0. There is no restriction on any particular edition of Windows 10.
-
-
Windows 10 supports health attestation scenarios by allowing applications access to the underlying health attestation configuration service provider (CSP) so that applications can request a health attestation token. The measurement of the boot sequence can be checked at any time locally by an antimalware or an MDM agent.
-
Remote device health attestation combined with an MDM provides a hardware-rooted method for reporting the current security status and detecting any changes, without having to trust the software running on the system.
-
In the case where malicious code is running on the device, the use of a remote server is required. If a rootkit is present on the device, the antimalware is no longer reliable, and its behavior can be hijacked by a malicious code running early in the startup sequence. That's why it's important to use Secure Boot and Device Guard, to control which code is loaded during the boot sequence.
-
The antimalware software can search to determine whether the boot sequence contains any signs of malware, such as a rootkit. It can also send the TCG log and the PCRs to a remote health attestation server to provide a separation between the measurement component and the verification component.
-
Health attestation logs the measurements in various TPM Platform Configuration Registers (PCRs) and TCG logs during the boot process.
-
-
When starting a device equipped with a TPM, a measurement of different components is performed. This includes firmware, UEFI drivers, CPU microcode, and also all the Windows 10 drivers whose type is Boot Start. The raw measurements are stored in the TPM PCR registers while the details of all events (executable path, authority certification, and so on) are available in the TCG log.
-
-
The health attestation process works as follows:
-
1. Hardware boot components are measured.
-
2. Operating system boot components are measured.
-
3. If Device Guard is enabled, current Device Guard policy is measured.
-
4. Windows kernel is measured.
-
5. Antivirus software is started as the first kernel mode driver.
-
6. Boot start drivers are measured.
-
7. MDM server through the MDM agent issues a health check command by leveraging the Health Attestation CSP.
-
8. Boot measurements are validated by the Health Attestation Service
-
**Note**
By default, the last 100 system boot logs and all associated resume logs are archived in the %SystemRoot%\\logs\\measuredboot folder.
-
The number of retained logs may be set with the registry **REG\_DWORD** value **PlatformLogRetention** under the **HKLM\\SYSTEM\\CurrentControlSet\\Services\\TPM** key. A value of **0** will turn off log archival and a value of **0xffffffff** will keep all logs.
-
-
The following process describes how health boot measurements are sent to the health attestation service:
-
1. The client (a Windows 10-based device with a TPM 2.0) initiates the request with the remote device health attestation service. Because the health attestation server is expected to be a Microsoft cloud service, the URI is already pre-provisioned in the client.
-
2. The client then sends the TCG log, the AIK signed data (PCR values, boot counter) and the AIK certificate information.
-
3. The remote device heath attestation service then:
-
1. Verifies that the AIK certificate is issued by a known and trusted CA and the certificate is valid and not revoked.
-
2. Verifies that the signature on the PCR quotes is correct and consistent with the TCG log value.
-
3. Parses the properties in the TCG log.
-
4. Issues the device health token that contains the health information, the AIK information, and the boot counter information. The health token also contains valid issuance time. The device health token is encrypted and signed, that means that the information is protected and only accessible to issuing health attestation service.
-
4. The client stores the health encrypted blob in its local store. The device health token contains device health status, a device ID (the Windows AIK), and the boot counter.
-
-
### Device health attestation components
-
The device health attestation solution involves different components that are TPM, Health Attestation CSP, and the Windows Health Attestation Service. Those components are described in this section.
-
### Trusted Platform Module
-
*It’s all about TPM 2.0 and endorsement certificates.* This section describes how PCRs (that contain system configuration data), endorsement key (EK) (that act as an identity card for TPM), SRK (that protect keys) and AIKs (that can report platform state) are used for health attestation reporting.
-
In a simplified manner, the TPM is a passive component with limited resources. It can calculate random numbers, RSA keys, decrypt short data, store hashes taken when booting the device.
-
A TPM incorporates in a single component:
-
- A RSA 2048-bit key generator
-
- A random number generator
-
- Nonvolatile memory for storing EK, SRK, and AIK keys
-
- A cryptographic engine to encrypt, decrypt, and sign
-
- Volatile memory for storing the PCRs and RSA keys
-
### Endorsement key
-
The TPM has an embedded unique cryptographic key called the endorsement key. The TPM endorsement key is a pair of asymmetric keys (RSA size 2048 bits).
-
The endorsement key public key is generally used for sending securely sensitive parameters, such as when taking possession of the TPM that contains the defining hash of the owner password. The EK private key is used when creating secondary keys like AIKs.
-
The endorsement key acts as an identity card for the TPM. For more information, see [Understand the TPM endorsement key](http://go.microsoft.com/fwlink/p/?LinkId=733952).
-
The endorsement key is often accompanied by one or two digital certificates:
-
- One certificate is produced by the TPM manufacturer and is called the **endorsement certificate**. The endorsement certificate is used to prove the authenticity of the TPM (for example, that it’s a real TPM manufactured by a specific chip maker) to local processes, applications, or cloud services. The endorsement certificate is created during manufacturing or the first time the TPM is initialized by communicating with an online service.
-
- The other certificate is produced by the platform builder and is called the **platform certificate** to indicate that a specific TPM is integrated with a certain device.
-
For certain devices that use firmware-based TPM produced by Intel or Qualcomm, the endorsement certificate is created when the TPM is initialized during the OOBE of Windows 10.
-
**Note**
Secure Boot protects the platform until the Windows kernel is loaded. Then protections like Trusted Boot, Hyper-V Code Integrity and ELAM take over. A device that uses Intel TPM or Qualcomm TPM gets a signed certificate online from the manufacturer that has created the chip and then stores the signed certificate in TPM storage. For the operation to succeed, if you are filtering Internet access from your client devices, you must authorize the following URLs:
-
- For Intel firmware TPM: **https://ekop.intel.com/ekcertservice**
-
- For Qualcomm firmware TPM: **https://ekcert.spserv.microsoft.com/**
-
-
### Attestation Identity Keys
-
Because the endorsement certificate is unique for each device and does not change, the usage of it may present privacy concerns because it's theoretically possible to track a specific device. To avoid this privacy problem, Windows 10 issues a derived attestation anchor based on the endorsement certificate. This intermediate key, which can be attested to an endorsement key, is the Attestation Identity Key (AIK) and the corresponding certificate is called the AIK certificate. This AIK certificate is issued by a Microsoft cloud service.
-
**Note**
Before the device can report its health using the TPM 2.0 attestation functions, an AIK certificate must be provisioned in conjunction with a third-party service like the Microsoft Cloud CA service. After it is provisioned, the AIK private key can be used to report platform configuration. Windows 10 creates a signature over the platform log state (and a monotonic counter value) at each boot by using the AIK.
-
-
The AIK is an asymmetric (public/private) key pair that is used as a substitute for the EK as an identity for the TPM for privacy purposes. The private portion of an AIK is never revealed or used outside the TPM and can only be used inside the TPM for a limited set of operations. Furthermore, it can only be used for signing, and only for limited, TPM-defined operations.
-
Windows 10 creates AIKs protected by the TPM, if available, that are 2048-bit RSA signing keys. Microsoft is hosting a cloud service called Microsoft Cloud CA to establish cryptographically that it is communicating with a real TPM and that the TPM possesses the presented AIK. After the Microsoft Cloud CA service has established these facts, it will issue an AIK certificate to the Windows 10-based device.
-
Many existing devices that will upgrade to Windows 10 will not have a TPM, or the TPM will not contain an endorsement certificate. **To accommodate those devices, Windows 10 allows the issuance of AIK certificates without the presence of an endorsement certificate.** Such AIK certificates are not issued by Microsoft Cloud CA. Note that this is not as trustworthy as an endorsement certificate that is burned into the device during manufacturing, but it will provide compatibility for advanced scenarios like Microsoft Passport without TPM.
-
In the issued AIK certificate, a special OID is added to attest that endorsement certificate was used during the attestation process. This information can be leveraged by a relying party to decide whether to reject devices that are attested using AIK certificates without an endorsement certificate or accept them. Another scenario can be to not allow access to high-value assets from devices that are attested by an AIK certificate that is not backed by an endorsement certificate.
-
### Storage root key
-
The storage root key (SRK) is also an asymmetric key pair (RSA with a minimum of 2048 bits length). The SRK has a major role and is used to protect TPM keys, so that these keys cannot be used without the TPM. The SRK key is created when the ownership of the TPM is taken.
-
### Platform Configuration Registers
-
The TPM contains a set of registers that are designed to provide a cryptographic representation of the software and state of the system that booted. These registers are called Platform Configuration Registers (PCRs).
-
The measurement of the boot sequence is based on the PCR and TCG log. To establish a static root of trust, when the device is starting, the device must be able to measure the firmware code before execution. In this case, the Core Root of Trust for Measurement (CRTM) is executed from the boot, calculates the hash of the firmware, then stores it by expanding the register PCR\[0\] and transfers execution to the firmware.
-
PCRs are set to zero when the platform is booted, and it is the job of the firmware that boots the platform to measure components in the boot chain and to record the measurements in the PCRs. Typically, boot components take the hash of the next component that is to be run and record the measurements in the PCRs. The initial component that starts the measurement chain is implicitly trusted. This is the CRTM. Platform manufacturers are required to have a secure update process for the CRTM or not permit updates to it. The PCRs record a cumulative hash of the components that have been measured.
-
The value of a PCR on its own is hard to interpret (it is just a hash value), but platforms typically keep a log with details of what has been measured, and the PCRs merely ensure that the log has not been tampered with. The logs are referred as a TCG log. Each time a register PCR is extended, an entry is added to the TCG log. Thus, throughout the boot process, a trace of the executable code and configuration data is created in the TCG log.
-
### TPM provisioning
-
For the TPM of a Windows 10-based device to be usable, it must first be provisioned. The process of provisioning differs somewhat based on TPM versions, but, when successful, it results in the TPM being usable and the owner authorization data (ownerAuth) for the TPM being stored locally on the registry.
-
When the TPM is provisioned, Windows 10 will first attempt to determine the EK and locally stored **ownerAuth** values by looking in the registry at the following location: **HKLM\\SYSTEM\\CurrentControlSet\\Services\\TPM\\WMI\\Endorsement**
-
During the provisioning process, the device may need to be restarted.
-
Note that the **Get-TpmEndorsementKeyInfo PowerShell** cmdlet can be used with administrative privilege to get information about the endorsement key and certificates of the TPM.
-
If the TPM ownership is not known but the EK exists, the client library will provision the TPM and will store the resulting **ownerAuth** value into the registry if the policy allows it will store the SRK public portion at the following location: **HKLM\\SYSTEM\\CurrentControlSet\\Services\\TPM\\WMI\\Admin\\SRKPub**
-
As part of the provisioning process, Windows 10 will create an AIK with the TPM. When this operation is performed, the resulting AIK public portion is stored in the registry at the following location: **HKLM\\SYSTEM\\CurrentControlSet\\Services\\TPM\\WMI\\WindowsAIKPub**
-
**Note**
For provisioning AIK certificates and filtering Internet access, you must authorize the following wildcard URL: **https://\*.microsoftaik.azure.net**
-
-
### Windows 10 Health Attestation CSP
-
Windows 10 contains a configuration service provider (CSP) specialized for interacting with the health attestation feature. A CSP is a component that plugs into the Windows MDM client and provides a published protocol for how MDM servers can configure settings and manage Windows-based devices. The management protocol is represented as a tree structure that can be specified as URIs with functions to perform on the URIs such as “get”, “set”, “delete”, and so on.
-
The following is a list of functions performed by the Windows 10 Health Attestation CSP:
-
- Collects data that is used to verify a device’s health status
-
- Forwards the data to the Health Attestation Service
-
- Provisions the Health Attestation Certificate that it receives from the Health Attestation Service
-
- Upon request, forwards the Health Attestation Certificate (received from the Health Attestation Service) and related runtime information to the MDM server for verification
-
During a health attestation session, the Health Attestation CSP forwards the TCG logs and PCRs values that are measured during the boot, by using a secure communication channel to the Health Attestation Service.
-
When an MDM server validates that a device has attested to the Health Attestation Service, it will be given a set of statements and claims about how that device booted, with the assurance that the device did not reboot between the time that it attested its health and the time that the MDM server validated it.
-
### Windows Health Attestation Service
-
The role of Windows Health Attestation Service is essentially to evaluate a set of health data (TCG log and PCR values), make a series of detections (based on available health data) and generate encrypted health blob or produce report to MDM servers.
-
**Note**
Both device and MDM servers must have access to **has.spserv.microsoft.com** using the TCP protocol on port 443 (HTTPS).
-
-
Checking that a TPM attestation and the associated log are valid takes several steps:
-
1. First, the server must check that the reports are signed by **trustworthy AIKs**. This might be done by checking that the public part of the AIK is listed in a database of assets, or perhaps that a certificate has been checked.
-
2. After the key has been checked, the signed attestation (a quote structure) should be checked to see whether it is a **valid signature over PCR values**.
-
3. Next the logs should be checked to ensure that they match the PCR values reported.
-
4. Finally, the logs themselves should be examined by an MDM solution to see whether they represent **known or valid security configurations**. For example, a simple check might be to see whether the measured early OS components are known to be good, that the ELAM driver is as expected, and that the ELAM driver policy file is up to date. If all of these checks succeed, an attestation statement can be issued that later can be used to determine whether or not the client should be granted access to a resource.
-
The Health Attestation Service provides the following information to an MDM solution about the health of the device:
-
- Secure Boot enablement
-
- Boot and kernel debug enablement
-
- BitLocker enablement
-
- VSM enabled
-
- Signed or unsigned Device Guard Code Integrity policy measurement
-
- ELAM loaded
-
- Safe Mode boot, DEP enablement, test signing enablement
-
- Device TPM has been provisioned with a trusted endorsement certificate
-
For completeness of the measurements, see [Health Attestation CSP](http://go.microsoft.com/fwlink/p/?LinkId=733949).
-
The following table presents some key items that can be reported back to MDM depending on the type of Windows 10-based device.
-
@@ -743,267 +444,134 @@ The following table presents some key items that can be reported back to MDM dep
-
-
### Leverage MDM and the Health Attestation Service
-
To make device health relevant, the MDM solution evaluates the device health report and is configured to the organization’s device health requirements.
-
A solution that leverages MDM and the Health Attestation Service consists of three main parts:
-
1. A device with health attestation enabled. This will usually be done as a part of enrollment with an MDM provider (health attestation will be disabled by default).
-
2. After this is enabled, and every boot thereafter, the device will send health measurements to the Health Attestation Service hosted by Microsoft, and it will receive a health attestation blob in return.
-
3. At any point after this, an MDM server can request the health attestation blob from the device and ask Health Attestation Service to decrypt the content and validate that it’s been attested.
-
-
Interaction between a Windows 10-based device, the Health Attestation Service, and MDM can be performed as follows:
-
1. The client initiates a session with the MDM server. The URI for the MDM server would be part of the client app that initiates the request. The MDM server at this time could request the health attestation data by using the appropriate CSP URI.
-
2. The MDM server specifies a nonce along with the request.
-
3. The client then sends the AIK quoted nonce + the boot counter and the health blob information. This health blob is encrypted with a Health Attestation Service public key that only the Health Attestation Service can decrypt.
-
4. The MDM server:
-
1. Verifies that the nonce is as expected.
-
2. Passes the quoted data, the nonce and the encrypted health blob to the Health Attestation Service server.
-
5. The Health Attestation Service:
-
1. Decrypts the health blob.
-
2. Verifies that the boot counter in the quote is correct using the AIK in the health blob and matches the value in the health blob.
-
3. Verifies that the nonce matches in the quote and the one that is passed from MDM.
-
4. Because the boot counter and the nonce are quoted with the AIK from the health blob, it also proves that the device is the same one as the one for which the health blob has been generated.
-
5. Sends data back to the MDM server including health parameters, freshness, and so on.
-
**Note**
The MDM server (relying party) never performs the quote or boot counter validation itself. It gets the quoted data and the health blob (which is encrypted) and sends the data to the Health Attestation Service for validation. This way, the AIK is never visible to the MDM, which thereby addresses privacy concerns.
-
-
Setting the requirements for device compliance is the first step to ensure that registered devices that do not meet health and compliance requirements are detected, tracked, and have actions enforced by the MDM solution.
-
Devices that attempt to connect to resources must have their health evaluated so that unhealthy and noncompliant devices can be detected and reported. To be fully efficient, an end-to-end security solution must impose a consequence for unhealthy devices like refusing access to high-value assets. That is the purpose of conditional access control, which is detailed in the next section.
-
## Control the security of a Windows 10-based device before access is granted
-
-
Today’s access control technology, in most cases, focuses on ensuring that the right people get access to the right resources. If users can authenticate, they get access to resources using a device that the organization’s IT staff and systems know very little about. Perhaps there is some check such as ensuring that a device is encrypted before giving access to email, but what if the device is infected with malware?
-
The remote device health attestation process uses measured boot data to verify the health status of the device. The health of the device is then available for an MDM solution like Intune.
-
**Note**
For the latest information on Intune and Windows 10 features support, see the [Microsoft Intune blog](http://go.microsoft.com/fwlink/p/?LinkId=691614) and [What's new in Microsoft Intune](http://go.microsoft.com/fwlink/p/?LinkId=733956).
-
-
The figure below shows how the Health Attestation Service is expected to work with Microsoft’s cloud-based Intune MDM service.
-
-
An MDM solution can then leverage health state statements and take them to the next level by coupling with client policies that will enable conditional access to be granted based on the device’s ability to prove that it’s malware free, its antimalware system is functional and up to date, the firewall is running, and the devices patch state is compliant.
-
Finally, resources can be protected by denying access to endpoints that are unable to prove they’re healthy. This feature is much needed for BYOD devices that need to access organizational resources.
-
### Built-in support of MDM in Windows 10
-
Windows 10 has an MDM client that ships as part of the operating system. This enables MDM servers to manage Windows 10-based devices without requiring a separate agent.
-
### Third-party MDM server support
-
Third-party MDM servers can manage Windows 10 by using the MDM protocol. The built-in management client is able to communicate with a compatible server that supports the OMA-DM protocol to perform enterprise management tasks. For additional information, see [Azure Active Directory integration with MDM](http://go.microsoft.com/fwlink/p/?LinkId=733954).
-
**Note**
MDM servers do not need to create or download a client to manage Windows 10. For more information, see [Mobile device management](http://go.microsoft.com/fwlink/p/?LinkId=733955).
-
-
The third-party MDM server will have the same consistent first-party user experience for enrollment, which also provides simplicity for Windows 10 users.
-
### Management of Windows Defender by third-party MDM
-
This management infrastructure makes it possible for IT pros to use MDM-capable products like Intune, to manage health attestation, Device Guard, or Windows Defender on Windows 10-based devices, including BYODs that aren’t domain joined. IT pros will be able to manage and configure all of the actions and settings they are familiar with customizing by using Intune with Intune Endpoint Protection on down-level operating systems. Admins that currently only manage domain joined devices through Group Policy will find it easy to transition to managing Windows 10-based devices by using MDM because many of the settings and actions are shared across both mechanisms.
-
For more information on how to manage Windows 10 security and system settings with an MDM solution, see [Custom URI settings for Windows 10 devices](http://go.microsoft.com/fwlink/p/?LinkId=733953).
-
### Conditional access control
-
On most platforms, the Azure Active Directory (Azure AD) device registration happens automatically during enrollment. The device states are written by the MDM solution into Azure AD, and then read by Office 365 (or by any authorized Windows app that interacts with Azure AD) the next time the client tries to access an Office 365 compatible workload.
-
If the device is not registered, the user will get a message with instructions on how to register (also known as enrolling). If the device is not compliant, the user will get a different message that redirects them to the MDM web portal where they can get more information on the compliance problem and how to resolve it.
-
**Azure AD** authenticates the user and the device, **MDM** manages the compliance and conditional access policies, and the **Health Attestation Service** reports about the health of the device in an attested way.
-
-
### Office 365 conditional access control
-
Azure AD enforces conditional access policies to secure access to Office 365 services. A tenant admin can create a conditional access policy that blocks a user on a non-compliant device from accessing an Office 365 service. The user must conform to the company’s device policies before access can be granted to the service. Alternately, the admin can also create a policy that requires users to just enroll their devices to gain access to an Office 365 service. Policies may be applied to all users of an organization, or limited to a few target groups and enhanced over time to include additional target groups.
-
When a user requests access to an Office 365 service from a supported device platform, Azure AD authenticates the user and device from which the user launches the request; and grants access to the service only when the user conforms to the policy set for the service. Users that do not have their device enrolled are given remediation instructions on how to enroll and become compliant to access corporate Office 365 services.
-
When a user enrolls, the device is registered with Azure AD, and enrolled with a compatible MDM solution like Intune.
-
**Note**
Microsoft is working with third-party MDM ISVs to support automated MDM enrollment and policy based access checks. Steps to turn on auto-MDM enrollment with Azure AD and Intune are explained in the [Windows 10, Azure AD And Microsoft Intune: Automatic MDM Enrollment Powered By The Cloud!](http://go.microsoft.com/fwlink/p/?LinkId=691615) blog post.
-
-
When a user enrolls a device successfully, the device becomes trusted. Azure AD provides single-sign-on to access company applications and enforces conditional access policy to grant access to a service not only the first time the user requests access, but every time the user requests to renew access.
-
The user will be denied access to services when sign-in credentials are changed, a device is lost/stolen, or the compliance policy is not met at the time of request for renewal.
-
Depending on the type of email application that employees use to access Exchange online, the path to establish secured access to email can be slightly different. However, the key components: Azure AD, Office 365/Exchange Online, and Intune, are the same. The IT experience and end-user experience also are similar.
-
-
Clients that attempt to access Office 365 will be evaluated for the following properties:
-
- Is the device managed by an MDM?
-
- Is the device registered with Azure AD?
-
- Is the device compliant?
-
To get to a compliant state, the Windows 10-based device needs to:
-
- Enroll with an MDM solution.
-
- Register with Azure AD.
-
- Be compliant with the device policies set by the MDM solution.
-
**Note**
At the present time, conditional access policies are selectively enforced on users on iOS and Android devices. For more information, see the [Azure AD, Microsoft Intune and Windows 10 – Using the cloud to modernize enterprise mobility!](http://go.microsoft.com/fwlink/p/?LinkId=691616) blog post.
-
-
### Cloud and on-premises apps conditional access control
-
Conditional access control is a powerful policy evaluation engine built into Azure AD. It gives IT pros an easy way to create access rules beyond Office 365 that evaluate the context of a user's logon to make real-time decisions about which applications they should be allowed to access.
-
IT pros can configure conditional access control policies for cloud SaaS applications secured by Azure AD and even on-premises applications. Access rules in Azure AD leverage the conditional access engine to check device health and compliance state reported by a compatible MDM solution like Intune in order to determine whether to allow access.
-
For more information about conditional access, see [Azure Conditional Access Preview for SaaS Apps.](http://go.microsoft.com/fwlink/p/?LinkId=524807)
-
**Note**
Conditional access control is an Azure AD Premium feature that's also available with EMS. If you don't have an Azure AD Premium subscription, you can get a trial from the [Microsoft Azure](http://go.microsoft.com/fwlink/p/?LinkId=691617) site.
-
-
For on-premises applications there are two options to enable conditional access control based on a device's compliance state:
-
- For on-premises applications that are published through the Azure AD Application Proxy, you can configure conditional access control policies as you would for cloud applications. For more details, see the [Azure AD Conditional Access preview updated: Now supports On-Premises and Custom LOB apps](http://go.microsoft.com/fwlink/p/?LinkId=691618) blog post.
-
- Additionally, Azure AD Connect will sync device compliance information from Azure AD to on-premises AD. ADFS on Windows Server Technical Preview 2016 will support conditional access control based on a device's compliance state. IT pros will configure conditional access control policies in ADFS that use the device's compliance state reported by a compatible MDM solution to secure on-premises applications.
-
-
The following process describes how Azure AD conditional access works:
-
1. User has already enrolled with MDM through Workplace Access/Azure AD join which registers device with Azure AD.
-
2. When the device boots or resumes from hibernate, a task “Tpm-HASCertRetr” is triggered to request in background a health attestation blob. Device sends TPM boot measurements to the Health Attestation Service.
-
3. Health Attestation Service validates device state and issues an encrypted blob to the device based on the health state with details on failed checks (if any).
-
4. User logs on and the MDM agent contacts the Intune/MDM server.
-
5. MDM server pushes down new policies if available and queries health blob state and other inventory state.
-
6. Device sends a health attestation blob previously acquired and also the value of the other state inventory requested by the Intune/MDM server.
-
7. Intune/MDM server sends the health attestation blob to Health Attestation Service to be validated.
-
8. Health Attestation Service validates that the device which sent the health attestation blob is healthy, and returns this result to Intune/MDM server.
-
9. Intune/MDM server evaluates compliance based on the compliance and the queried inventory/health attestation state from device.
-
10. Intune/MDM server updates compliance state against device object in Azure AD.
-
11. User opens app, attempts to access a corporate managed asset.
-
12. Access gated by compliance claim in Azure AD.
-
13. If the device is compliant and the user is authorized, an access token is generated.
-
14. User can access the corporate managed asset.
-
For more information about Azure AD join, see the [Azure AD & Windows 10: Better Together for Work or School](http://go.microsoft.com/fwlink/p/?LinkId=691619) white paper.
-
Conditional access control is a topic that many organizations and IT pros may not know as well as they should. The different attributes that describe a user, a device, compliance, and context of access are very powerful when used with a conditional access engine. Conditional access control is an essential step that helps organizations secure their environment.
-
## Takeaways and summary
-
-
The following list contains high-level key take-aways to improve the security posture of any organization. However, the few take-aways presented in this section should not be interpreted as an exhaustive list of security best practices.
-
- **Understand that no solution is 100 percent secure**
-
If determined adversaries with malicious intent gain physical access to the device, they could eventually break through its security layers and control it.
-
- **Use health attestation with an MDM solution**
-
Devices that attempt to connect to high-value assets must have their health evaluated so that unhealthy and noncompliant devices can be detected, reported, and eventually blocked.
-
- **Use Credential Guard**
-
Credential Guard is a feature that greatly helps protect corporate domain credentials from pass-the-hash attacks.
-
- **Use Device Guard**
-
Device Guard is a real advance in security and an effective way to help protect against malware. The new Device Guard feature in Windows 10 blocks untrusted apps (apps not authorized by your organization).
-
- **Sign Device Guard policy**
-
Signed Device Guard policy helps protect against a user with administrator privileges trying to defeat the current policy. When a policy is signed, the only way to modify Device Guard subsequently is to provide a new version of the policy signed by the same signer or from a signer specify as part of the Device Guard policy.
-
- **Use virtualization-based security**
-
When you have Kernel Mode Code Integrity protected by virtualization-based security, the code integrity rules are still enforced even if a vulnerability allows unauthorized kernel mode memory access. Keep in mind that Device Guard devices that run Kernel Code Integrity with virtualization-based security must have compatible drivers.
-
- **Start to deploy Device Guard with Audit mode**
-
Deploy Device Guard policy to targeted computers and devices in Audit mode. Monitor the Code Integrity event log that indicates a program or a driver would have been blocked if Device Guard was configured in Enforcement mode. Adjust Device Guard rules until a high level of confidence has been reached. After the testing phase has been completed, Device Guard policy can be switched to Enforcement mode.
-
- **Build an isolated reference machine when deploying Device Guard**
-
Because the corporate network can contain malware, you should start to configure a reference environment that is isolated from your main corporate network. After that, you can create a code integrity policy that includes the trusted applications you want to run on your protected devices.
-
- **Use AppLocker when it makes sense**
-
Although AppLocker is not considered a new Device Guard feature, it complements Device Guard functionality for some scenarios like being able to deny a specific Universal Windows apps for a specific user or a group of users.
-
- **Lock down firmware and configuration**
-
After Windows 10 is installed, lock down firmware boot options access. This prevents a user with physical access from modifying UEFI settings, disabling Secure Boot, or booting other operating systems. Also, in order to protect against an administrator trying to disable Device Guard, add a rule in the current Device Guard policy that will deny and block execution of the **C:\\Windows\\System32\\SecConfig.efi** tool.
-
Health attestation is a key feature of Windows 10 that includes client and cloud components to control access to high-value assets based on a user and their device’s identity and compliance with corporate governance policy. Organizations can choose to detect and report unhealthy devices, or to configure health enforcement rules based on their needs. Health attestation provides an end-to-end security model and integration points, which vendors and software developers can use to build and integrate a customized solution.
-
## Related topics
-
-
[Protect derived domain credentials with Credential Guard](credential-guard.md)
-
[Device Guard deployment guide](device-guard-deployment-guide.md)
-
[Trusted Platform Module technology overview](http://go.microsoft.com/fwlink/p/?LinkId=733957)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/protecting-cluster-shared-volumes-and-storage-area-networks-with-bitlocker.md b/windows/keep-secure/protecting-cluster-shared-volumes-and-storage-area-networks-with-bitlocker.md
index 5ed8ed7a78..a1a5ed3f34 100644
--- a/windows/keep-secure/protecting-cluster-shared-volumes-and-storage-area-networks-with-bitlocker.md
+++ b/windows/keep-secure/protecting-cluster-shared-volumes-and-storage-area-networks-with-bitlocker.md
@@ -2,191 +2,112 @@
title: Protecting cluster shared volumes and storage area networks with BitLocker (Windows 10)
description: This topic for IT pros describes how to protect CSVs and SANs with BitLocker.
ms.assetid: ecd25a10-42c7-4d31-8a7e-ea52c8ebc092
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Protecting cluster shared volumes and storage area networks with BitLocker
-
-
**Applies to**
-
- Windows 10
-
This topic for IT pros describes how to protect CSVs and SANs with BitLocker.
-
BitLocker can protect both physical disk resources and cluster shared volumes version 2.0 (CSV2.0). BitLocker on clustered volumes allows for an additional layer of protection for administrators wishing to protect sensitive, highly available data. By adding additional protectors to the clustered volume, administrators can also add an additional barrier of security to resources within an organization by allowing only certain user accounts access to unlock the BitLocker volume.
-
## Configuring BitLocker on Cluster Shared Volumes
-
-
### Using BitLocker with Clustered Volumes
-
BitLocker on volumes within a cluster are managed based on how the cluster service "views" the volume to be protected. The volume can be a physical disk resource such as a logical unit number (LUN) on a storage area network (SAN) or network attached storage (NAS).
-
**Important**
SANs used with BitLocker must have obtained Windows Hardware Certification. For more info, see [Windows Hardware Lab Kit](https://msdn.microsoft.com/library/windows/hardware/dn930814.aspx).
-
-
Alternatively, the volume can be a cluster-shared volume, a shared namespace, within the cluster. Windows Server 2012 expanded the CSV architecture, now known as CSV2.0, to enable support for BitLocker. When using BitLocker with volumes designated for a cluster, the volume will need to turn on BitLocker before its addition to the storage pool within cluster or put the resource into maintenance mode before BitLocker operations will complete.
-
Windows PowerShell or the manage-bde command line interface is the preferred method to manage BitLocker on CSV2.0 volumes. This is recommended over the BitLocker Control Panel item because CSV2.0 volumes are mount points. Mount points are an NTFS object that is used to provide an entry point to other volumes. Mount points do not require the use of a drive letter. Volumes that lack drive letters do not appear in the BitLocker Control Panel item. Additionally, the new Active Directory-based protector option required for cluster disk resource or CSV2.0 resources is not available in the Control Panel item.
-
**Note**
Mount points can be used to support remote mount points on SMB based network shares. This type of share is not supported for BitLocker encryption.
-
-
For thinly provisioned storage, such as a Dynamic Virtual Hard Disk (VHD), BitLocker runs in Used Disk Space Only encryption mode. You cannot use the **manage-bde –WipeFreeSpace** command to transition the volume to full-volume encryption on these types of volumes. This occurs because Full Encryption requires an end marker for the volume and dynamically expanding VHDs do not have a static end of volume marker.
-
### Active Directory-based protector
-
You can also use an Active Directory Domain Services (AD DS) protector for protecting clustered volumes held within your AD DS infrastructure. The **ADAccountOrGroup** protector is a domain security identifier (SID)-based protector that can be bound to a user account, machine account or group. When an unlock request is made for a protected volume, the BitLocker service interrupts the request and uses the BitLocker protect/unprotect APIs to unlock or deny the request. BitLocker will unlock protected volumes without user intervention by attempting protectors in the following order:
-
1. Clear key
-
2. Driver-based auto-unlock key
-
3. ADAccountOrGroup protector
-
1. Service context protector
-
2. User protector
-
4. Registry-based auto-unlock key
-
**Note**
A Windows Server 2012 or later domain controller is required for this feature to work properly.
-
-
### Turning on BitLocker before adding disks to a cluster using Windows PowerShell
-
BitLocker encryption is available for disks before or after addition to a cluster storage pool. The advantage of encrypting volumes prior to adding them to a cluster is that the disk resource does not require suspending the resource to complete the operation. To turn on BitLocker for a disk before adding it to a cluster, do the following:
-
1. Install the BitLocker Drive Encryption feature if it is not already installed.
-
2. Ensure the disk is formatted NTFS and has a drive letter assigned to it.
-
3. Enable BitLocker on the volume using your choice of protector. A password protector is used in the Windows PowerShell script example below.
-
``` syntax
Enable-BitLocker E: -PasswordProtector -Password $pw
```
-
4. Identify the name of the cluster with Windows PowerShell.
-
``` syntax
Get-Cluster
```
-
5. Add an **ADAccountOrGroup**protector to the volume using the cluster name using a command such as:
-
``` syntax
Add-BitLockerProtector E: -ADAccountOrGroupProtector -ADAccountOrGroup CLUSTER$
```
-
**Warning**
You must add an **ADAccountOrGroup** protector using the cluster CNO for a BitLocker enabled volume to either be shared in a Cluster Shared Volume or to failover properly in a traditional failover cluster.
-
-
6. Repeat steps 1-6 for each disk in the cluster.
-
7. Add the volume(s) to the cluster.
-
### Turning on BitLocker for a clustered disk using Windows PowerShell
-
When the cluster service owns a disk resource already, it needs to be set into maintenance mode before BitLocker can be enabled. Use the following steps for turning BitLocker on for a clustered disk:
-
1. Install the BitLocker Drive Encryption feature if it is not already installed.
-
2. Check the status of the cluster disk using Windows PowerShell.
-
``` syntax
Get-ClusterResource "Cluster Disk 1"
```
-
3. Put the physical disk resource into maintenance mode using Windows PowerShell.
-
``` syntax
Get-ClusterResource "Cluster Disk 1" | Suspend-ClusterResource
```
-
4. Enable BitLocker on the volume using your choice of protector. A password protector is used in the example below.
-
``` syntax
Enable-BitLocker E: -PasswordProtector -Password $pw
```
-
5. Identify the name of the cluster with Windows PowerShell
-
``` syntax
Get-Cluster
```
-
6. Add an **ADAccountOrGroup** protector with the Cluster Name Object (CNO) to the volume using a command such as:
-
``` syntax
Add-BitLockerProtector E: -ADAccountOrGroupProtector -ADAccountOrGroup CLUSTER$
```
-
**Warning**
You must add an **ADAccountOrGroup** protector using the cluster CNO for a BitLocker enabled volume to either be shared in a Cluster Shared Volume or to failover properly in a traditional failover cluster.
-
-
7. Repeat steps 1-6 for each disk in the cluster.
-
8. Add the volume(s) to the cluster
-
### Adding BitLocker encrypted volumes to a cluster using manage-bde
-
You can also use manage-bde to enable BitLocker on clustered volumes. The steps needed to add a physical disk resource or CSV2.0 volume to an existing cluster includes the following:
-
1. Verify the BitLocker Drive Encryption feature is installed on the computer.
-
2. Ensure new storage is formatted as NTFS.
-
3. Encrypt the volume, add a recovery key and add the cluster administrator as a protector key using the manage-bde command line interface (see example):
-
- `Manage-bde -on -used -RP -sid domain\CNO$ -sync`
-
1. BitLocker will check to see if the disk is already part of a cluster. If it is, administrators will encounter a hard block. Otherwise, the encryption will continue.
-
2. Using the -sync parameter is optional. Using it ensures the command waits until the encryption for the volume is completed before releasing the volume for use in the cluster storage pool.
-
4. Open the Failover Cluster Manager snap-in or cluster PowerShell cmdlets to enable the disk to be clustered
-
- Once the disk is clustered it can also be enabled for CSV.
-
5. During the resource online operation, cluster will check to see if the disk is BitLocker encrypted.
-
1. If the volume is not BitLocker enabled, traditional cluster online operations occur.
-
2. If the volume is BitLocker enabled, the following check occurs:
-
- If volume is **locked**, BitLocker will impersonate the CNO and unlock the volume using the CNO protector. If this operation fails an event will be logged that the volume could not be unlocked and the online operation will fail.
-
6. Once the disk is online in the storage pool, it can be added to a CSV by right clicking on the disk resource and choosing "**Add to cluster shared volumes**".
-
CSVs can include both encrypted and unencrypted volumes. To check the status of a particular volume for BitLocker encryption, administrators can utilize the manage-bde -status command with a path to the volume inside the CSV namespace as seen in the example command line below.
-
``` syntax
manage-bde -status "C:\ClusterStorage\volume1"
```
-
### Physical Disk Resources
-
Unlike CSV2.0 volumes, physical disk resources can only be accessed by one cluster node at a time. This means that operations such as encrypting, decrypting, locking or unlocking volumes require context to perform. For example, you cannot unlock or decrypt a physical disk resource if you are not administering the cluster node that owns the disk resource because the disk resource is not available.
-
### Restrictions on BitLocker actions with cluster volumes
-
The following table contains information about both Physical Disk Resources (i.e. traditional failover cluster volumes) and Cluster Shared Volumes (CSV) and the actions that are allowed by BitLocker in each situation.
-
@@ -289,39 +210,19 @@ The following table contains information about both Physical Disk Resources (i.e
-
-
**Note**
Although the manage-bde -pause command is Blocked in clusters, the cluster service will automatically resume a paused encryption or decryption from the MDS node
-
-
In the case where a physical disk resource experiences a failover event during conversion, the new owning node will detect the conversion is not complete and will complete the conversion process.
-
### Other considerations when using BitLocker on CSV2.0
-
Some other considerations to take into account for BitLocker on clustered storage include the following:
-
- BitLocker volumes have to be initialized and beginning encryption before they are available to add to a CSV2.0 volume.
-
- If an administrator needs to decrypt a CSV volume, remove the volume from the cluster or put into disk maintenance mode. You can add the CSV back to the cluster while waiting for decryption to complete.
-
- If an administrator needs to start encrypting a CSV volume, remove the volume from the cluster or put it in maintenance mode.
-
- If conversion is paused with encryption in progress and the CSV volume is offline from the cluster, the cluster thread (health check) will automatically resume conversion when the volume is online to the cluster.
-
- If conversion is paused with encryption in progress and a physical disk resource volume is offline from the cluster, the BitLocker driver will automatically resume conversion when the volume is online to the cluster.
-
- If conversion is paused with encryption in progress, while the CSV volume is in maintenance mode, the cluster thread (health check) will automatically resume conversion when moving the volume back from maintenance.
-
- If conversion is paused with encryption in progress, while the disk resource volume is in maintenance mode, the BitLocker driver will automatically resume conversion when the volume is moved back from maintenance mode.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/recovery-console-allow-automatic-administrative-logon.md b/windows/keep-secure/recovery-console-allow-automatic-administrative-logon.md
index c67329f99a..e1f339479c 100644
--- a/windows/keep-secure/recovery-console-allow-automatic-administrative-logon.md
+++ b/windows/keep-secure/recovery-console-allow-automatic-administrative-logon.md
@@ -2,54 +2,32 @@
title: Recovery console Allow automatic administrative logon (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Recovery console Allow automatic administrative logon security policy setting.
ms.assetid: be2498fc-48f4-43f3-ad09-74664e45e596
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Recovery console: Allow automatic administrative logon
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **Recovery console: Allow automatic administrative logon** security policy setting.
-
## Reference
-
-
This policy setting determines whether the built-in Administrator account password must be provided before access to the device is granted. If you enable this setting, the built-in Administrator account is automatically logged on to the computer at the Recovery Console; no password is required.
-
The Recovery Console can be very useful when troubleshooting and repairing systems that cannot be restarted. However, enabling this policy setting so a user can automatically log on to the console is dangerous. Anyone can walk up to the server, shut it down by disconnecting the power, reboot it, select **Recovery Console** from the **Restart** menu, and then assume full control of the server.
-
### Possible values
-
- Enabled
-
The built-in Administrator account is automatically logged on to the computer at the Recovery Console; no password is required
-
- Disabled
-
Automatic administrative logon is not allowed.
-
- Not defined
-
Automatic administrative logon is not allowed.
-
### Best practices
-
- Set **Recovery Console: Allow automatic administrative logon** to **Disabled**. This requires a user to enter a user name and password to access the Recovery Console account.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -88,53 +66,24 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Group Policy
-
Setting and deploying this policy using Group Policy takes precedence over the setting on the local device
-
### Policy conflicts
-
None.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
The Recovery Console can be very useful when you must troubleshoot and repair device that do not start. However, allowing automatic logon to the Recovery Console can make it possible for someone to assume full control of the server.
-
### Countermeasure
-
Disable the **Recovery console: Allow automatic administrative logon** setting.
-
### Potential impact
-
Users must enter a user name and password to access the Recovery Console.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/recovery-console-allow-floppy-copy-and-access-to-all-drives-and-folders.md b/windows/keep-secure/recovery-console-allow-floppy-copy-and-access-to-all-drives-and-folders.md
index f881d30d6d..113bafb66c 100644
--- a/windows/keep-secure/recovery-console-allow-floppy-copy-and-access-to-all-drives-and-folders.md
+++ b/windows/keep-secure/recovery-console-allow-floppy-copy-and-access-to-all-drives-and-folders.md
@@ -2,56 +2,33 @@
title: Recovery console Allow floppy copy and access to all drives and folders (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Recovery console Allow floppy copy and access to all drives and folders security policy setting.
ms.assetid: a5b4ac0c-f33d-42b5-a866-72afa7cbd0bd
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Recovery console: Allow floppy copy and access to all drives and folders
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **Recovery console: Allow floppy copy and access to all drives and folders** security policy setting.
-
## Reference
-
-
This policy setting enables or disables the Recovery Console SET command, which allows you to set the following Recovery Console environment variables.
-
- **AllowWildCards**. Enables wildcard support for some commands, such as the DEL command.
-
- **AllowAllPaths**. Allows access to all files and folders on the device.
-
- **AllowRemovableMedia**. Allows files to be copied to removable media, such as a floppy disk.
-
- **NoCopyPrompt**. Suppresses the prompt that typically displays before an existing file is overwritten.
-
You might forget to remove removable media, such as CD or floppy disk, with sensitive data or applications that a malicious user could then steal. Or you could accidentally leave a startup disk in the computer after using the Recovery Console. If the device is restarted for any reason and the BIOS has been configured to boot from the removable media before the hard disk drive, the server will start from the removable disk. This causes the server's network services to be unavailable.
-
### Possible values
-
- Enabled
-
- Disabled
-
- Not defined
-
### Best practices
-
- Set **Recovery Console: Allow floppy copy and access to drives and folders** to **Disabled**. Users who have started a server by using the Recovery Console and logged in with the built-in Administrator account will not be able to copy files and folders to a floppy disk.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -90,65 +67,30 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Group Policy
-
Setting and deploying this policy using Group Policy takes precedence over the setting on the local device.
-
### Policy conflicts
-
None.
-
### Command-line tools
-
Enabling this security option makes the Recovery Console SET command available, which allows you to set the following Recovery Console environment variables:
-
- AllowWildCards: Enable wildcard support for some commands (such as the DEL command).
-
- AllowAllPaths: Allow access to all files and folders on the device.
-
- AllowRemovableMedia: Allow files to be copied to removable media, such as a floppy disk.
-
- NoCopyPrompt: Do not prompt when overwriting an existing file.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
An attacker who can cause the system to restart into the Recovery Console could steal sensitive data and leave no audit or access trail.
-
### Countermeasure
-
Disable the **Recovery console: Allow floppy copy and access to drives and folders** setting.
-
### Potential impact
-
Users who have started a server through the Recovery Console and logged in with the built-in Administrator account cannot copy files and folders to a floppy disk.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/refresh-an-applocker-policy.md b/windows/keep-secure/refresh-an-applocker-policy.md
index f134252dff..b94e1582a1 100644
--- a/windows/keep-secure/refresh-an-applocker-policy.md
+++ b/windows/keep-secure/refresh-an-applocker-policy.md
@@ -2,73 +2,39 @@
title: Refresh an AppLocker policy (Windows 10)
description: This topic for IT professionals describes the steps to force an update for an AppLocker policy.
ms.assetid: 3f24fcbc-3926-46b9-a1a2-dd036edab8a9
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Refresh an AppLocker policy
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals describes the steps to force an update for an AppLocker policy.
-
If you update the rule collection on a local computer by using the Local Security Policy snap-in, the policy will take effect immediately. If Group Policy is used to distribute the AppLocker policy and you want to immediately implement the policy, you must manually refresh the policy. The Group Policy refresh might take several minutes, depending upon the number of policies within the Group Policy Object (GPO) and the number of target computers.
-
To use Group Policy to distribute the AppLocker policy change, you need to retrieve the deployed AppLocker policy first. To prepare for the update and subsequent refresh, see [Edit an AppLocker policy](edit-an-applocker-policy.md)
-
[Edit an AppLocker policy](edit-an-applocker-policy.md) and [Use the AppLocker Windows PowerShell cmdlets](use-the-applocker-windows-powershell-cmdlets.md).
-
To complete this procedure, you must have Edit Setting permission to edit a GPO. By default, members of the **Domain Admins** group, the **Enterprise Admins** group, and the **Group Policy Creator Owners** group have this permission.
-
**To manually refresh the AppLocker policy by using Group Policy**
-
1. From a command prompt, type **gpupdate /force**, and then press ENTER.
-
2. When the command finishes, close the command prompt window, and then verify that the intended rule behavior is correct. You can do this by checking the AppLocker event logs for events that include "policy applied."
-
To change a policy on an individual computer, or to implement that policy on other computers, without using Group Policy, you first need to update the rule within the rule collection. For information about updating existing rules, see [Edit AppLocker rules](edit-applocker-rules.md). For information about creating a new rule for an existing policy, see:
-
- [Create a rule that uses a publisher condition](create-a-rule-that-uses-a-publisher-condition.md)
-
- [Create a rule that uses a file hash condition](create-a-rule-that-uses-a-file-hash-condition.md)
-
- [Create a rule that uses a path condition](create-a-rule-that-uses-a-path-condition.md)
-
Membership in the local **Administrators** group, or equivalent, is the minimum required to complete this procedure.
-
**To refresh the AppLocker policy on the local computer**
-
- Update the rule collection by using the Local Security Policy console with one of the following procedures:
-
- [Edit AppLocker rules](edit-applocker-rules.md)
-
- [Delete an AppLocker rule](delete-an-applocker-rule.md)
-
- [Add exceptions for an AppLocker rule](configure-exceptions-for-an-applocker-rule.md)
-
When finished, the policy is in effect.
-
To make the same change on another device, you can use any of the following methods:
-
- From the device that you made the change on, export the AppLocker policy, and then import the policy onto the other device. To do this, use the AppLocker **Export Policy** and **Import Policy** features to copy the rules from the changed computer.
-
**Caution**
When importing rules from another computer, all the rules will be applied, not just the one that was updated. Merging policies allows both existing and updated (or new) rules to be applied.
-
-
- Merge AppLocker policies. For procedures to do this, see [Merge AppLocker policies manually](merge-applocker-policies-manually.md) and [Merge AppLocker policies by using Set-ApplockerPolicy](merge-applocker-policies-by-using-set-applockerpolicy.md).
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/registry-global-object-access-auditing.md b/windows/keep-secure/registry-global-object-access-auditing.md
index f544039c14..cf9eaa2938 100644
--- a/windows/keep-secure/registry-global-object-access-auditing.md
+++ b/windows/keep-secure/registry-global-object-access-auditing.md
@@ -2,35 +2,19 @@
title: Registry (Global Object Access Auditing) (Windows 10)
description: This topic for the IT professional describes the Advanced Security Audit policy setting, Registry (Global Object Access Auditing), which enables you to configure a global system access control list (SACL) on the registry of a computer.
ms.assetid: 953bb1c1-3f76-43be-ba17-4aed2304f578
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Registry (Global Object Access Auditing)
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional describes the Advanced Security Audit policy setting, **Registry (Global Object Access Auditing)**, which enables you to configure a global system access control list (SACL) on the registry of a computer.
-
If you select the **Configure security** check box on this policy’s property page, you can add a user or group to the global SACL. This enables you to define computer system access control lists (SACLs) per object type for the registry. The specified SACL is then automatically applied to every registry object type.
-
This policy setting must be used in combination with the **Registry** security policy setting under Object Access. For more info, see [Audit Registry](audit-registry.md).
-
## Related topics
-
-
[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/remove-computer-from-docking-station.md b/windows/keep-secure/remove-computer-from-docking-station.md
index 10454b9cdd..fa16818895 100644
--- a/windows/keep-secure/remove-computer-from-docking-station.md
+++ b/windows/keep-secure/remove-computer-from-docking-station.md
@@ -2,50 +2,30 @@
title: Remove computer from docking station (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Remove computer from docking station security policy setting.
ms.assetid: 229a385a-a862-4973-899a-413b1b5b6c30
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Remove computer from docking station
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Remove computer from docking station** security policy setting.
-
## Reference
-
-
This security setting determines whether a user can undock a portable device from its docking station without logging on. This policy setting only affects scenarios that involve a portable computer and its docking station.
-
If this user right is assigned to the user’s account (or if the user is a member of the assigned group), the user must log on before removing the portable device from its docking station. Otherwise, as a security measure, the user will not be able to log on after the device is removed from the docking station. If this policy is not assigned, the user may remove the portable device from its docking station without logging on, and then have the ability to start and log on to the device afterwards in its undocked state.
-
Constant: SeUndockPrivilege
-
### Possible values
-
- User-defined list of accounts
-
- Not Defined
-
### Best practices
-
- Assign this user right to only those accounts that are permitted to use the portable device.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
Although this portable device scenario does not normally apply to servers, by default this setting is Administrators on domain controllers and on stand-alone servers.
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -84,67 +64,31 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
A restart of the device is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
### Group Policy
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Anyone who has the **Remove computer from docking station** user right can log on and then remove a portable device from its docking station. If this setting is not defined, it has the same effect as if everyone was granted this right. However, the value of implementing this countermeasure is reduced by the following factors:
-
- If attackers can restart the device, they could remove it from the docking station after the BIOS starts but before the operating system starts.
-
- This setting does not affect servers because they typically are not installed in docking stations.
-
- An attacker could steal the device and the docking station together.
-
- Devices that can be mechanically undocked can be physically removed by the user whether or not they use the Windows undocking functionality.
-
### Countermeasure
-
Ensure that only the local Administrators group and the user account to which the device is allocated are assigned the **Remove computer from docking station** user right.
-
### Potential impact
-
By default, only members of the local Administrators group are granted this right. Other user accounts must be explicitly granted this user right as necessary. If your organization's users are not members of the local Administrators groups on their portable devices, they cannot remove their portable devices from their docking stations if they do not first shut down the device. Therefore, you may want to assign the **Remove computer from docking station** privilege to the local Users group for portable devices.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/replace-a-process-level-token.md b/windows/keep-secure/replace-a-process-level-token.md
index e3a17bfad2..237f74debf 100644
--- a/windows/keep-secure/replace-a-process-level-token.md
+++ b/windows/keep-secure/replace-a-process-level-token.md
@@ -2,54 +2,32 @@
title: Replace a process level token (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Replace a process level token security policy setting.
ms.assetid: 5add02db-6339-489e-ba21-ccc3ccbe8745
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Replace a process level token
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Replace a process level token** security policy setting.
-
## Reference
-
-
This policy setting determines which parent processes can replace the access token that is associated with a child process.
-
Specifically, the **Replace a process level token** setting determines which user accounts can call the CreateProcessAsUser() application programming interface (API) so that one service can start another. An example of a process that uses this user right is Task Scheduler, where the user right is extended to any processes that can be managed by Task Scheduler.
-
An access token is an object that describes the security context of a process or thread. The information in a token includes the identity and privileges of the user account that is associated with the process or thread. With this user right, every child process that runs on behalf of this user account would have its access token replaced with the process level token.
-
Constant: SeAssignPrimaryTokenPrivilege
-
### Possible values
-
- User-defined list of accounts
-
- Defaults
-
- Not defined
-
### Best practices
-
- For member servers, ensure that only the Local Service and Network Service accounts have the **Replace a process level token** user right.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
By default this setting is Network Service and Local Service on domain controllers and on stand-alone servers.
-
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
-
@@ -93,59 +71,27 @@ The following table lists the actual and effective default policy values for the
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
A restart of the device is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
### Group Policy
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Users with the **Replace a process level token** user right can start processes as another user if they know the user’s credentials.
-
### Countermeasure
-
For member servers, ensure that only the Local Service and Network Service accounts have the **Replace a process level token** user right.
-
### Potential impact
-
On most computers, restricting the **Replace a process level token** user right to the Local Service and the Network Service built-in accounts is the default configuration, and there is no negative impact. However, if you have installed optional components such as ASP.NET or IIS, you may need to assign the **Replace a process level token** user right to additional accounts. For example, IIS requires that the Service, Network Service, and IWAM\_*<ComputerName>* accounts be explicitly granted this user right.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/requirements-for-deploying-applocker-policies.md b/windows/keep-secure/requirements-for-deploying-applocker-policies.md
index c4f0103ef7..996718cd10 100644
--- a/windows/keep-secure/requirements-for-deploying-applocker-policies.md
+++ b/windows/keep-secure/requirements-for-deploying-applocker-policies.md
@@ -2,35 +2,23 @@
title: Requirements for deploying AppLocker policies (Windows 10)
description: This deployment topic for the IT professional lists the requirements that you need to consider before you deploy AppLocker policies.
ms.assetid: 3e55bda2-3cd7-42c7-bad3-c7dfbe193d48
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Requirements for deploying AppLocker policies
-
-
**Applies to**
-
- Windows 10
-
This deployment topic for the IT professional lists the requirements that you need to consider before you deploy AppLocker policies.
-
The following requirements must be met or addressed before you deploy your AppLocker policies:
-
- [Deployment plan](#bkmk-reqdepplan)
-
- [Supported operating systems](#bkmk-reqsupportedos)
-
- [Policy distribution mechanism](#bkmk-reqpolicydistmech)
-
- [Event collection and analysis system](#bkmk-reqeventcollectionsystem)
-
### Deployment plan
-
An AppLocker policy deployment plan is the result of investigating which applications are required and necessary in your organization, which apps are optional, and which apps are forbidden. To develop this plan, see [AppLocker Design Guide](applocker-policies-design-guide.md). The following table is an example of the data you need to collect and the decisions you need to make to successfully deploy AppLocker policies on the supported operating systems (as listed in [Requirements to use AppLocker](requirements-to-use-applocker.md).
-
@@ -126,11 +114,8 @@ An AppLocker policy deployment plan is the result of investigating which applica
-
-
**Event processing policy**
-
@@ -166,11 +151,8 @@ An AppLocker policy deployment plan is the result of investigating which applica
-
-
**Policy maintenance policy**
-
@@ -210,38 +192,17 @@ An AppLocker policy deployment plan is the result of investigating which applica
-
-
### Supported operating systems
-
AppLocker is supported only on certain operating systems. Some features are not available on all operating systems. For more information, see [Requirements to use AppLocker](requirements-to-use-applocker.md).
-
### Policy distribution mechanism
-
You need a way to distribute the AppLocker policies throughout the targeted business groups. AppLocker uses Group Policy management architecture to effectively distribute application control policies. AppLocker policies can also be configured on individual computers by using the Local Security Policy snap-in.
-
### Event collection and analysis system
-
Event processing is important to understand application usage. You must have a process in place to collect and analyze AppLocker events so that application usage is appropriately restricted and understood. For procedures to monitor AppLocker events, see:
-
- [Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md)
-
- [Configure an AppLocker policy for enforce rules](configure-an-applocker-policy-for-enforce-rules.md)
-
- [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md)
-
## See also
-
-
[AppLocker deployment guide](applocker-policies-deployment-guide.md)
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/requirements-to-use-applocker.md b/windows/keep-secure/requirements-to-use-applocker.md
index 2921b46a0e..db3259ce0a 100644
--- a/windows/keep-secure/requirements-to-use-applocker.md
+++ b/windows/keep-secure/requirements-to-use-applocker.md
@@ -2,42 +2,26 @@
title: Requirements to use AppLocker (Windows 10)
description: This topic for the IT professional lists software requirements to use AppLocker on the supported Windows operating systems.
ms.assetid: dc380535-071e-4794-8f9d-e5d1858156f0
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Requirements to use AppLocker
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional lists software requirements to use AppLocker on the supported Windows operating systems.
-
## General requirements
-
-
To use AppLocker, you need:
-
- A device running a supported operating system to create the rules. The computer can be a domain controller.
-
- For Group Policy deployment, at least one device with the Group Policy Management Console (GPMC) or Remote Server Administration Tools (RSAT) installed to host the AppLocker rules.
-
- Devices running a supported operating system to enforce the AppLocker rules that you create.
-
**Note**
You can use Software Restriction Policies with AppLocker, but with some limitations. For more info, see [Use AppLocker and Software Restriction Policies in the same domain](use-applocker-and-software-restriction-policies-in-the-same-domain.md).
-
-
## Operating system requirements
-
-
The following table show the on which operating systems AppLocker features are supported.
-
@@ -215,37 +199,14 @@ The following table show the on which operating systems AppLocker features are s
-
-
AppLocker is not supported on versions of the Windows operating system not listed above. Software Restriction Policies can be used with those versions. However, the SRP Basic User feature is not supported on the above operating systems.
-
## See also
-
-
[Administer AppLocker](administer-applocker.md)
-
-
[Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md)
-
-
[Optimize AppLocker performance](optimize-applocker-performance.md)
-
-
[Use AppLocker and Software Restriction Policies in the same domain](use-applocker-and-software-restriction-policies-in-the-same-domain.md)
-
-
[Manage packaged apps with AppLocker](manage-packaged-apps-with-applocker.md)
-
-
[AppLocker Design Guide](applocker-policies-design-guide.md)
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/reset-account-lockout-counter-after.md b/windows/keep-secure/reset-account-lockout-counter-after.md
index 4267057664..04fdcce682 100644
--- a/windows/keep-secure/reset-account-lockout-counter-after.md
+++ b/windows/keep-secure/reset-account-lockout-counter-after.md
@@ -2,46 +2,28 @@
title: Reset account lockout counter after (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Reset account lockout counter after security policy setting.
ms.assetid: d5ccf6dd-5ba7-44a9-8e0b-c478d8b1442c
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Reset account lockout counter after
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **Reset account lockout counter after** security policy setting.
-
## Reference
-
-
The **Reset account lockout counter after** policy setting determines the number of minutes that must elapse from the time a user fails to log on before the failed logon attempt counter is reset to 0. If [Account lockout threshold](account-lockout-threshold.md) is set to a number greater than zero, this reset time must be less than or equal to the value of [Account lockout duration](account-lockout-duration.md).
-
A disadvantage to setting this too high is that users lock themselves out for an inconveniently long period if they exceed the account lockout threshold through logon errors. Users may make excessive Help Desk calls.
-
### Possible values
-
- A user-defined number of minutes from 1 through 99,999
-
- Not defined
-
### Best practices
-
- You need to determine the threat level for your organization and balance that against the cost of your Help Desk support for password resets. Each organization will have specific requirements.
-
### Location
-
**Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Account Lockout Policy**
-
### Default values
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -80,36 +62,16 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Users can accidentally lock themselves out of their accounts if they mistype their password multiple times.
-
### Countermeasure
-
Configure the **Reset account lockout counter after** policy setting to 30.
-
### Potential impact
-
If you do not configure this policy setting or if the value is configured to an interval that is too long, an attacker could attempt to log on to each user's account numerous times and lock out their accounts, a denial-of-service (DoS) attack might succeed, or administrators might have to manually unlock all locked-out accounts. If you configure this policy setting to a reasonable value, users can perform new attempts to log on after a failed logon within a reasonable time, without making brute force attacks feasible at high speeds. Be sure that you notify users of the values that are used for this policy setting so that they wait for the lockout timer to expire before they call the Help Desk.
-
## Related topics
-
-
[Account Lockout Policy](account-lockout-policy.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/restore-files-and-directories.md b/windows/keep-secure/restore-files-and-directories.md
index e0941e62be..dc9f47c01a 100644
--- a/windows/keep-secure/restore-files-and-directories.md
+++ b/windows/keep-secure/restore-files-and-directories.md
@@ -2,56 +2,33 @@
title: Restore files and directories (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Restore files and directories security policy setting.
ms.assetid: c673c0fa-6f49-4edd-8c1f-c5e8513f701d
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Restore files and directories
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Restore files and directories** security policy setting.
-
## Reference
-
-
This security setting determines which users can bypass file, directory, registry, and other persistent object permissions when they restore backed up files and directories, and it determines which users can set valid security principals as the owner of an object.
-
Granting this user right to an account is similar to granting the account the following permissions to all files and folders on the system:
-
- **Traverse folder / execute file**
-
- **Write**
-
Constant: SeRestorePrivilege
-
### Possible values
-
- User-defined list of accounts
-
- Defaults
-
- Not Defined
-
### Best practices
-
- Users with this user right can overwrite registry settings, hide data, and gain ownership of system objects, so only assign this user right to trusted users.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
By default, this right is granted to the Administrators, Backup Operators, and Server Operators groups on domain controllers, and to the Administrators and Backup Operators groups on stand-alone servers.
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -97,64 +74,30 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
A restart of the computer is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
### Group Policy
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
An attacker with the **Restore files and directories** user right could restore sensitive data to a computer and overwrite data that is more recent, which could lead to loss of important data, data corruption, or a denial-of-service condition. Attackers could overwrite executable files that are used by legitimate administrators or system services with versions that include malicious software to grant themselves elevated privileges, compromise data, or install programs that provide continued access to the device
-
**Note**
Even if the following countermeasure is configured, an attacker could restore data to a computer in a domain that is controlled by the attacker. Therefore, it is critical that organizations carefully protect the media that are used to back up data.
-
-
### Countermeasure
-
Ensure that only the local Administrators group is assigned the **Restore files and directories** user right unless your organization has clearly defined roles for backup and for restore personnel.
-
### Potential impact
-
If you remove the **Restore files and directories** user right from the Backup Operators group and other accounts, users who are not members of the local Administrators group cannot load data backups. If restoring backups is delegated to a subset of IT staff in your organization, you should verify that this change does not negatively affect the ability of your organization's personnel to do their jobs.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/run-the-automatically-generate-rules-wizard.md b/windows/keep-secure/run-the-automatically-generate-rules-wizard.md
index 63611e7155..105d076374 100644
--- a/windows/keep-secure/run-the-automatically-generate-rules-wizard.md
+++ b/windows/keep-secure/run-the-automatically-generate-rules-wizard.md
@@ -2,64 +2,35 @@
title: Run the Automatically Generate Rules wizard (Windows 10)
description: This topic for IT professionals describes steps to run the wizard to create AppLocker rules on a reference device.
ms.assetid: 8cad1e14-d5b2-437c-8f88-70cffd7b3d8e
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Run the Automatically Generate Rules wizard
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals describes steps to run the wizard to create AppLocker rules on a reference device.
-
AppLocker allows you to automatically generate rules for all files within a folder. It will scan the specified folder and create the condition types that you choose for each file in that folder.
-
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group Policy Object (GPO) or by using the Local Security Policy snap-in for an AppLocker policy on a local device or in a security template. For info how to use these MMC snap-ins to administer AppLocker, see [Administer AppLocker](administer-applocker.md#bkmk-using-snapins).
-
**To automatically generate rules**
-
1. Open the AppLocker console.
-
2. Right-click the appropriate rule type for which you want to automatically generate rules. You can automatically generate rules for executable, Windows Installer, script and packaged app rules.
-
3. Click **Automatically Generate Rules**.
-
4. On the **Folder and Permissions** page, click **Browse** to choose the folder to be analyzed. By default, this is the Program Files folder.
-
5. Click **Select** to choose the security group in which the default rules should be applied. By default, this is the **Everyone** group.
-
6. The wizard provides a name in the **Name to identify this set of rules** box based on the name of the folder that you have selected. Accept the provided name or type a different name, and then click **Next**.
-
7. On the **Rule Preferences** page, choose the conditions that you want the wizard to use while creating rules, and then click **Next**. For more info about rule conditions, see [Understanding AppLocker rule condition types](understanding-applocker-rule-condition-types.md).
-
**Note**
The **Reduce the number of rules created by grouping similar files** check box is selected by default. This helps you organize AppLocker rules and reduce the number of rules that you create by performing the following operations for the rule condition that you select:
-
- One publisher condition is created for all files that have the same publisher and product name.
-
- One path condition is created for the folder that you select. For example, if you select *C:\\Program Files\\ProgramName\\* and the files in that folder are not signed, the wizard creates a rule for *%programfiles%\\ProgramName\\\**.
-
- One file hash condition is created that contains all of the file hashes. When rule grouping is disabled, the wizard creates a file hash rule for each file.
-
-
8. Review the files that were analyzed and the rules that will be automatically created. To make changes, click **Previous** to return to the page where you can change your selections. After reviewing the rules, click **Create**.
-
**Note**
If you are running the wizard to create your first rules for a GPO, you will be prompted to create the default rules, which allow critical system files to run, after completing the wizard. You may edit the default rules at any time. If your organization has decided to edit the default rules or create custom rules to allow the Windows system files to run, ensure that you delete the default rules after replacing them with your custom rules.
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/script-rules-in-applocker.md b/windows/keep-secure/script-rules-in-applocker.md
index d1c18e6cfb..5f1570086a 100644
--- a/windows/keep-secure/script-rules-in-applocker.md
+++ b/windows/keep-secure/script-rules-in-applocker.md
@@ -2,35 +2,23 @@
title: Script rules in AppLocker (Windows 10)
description: This topic describes the file formats and available default rules for the script rule collection.
ms.assetid: fee24ca4-935a-4c5e-8a92-8cf1d134d35f
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Script rules in AppLocker
-
-
**Applies to**
-
- Windows 10
-
This topic describes the file formats and available default rules for the script rule collection.
-
AppLocker defines script rules to include only the following file formats:
-
- .ps1
-
- .bat
-
- .cmd
-
- .vbs
-
- .js
-
The following table lists the default rules that are available for the script rule collection.
-
@@ -67,19 +55,8 @@ The following table lists the default rules that are available for the script ru
-
-
## Related topics
-
-
[Understanding AppLocker default rules](understanding-applocker-default-rules.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/secpol-advanced-security-audit-policy-settings.md b/windows/keep-secure/secpol-advanced-security-audit-policy-settings.md
index 6cc38ffbeb..768c9de4a0 100644
--- a/windows/keep-secure/secpol-advanced-security-audit-policy-settings.md
+++ b/windows/keep-secure/secpol-advanced-security-audit-policy-settings.md
@@ -2,40 +2,22 @@
title: Advanced security audit policy settings (Windows 10)
description: Provides information about the advanced security audit policy settings that are available in Windows and the audit events that they generate.
ms.assetid: 6BF9A642-DBC3-4101-94A3-B2316C553CE3
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Advanced security audit policy settings
-
-
**Applies to**
-
- Windows 10
-
Provides information about the advanced security audit policy settings that are available in Windows and the audit events that they generate.
-
The security audit policy settings under **Security Settings\\Advanced Audit Policy Configuration** can help your organization audit compliance with important business-related and security-related rules by tracking precisely defined activities, such as:
-
- A group administrator has modified settings or data on servers that contain finance information.
-
- An employee within a defined group has accessed an important file.
-
- The correct system access control list (SACL) is applied to every file and folder or registry key on a computer or file share as a verifiable safeguard against undetected access.
-
You can access these audit policy settings through the Local Security Policy snap-in (secpol.msc) on the local device or by using Group Policy.
-
These Advanced Audit policy settings allow you to select only the behaviors that you want to monitor. You can exclude audit results for behaviors that are of little or no concern to you, or behaviors that create an excessive number of log entries. In addition, because security audit policies can be applied by using domain Group Policy Objects, audit policy settings can be modified, tested, and deployed to selected users and groups with relative simplicity.
-
For more info, see [Advanced security audit policies](advanced-security-auditing.md).
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/security-auditing-overview.md b/windows/keep-secure/security-auditing-overview.md
index bc9ff675c5..ee62474c85 100644
--- a/windows/keep-secure/security-auditing-overview.md
+++ b/windows/keep-secure/security-auditing-overview.md
@@ -2,31 +2,20 @@
title: Security auditing (Windows 10)
description: Topics in this section are for IT professionals and describes the security auditing features in Windows and how your organization can benefit from using these technologies to enhance the security and manageability of your network.
ms.assetid: 2d9b8142-49bd-4a33-b246-3f0c2a5f32d4
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Security auditing
-
-
**Applies to**
-
- Windows 10
-
Topics in this section are for IT professionals and describes the security auditing features in Windows and how your organization can benefit from using these technologies to enhance the security and manageability of your network.
-
##
-
-
Security auditing is one of the most powerful tools that you can use to maintain the integrity of your system. As part of your overall security strategy, you should determine the level of auditing that is appropriate for your environment. Auditing should identify attacks (successful or not) that pose a threat to your network, and attacks against resources that you have determined to be valuable in your risk assessment.
-
For info on the changes that were added in Windows 10, see [Security auditing](../whats-new/security-auditing.md).
-
## In this section
-
-
@@ -49,14 +38,6 @@ For info on the changes that were added in Windows 10, see [Security auditing](
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/security-considerations-for-applocker.md b/windows/keep-secure/security-considerations-for-applocker.md
index 0fddbefbdc..023305b4f1 100644
--- a/windows/keep-secure/security-considerations-for-applocker.md
+++ b/windows/keep-secure/security-considerations-for-applocker.md
@@ -2,61 +2,33 @@
title: Security considerations for AppLocker (Windows 10)
description: This topic for the IT professional describes the security considerations you need to address when implementing AppLocker.
ms.assetid: 354a5abb-7b31-4bea-a442-aa9666117625
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Security considerations for AppLocker
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional describes the security considerations you need to address when implementing AppLocker.
-
The purpose of AppLocker is to restrict the access to software, and therefore, the data accessed by the software, to a specific group of users or within a defined business group. The following are security considerations for AppLocker:
-
AppLocker is deployed within an enterprise and administered centrally by those in IT with trusted credentials. This makes its policy creation and deployment conform to similar policy deployment processes and security restrictions.
-
AppLocker policies are distributed through known processes and by known means within the domain through Group Policy. But AppLocker policies can also be set on individual computers if the person has administrator privileges, and those policies might be contrary to the organization's written security policy. The enforcement settings for local policies are overridden by the same AppLocker policies in a Group Policy Object (GPO). However, because AppLocker rules are additive, a local policy that is not in a GPO will still be evaluated for that computer.
-
Microsoft does not provide a way to develop any extensions to AppLocker. The interfaces are not public. A user with administrator credentials can automate some AppLocker processes by using Windows PowerShell cmdlets. For info about the Windows PowerShell cmdlets for AppLocker, see the [AppLocker Cmdlets in Windows PowerShell](http://technet.microsoft.com/library/ee460962.aspx).
-
AppLocker runs in the context of Administrator or LocalSystem, which is the highest privilege set. This security context has the potential of misuse. If a user with administrative credentials makes changes to an AppLocker policy on a local device that is joined to a domain, those changes could be overwritten or disallowed by the GPO that contains the AppLocker rule for the same file (or path) that was changed on the local device. However, because AppLocker rules are additive, a local policy that is not in a GPO will still be evaluated for that computer. If the local computer is not joined to a domain and is not administered by Group Policy, a person with administrative credentials can alter the AppLocker policy.
-
When securing files in a directory with a rule of the path condition type, whether using the allow or deny action on the rule, it is still necessary and good practice to restrict access to those files by setting the access control lists (ACLs) according to your security policy.
-
AppLocker does not protect against running 16-bit DOS binaries in the Virtual DOS Machine (NTVDM). This technology allows running legacy DOS and 16-bit Windows programs on computers that are using Intel 80386 or later when there is already another operating system running and controlling the hardware. The result is that 16-bit binaries can still run on Windows Server 2008 R2 and Windows 7 when AppLocker is configured to otherwise block binaries and libraries. If it is a requirement to prevent 16-bit applications from running, you must configure the Deny rule in the executable rule collection for NTVDM.exe.
-
You cannot use AppLocker (or Software Restriction Policies) to prevent code from running outside the Win32 subsystem. In particular, this applies to the (POSIX) subsystem in Windows NT. If it is a requirement to prevent applications from running in the POSIX subsystem, you must disable the subsystem.
-
AppLocker can only control VBScript, JScript, .bat files, .cmd files, and Windows PowerShell scripts. It does not control all interpreted code that runs within a host process, for example, Perl scripts and macros. Interpreted code is a form of executable code that runs within a host process. For example, Windows batch files (\*.bat) run within the context of the Windows Command Host (cmd.exe). To control interpreted code by using AppLocker, the host process must call AppLocker before it runs the interpreted code, and then enforce the decision returned by AppLocker. Not all host processes call into AppLocker and, therefore, AppLocker cannot control every kind of interpreted code, such as Microsoft Office macros.
-
**Important**
You should configure the appropriate security settings of these host processes if you must allow them to run. For example, configure the security settings in Microsoft Office to ensure that only signed and trusted macros are loaded.
-
-
AppLocker rules either allow or prevent an application from launching. AppLocker does not control the behavior of applications after they are launched. Applications could contain flags passed to functions that signal AppLocker to circumvent the rules and allow another .exe or .dll to be loaded. In practice, an application that is allowed by AppLocker could use these flags to bypass AppLocker rules and launch child processes. You must thoroughly examine each application before allowing them to run by using AppLocker rules.
-
**Note**
Two flags that illustrate this condition are `SANDBOX_INERT`, which can be passed to `CreateRestrictedToken`, and `LOAD_IGNORE_CODE_AUTHZ_LEVEL`, which can be passed to `LoadLibraryEx`. Both of these flags signal AppLocker to circumvent the rules and allow a child .exe or .dll to be loaded.
-
-
## Related topics
-
-
[AppLocker technical reference](applocker-technical-reference.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/security-options.md b/windows/keep-secure/security-options.md
index b6d6747c20..1e083a249a 100644
--- a/windows/keep-secure/security-options.md
+++ b/windows/keep-secure/security-options.md
@@ -2,30 +2,20 @@
title: Security Options (Windows 10)
description: Provides an introduction to the settings under Security Options of the local security policies and links to information about each setting.
ms.assetid: 405ea253-8116-4e57-b08e-14a8dcdca92b
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Security Options
-
-
**Applies to**
-
- Windows 10
-
Provides an introduction to the settings under **Security Options** of the local security policies and links to information about each setting.
-
The **Security Options** contain the following groupings of security policy settings that allow you to configure the behavior of the local computer. Some of these policies can be included in a Group Policy Object and distributed over your organization.
-
If you edit policy settings locally on a device, you will affect the settings on only that one device. If you configure the settings in a Group Policy Object (GPO), the settings apply to all devices that are subject to that GPO.
-
For info about setting security policies, see [Configure security policy settings](how-to-configure-security-policy-settings.md).
-
## In this section
-
-
@@ -420,21 +410,9 @@ For info about setting security policies, see [Configure security policy setting
-
-
## Related topics
-
-
[Security policy settings reference](security-policy-settings-reference.md)
-
[Security policy settings](security-policy-settings.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/security-policy-settings-reference.md b/windows/keep-secure/security-policy-settings-reference.md
index 62c40372cc..83e2f87051 100644
--- a/windows/keep-secure/security-policy-settings-reference.md
+++ b/windows/keep-secure/security-policy-settings-reference.md
@@ -2,28 +2,19 @@
title: Security policy settings reference (Windows 10)
description: This reference of security settings provides information about how to implement and manage security policies, including setting options and security considerations.
ms.assetid: ef5a4579-15a8-4507-9a43-b7ccddcb0ed1
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Security policy settings reference
-
-
**Applies to**
-
- Windows 10
-
This reference of security settings provides information about how to implement and manage security policies, including setting options and security considerations.
-
This reference focuses on those settings that are considered security settings. This reference examines only the settings and features in the Windows operating systems that can help organizations secure their enterprises against malicious software threats. Management features and those security features that you cannot configure are not described in this reference.
-
Each policy setting described contains referential content such as a detailed explanation of the settings, best practices, default settings, differences between operating system versions, policy management considerations, and security considerations that include a discussion of vulnerability, countermeasures, and potential impact of those countermeasures.
-
## In this section
-
-
@@ -58,14 +49,6 @@ Each policy setting described contains referential content such as a detailed ex
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/security-policy-settings.md b/windows/keep-secure/security-policy-settings.md
index 67592a65d4..fb4adf5d9d 100644
--- a/windows/keep-secure/security-policy-settings.md
+++ b/windows/keep-secure/security-policy-settings.md
@@ -2,454 +2,232 @@
title: Security policy settings (Windows 10)
description: This reference topic describes the common scenarios, architecture, and processes for security settings.
ms.assetid: e7ac5204-7f6c-4708-a9f6-6af712ca43b9
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Security policy settings
-
-
**Applies to**
-
- Windows 10
-
This reference topic describes the common scenarios, architecture, and processes for security settings.
-
Security policy settings are rules that administrators configure on a computer or multiple devices for the purpose of protecting resources on a device or network. The Security Settings extension of the Local Group Policy Editor snap-in allows you to define security configurations as part of a Group Policy Object (GPO). The GPOs are linked to Active Directory containers such as sites, domains, or organizational units, and they enable you to manage security settings for multiple devices from any device joined to the domain. Security settings policies are used as part of your overall security implementation to help secure domain controllers, servers, clients, and other resources in your organization.
-
Security settings can control:
-
- User authentication to a network or device.
-
- The resources that users are permitted to access.
-
- Whether to record a user’s or group’s actions in the event log.
-
- Membership in a group.
-
To manage security configurations for multiple devices, you can use one of the following options:
-
- Edit specific security settings in a GPO.
-
- Use the Security Templates snap-in to create a security template that contains the security policies you want to apply, and then import the security template into a Group Policy Object. A security template is a file that represents a security configuration, and it can be imported to a GPO, applied to a local device, or used to analyze security.
-
For more info about managing security configurations, see [Administer security policy settings](administer-security-policy-settings.md).
-
The Security Settings extension of the Local Group Policy Editor includes the following types of security policies:
-
- **Account Policies.** These polices are defined on devices; they affect how user accounts can interact with the computer or domain. Account policies include the following types of policies:
-
- **Password Policy.** These policies determine settings for passwords, such as enforcement and lifetimes. Password policies are used for domain accounts.
-
- **Account Lockout Policy.** These policies determine the conditions and length of time that an account will be locked out of the system. Account lockout policies are used for domain or local user accounts.
-
- **Kerberos Policy.** These policies are used for domain user accounts; they determine Kerberos-related settings, such as ticket lifetimes and enforcement.
-
- **Local Policies.** These policies apply to a computer and include the following types of policy settings:
-
- **Audit Policy.** Specify security settings that control the logging of security events into the Security log on the computer, and specifies what types of security events to log (success, failure, or both).
-
**Note**
For devices running Windows 7 and later, we recommend to use the settings under Advanced Audit Policy Configuration rather than the Audit Policy settings under Local Policies.
-
-
- **User Rights Assignment.** Specify the users or groups that have logon rights or privileges on a device
-
- **Security Options.** Specify security settings for the computer, such as Administrator and Guest Account names; access to floppy disk drives and CD-ROM drives; installation of drivers; logon prompts; and so on.
-
- **Windows Firewall with Advanced Security.** Specify settings to protect the device on your network by using a stateful firewall that allows you to determine which network traffic is permitted to pass between your device and the network.
-
- **Network List Manager Policies.** Specify settings that you can use to configure different aspects of how networks are listed and displayed on one device or on many devices.
-
- **Public Key Policies.** Specify settings to control Encrypting File System, Data Protection, and BitLocker Drive Encryption in addition to certain certificate paths and services settings.
-
- **Software Restriction Policies.** Specify settings to identify software and to control its ability to run on your local device, organizational unit, domain, or site.
-
- **Application Control Policies.** Specify settings to control which users or groups can run particular applications in your organization based on unique identities of files.
-
- **IP Security Policies on Local Computer.** Specify settings to ensure private, secure communications over IP networks through the use of cryptographic security services. IPsec establishes trust and security from a source IP address to a destination IP address.
-
- **Advanced Audit Policy Configuration.** Specify settings that control the logging of security events into the security log on the device. The settings under Advanced Audit Policy Configuration provide finer control over which activities to monitor as opposed to the Audit Policy settings under Local Policies.
-
## Policy-based security settings management
-
-
The Security Settings extension to Group Policy provides an integrated policy-based management infrastructure to help you manage and enforce your security policies.
-
You can define and apply security settings policies to users, groups, and network servers and clients through Group Policy and Active Directory Domain Services (AD DS). A group of servers with the same functionality can be created (for example, a Microsoft Web (IIS) server), and then Group Policy Objects can be used to apply common security settings to the group. If more servers are added to this group later, many of the common security settings are automatically applied, reducing deployment and administrative labor.
-
### Common scenarios for using security settings policies
-
Security settings policies are used to manage the following aspects of security: accounts policy, local policy, user rights assignment, registry values, file and registry Access Control Lists (ACLs), service startup modes, and more.
-
As part of your security strategy, you can create GPOs with security settings policies configured specifically for the various roles in your organization, such as domain controllers, file servers, member servers, clients, and so on.
-
You can create an organizational unit (OU) structure that groups devices according to their roles. Using OUs is the best method for separating specific security requirements for the different roles in your network. This approach also allows you to apply customized security templates to each class of server or computer. After creating the security templates, you create a new GPO for each of the OUs, and then import the security template (.inf file) into the new GPO.
-
Importing a security template to a GPO ensures that any accounts to which the GPO is applied automatically receive the template’s security settings when the Group Policy settings are refreshed. On a workstation or server, the security settings are refreshed at regular intervals (with a random offset of at most 30 minutes), and, on a domain controller, this process occurs every few minutes if changes have occurred in any of the GPO settings that apply. The settings are also refreshed every 16 hours, whether or not any changes have occurred.
-
**Note**
These refresh settings vary between versions of the operating system and can be configured.
-
-
By using Group Policy−based security configurations in conjunction with the delegation of administration, you can ensure that specific security settings, rights, and behavior are applied to all servers and computers within an OU. This approach makes it simple to update a number of servers with any additional changes required in the future.
-
### Dependencies on other operating system technologies
-
For devices that are members of a Windows Server 2008 or later domain, security settings policies depend on the following technologies:
-
- **Active Directory Domain Services (AD DS)**
-
The Windows-based directory service, AD DS, stores information about objects on a network and makes this information available to administrators and users. By using AD DS, you can view and manage network objects on the network from a single location, and users can access permitted network resources by using a single logon.
-
- **Group Policy**
-
The infrastructure within AD DS that enables directory-based configuration management of user and computer settings on devices running Windows Server. By using Group Policy, you can define configurations for groups of users and computers, including policy settings, registry-based policies, software installation, scripts, folder redirection, Remote Installation Services, Internet Explorer maintenance, and security.
-
- **Domain Name System (DNS)**
-
A hierarchical naming system used for locating domain names on the Internet and on private TCP/IP networks. DNS provides a service for mapping DNS domain names to IP addresses, and IP addresses to domain names. This allows users, computers, and applications to query DNS to specify remote systems by fully qualified domain names rather than by IP addresses.
-
- **Winlogon**
-
A part of the Windows operating system that provides interactive logon support. Winlogon is designed around an interactive logon model that consists of three components: the Winlogon executable, a credential provider, and any number of network providers.
-
- **Setup**
-
Security configuration interacts with the operating system setup process during a clean installation or upgrade from earlier versions of Windows Server.
-
- **Security Accounts Manager (SAM)**
-
A Windows service used during the logon process. SAM maintains user account information, including groups to which a user belongs.
-
- **Local Security Authority (LSA)**
-
A protected subsystem that authenticates and logs users onto the local system. LSA also maintains information about all aspects of local security on a system, collectively known as the Local Security Policy of the system.
-
- **Windows Management Instrumentation (WMI)**
-
A feature of the Microsoft Windows operating system, WMI is the Microsoft implementation of Web-Based Enterprise Management (WBEM), which is an industry initiative to develop a standard technology for accessing management information in an enterprise environment. WMI provides access to information about objects in a managed environment. Through WMI and the WMI application programming interface (API), applications can query for and make changes to static information in the Common Information Model (CIM) repository and dynamic information maintained by the various types of providers.
-
- **Resultant Set of Policy (RSoP)**
-
An enhanced Group Policy infrastructure that uses WMI in order to make it easier to plan and debug policy settings. RSoP provides public methods that expose what an extension to Group Policy would do in a what-if situation, and what the extension has done in an actual situation. This allows administrators to easily determine the combination of policy settings that apply to, or will apply to, a user or device.
-
- **Service Control Manager (SCM)**
-
Used for configuration of service startup modes and security.
-
- **Registry**
-
Used for configuration of registry values and security.
-
- **File system**
-
Used for configuration of security.
-
- **File system conversions**
-
Security is set when an administrator converts a file system from FAT to NTFS.
-
- **Microsoft Management Console (MMC)**
-
The user interface for the Security Settings tool is an extension of the Local Group Policy Editor MMC snap-in.
-
### Security settings policies and Group Policy
-
The Security Settings extension of the Local Group Policy Editor is part of the Security Configuration Manager tool set. The following components are associated with Security Settings: a configuration engine; an analysis engine; a template and database interface layer; setup integration logic; and the secedit.exe command-line tool. The security configuration engine is responsible for handling security configuration editor-related security requests for the system on which it runs. The analysis engine analyzes system security for a given configuration and saves the result. The template and database interface layer handles reading and writing requests from and to the template or database (for internal storage). The Security Settings extension of the Local Group Policy Editor handles Group Policy from a domain-based or local device. The security configuration logic integrates with setup and manages system security for a clean installation or upgrade to a more recent Windows operating system. Security information is stored in templates (.inf files) or in the Secedit.sdb database.
-
The following diagram shows Security Settings and related features.
-
**Security Settings Policies and Related Features**
-
-
- **Scesrv.dll**
-
Provides the core security engine functionality.
-
- **Scecli.dll**
-
Provides the client-side interfaces to the security configuration engine and provides data to Resultant Set of Policy (RSoP).
-
- **Wsecedit.dll**
-
The Security Settings extension of Local Group Policy Editor. scecli.dll is loaded into wsecedit.dll to support the Security Settings user interface.
-
- **Gpedit.dll**
-
The Local Group Policy Editor MMC snap-in.
-
## Security Settings extension architecture
-
-
The Security Settings extension of the Local Group Policy Editor is part of the Security Configuration Manager tools, as shown in the following diagram.
-
**Security Settings Architecture**
-
-
The security settings configuration and analysis tools include a security configuration engine, which provides local computer (non-domain member) and Group Policy−based configuration and analysis of security settings policies. The security configuration engine also supports the creation of security policy files. The primary features of the security configuration engine are scecli.dll and scesrv.dll.
-
The following list describes these primary features of the security configuration engine and other Security Settings−related features.
-
- **scesrv.dll**
-
This .dll is hosted in services.exe and runs under local system context. scesrv.dll provides core Security Configuration Manager functionality, such as import, configure, analyze, and policy propagation.
-
Scesrv.dll performs configuration and analysis of various security-related system parameters by calling corresponding system APIs, including LSA, SAM, and the registry.
-
Scesrv.dll exposes APIs such as import, export, configure, and analyze. It checks that the request is made over LRPC (Windows XP) and fails the call if it is not.
-
Communication between parts of the Security Settings extension occurs by using the following methods:
-
- Component Object Model (COM) calls
-
- Local Remote Procedure Call (LRPC)
-
- Lightweight Directory Access Protocol (LDAP)
-
- Active Directory Service Interfaces (ADSI)
-
- Server Message Block (SMB)
-
- Win32 APIs
-
- Windows Management Instrumentation (WMI) calls
-
On domain controllers, scesrv.dll receives notifications of changes made to SAM and the LSA that need to be synchronized across domain controllers. Scesrv.dll incorporates those changes into the Default Domain Controller Policy GPO by using in-process scecli.dll template modification APIs.
-
Scesrv.dll also performs configuration and analysis operations.
-
- **Scecli.dll**
-
This is the client-side interface or wrapper to scesrv.dll. scecli.dll is loaded into Wsecedit.dll to support MMC snap-ins. It is used by Setup to configure default system security and security of files, registry keys, and services installed by the Setup API .inf files.
-
The command-line version of the security configuration and analysis user interfaces, secedit.exe, uses scecli.dll.
-
Scecli.dll implements the client-side extension for Group Policy.
-
Scesrv.dll uses scecli.dll to download applicable Group Policy files from SYSVOL in order to apply Group Policy security settings to the local device.
-
Scecli.dll logs application of security policy into WMI (RSoP).
-
Scesrv.dll policy filter uses scecli.dll to update Default Domain Controller Policy GPO when changes are made to SAM and LSA.
-
- **Wsecedit.dll**
-
The Security Settings extension of the Group Policy Object Editor snap-in. You use this tool to configure security settings in a Group Policy Object for a site, domain, or organizational unit. You can also use Security Settings to import security templates to a GPO.
-
- **Secedit.sdb**
-
This is a permanent system database used for policy propagation including a table of persistent settings for rollback purposes.
-
- **User databases**
-
A user database is any database other than the system database created by administrators for the purposes of configuration or analysis of security.
-
- **.Inf Templates**
-
These are text files that contain declarative security settings. They are loaded into a database before configuration or analysis. Group Policy security policies are stored in .inf files on the SYSVOL folder of domain controllers, where they are downloaded (by using file copy) and merged into the system database during policy propagation.
-
## Security settings policy processes and interactions
-
-
For a domain-joined device, where Group Policy is administered, security settings are processed in conjunction with Group Policy. Not all settings are configurable.
-
### Group Policy processing
-
When a computer starts and a user logs on, computer policy and user policy are applied according to the following sequence:
-
1. The network starts. Remote Procedure Call System Service (RPCSS) and Multiple Universal Naming Convention Provider (MUP) start.
-
2. An ordered list of Group Policy Objects is obtained for the device. The list might depend on these factors:
-
- Whether the device is part of a domain and, therefore, subject to Group Policy through Active Directory.
-
- The location of the device in Active Directory.
-
- Whether the list of Group Policy Objects has changed. If the list of Group Policy Objects has not changed, no processing is done.
-
3. Computer policy is applied. These are the settings under Computer Configuration from the gathered list. This is a synchronous process by default and occurs in the following order: local, site, domain, organizational unit, child organizational unit, and so on. No user interface appears while computer policies are processed.
-
4. Startup scripts run. This is hidden and synchronous by default; each script must complete or time out before the next one starts. The default time-out is 600 seconds. You can use several policy settings to modify this behavior.
-
5. The user presses CTRL+ALT+DEL to log on.
-
6. After the user is validated, the user profile loads; it is governed by the policy settings that are in effect.
-
7. An ordered list of Group Policy Objects is obtained for the user. The list might depend on these factors:
-
- Whether the user is part of a domain and, therefore, subject to Group Policy through Active Directory.
-
- Whether loopback policy processing is enabled, and if so, the state (Merge or Replace) of the loopback policy setting.
-
- The location of the user in Active Directory.
-
- Whether the list of Group Policy Objects has changed. If the list of Group Policy Objects has not changed, no processing is done.
-
8. User policy is applied. These are the settings under User Configuration from the gathered list. This is synchronous by default and in the following order: local, site, domain, organizational unit, child organizational unit, and so on. No user interface appears while user policies are processed.
-
9. Logon scripts run. Group Policy−based logon scripts are hidden and asynchronous by default. The user object script runs last.
-
10. The operating system user interface that is prescribed by Group Policy appears.
-
### Group Policy Objects storage
-
A Group Policy Object (GPO) is a virtual object that is identified by a Globally Unique Identifier (GUID) and stored at the domain level. The policy setting information of a GPO is stored in the following two locations:
-
- **Group Policy containers in Active Directory.**
-
The Group Policy container is an Active Directory container that contains GPO properties, such as version information, GPO status, plus a list of other component settings.
-
- **Group Policy templates in a domain’s system volume folder (SYSVOL).**
-
The Group Policy template is a file system folder that includes policy data specified by .admx files, security settings, script files, and information about applications that are available for installation. The Group Policy template is located in the SYSVOL folder in the domain\\Policies subfolder.
-
The **GROUP\_POLICY\_OBJECT** structure provides information about a GPO in a GPO list, including the version number of the GPO, a pointer to a string that indicates the Active Directory portion of the GPO, and a pointer to a string that specifies the path to the file system portion of the GPO.
-
### Group Policy processing order
-
Group Policy settings are processed in the following order:
-
1. **Local Group Policy Object.**
-
Each device running a Windows operating system beginning with Windows XP has exactly one Group Policy Object that is stored locally.
-
2. **Site.**
-
Any Group Policy Objects that have been linked to the site are processed next. Processing is synchronous and in an order that you specify.
-
3. **Domain.**
-
Processing of multiple domain-linked Group Policy Objects is synchronous and in an order you speciy.
-
4. **Organizational units.**
-
Group Policy Objects that are linked to the organizational unit that is highest in the Active Directory hierarchy are processed first, then Group Policy Objects that are linked to its child organizational unit, and so on. Finally, the Group Policy Objects that are linked to the organizational unit that contains the user or device are processed.
-
At the level of each organizational unit in the Active Directory hierarchy, one, many, or no Group Policy Objects can be linked. If several Group Policy Objects are linked to an organizational unit, their processing is synchronous and in an order that you specify.
-
This order means that the local Group Policy Object is processed first, and Group Policy Objects that are linked to the organizational unit of which the computer or user is a direct member are processed last, which overwrites the earlier Group Policy Objects.
-
This is the default processing order and administrators can specify exceptions to this order. A Group Policy Object that is linked to a site, domain, or organizational unit (not a local Group Policy Object) can be set to **Enforced** with respect to that site, domain, or organizational unit, so that none of its policy settings can be overridden. At any site, domain, or organizational unit, you can mark Group Policy inheritance selectively as **Block Inheritance**. Group Policy Object links that are set to **Enforced** are always applied, however, and they cannot be blocked.
-
### Security settings policy processing
-
In the context of Group Policy processing, security settings policy is processed in the following order.
-
1. During Group Policy processing, the Group Policy engine determines which security settings policies to apply.
-
2. If security settings policies exist in a GPO, Group Policy invokes the Security Settings client-side extension.
-
3. The Security Settings extension downloads the policy from the appropriate location such as a specific domain controller.
-
4. The Security Settings extension merges all security settings policies according to precedence rules. The processing is according to the Group Policy processing order of local, site, domain, and organizational unit (OU), as described earlier in the “Group Policy processing order” section. If multiple GPOs are in effect for a given device and there are no conflicting policies, then the policies are cumulative and are merged.
-
This example uses the Active Directory structure shown in the following figure. A given computer is a member of OU2, to which the **GroupMembershipPolGPO** GPO is linked. This computer is also subject to the **UserRightsPolGPO** GPO, which is linked to OU1, higher in the hierarchy. In this case, no conflicting policies exist so the device receives all of the policies contained in both the **UserRightsPolGPO** and the **GroupMembershipPolGPO** GPOs.
-
**Multiple GPOs and Merging of Security Policy**
-
-
5. The resultant security policies are stored in secedit.sdb, the security settings database. The security engine gets the security template files and imports them to secedit.sdb.
-
6. The security settings policies are applied to devices.
-
The following figure illustrates the security settings policy processing.
-
**Security Settings Policy Processing**
-
-
### Merging of security policies on domain controllers
-
Password policies, Kerberos, and some security options are only merged from GPOs that are linked at the root level on the domain. This is done to keep those settings synchronized across all domain controllers in the domain. The following security options are merged:
-
- Network Security: Force logoff when logon hours expire
-
- Accounts: Administrator account status
-
- Accounts: Guest account status
-
- Accounts: Rename administrator account
-
- Accounts: Rename guest account
-
Another mechanism exists that allows security policy changes made by administrators by using net accounts to be merged into the Default Domain Policy GPO. User rights changes that are made by using Local Security Authority (LSA) APIs are filtered into the Default Domain Controllers Policy GPO.
-
### Special considerations for domain controllers
-
If an application is installed on a primary domain controller (PDC) with operations master role (also known as flexible single master operations or FSMO) and the application makes changes to user rights or password policy, these changes must be communicated to ensure that synchronization across domain controllers occurs. Scesrv.dll receives a notification of any changes made to the security account manager (SAM) and LSA that need to be synchronized across domain controllers and then incorporates the changes into the Default Domain Controller Policy GPO by using scecli.dll template modification APIs.
-
### When security settings are applied
-
After you have edited the security settings policies, the settings are refreshed on the computers in the organizational unit linked to your Group Policy Object in the following instances:
-
- When a device is restarted.
-
- Every 90 minutes on a workstation or server and every 5 minutes on a domain controller. This refresh interval is configurable.
-
- By default, Security policy settings delivered by Group Policy are also applied every 16 hours (960 minutes) even if a GPO has not changed.
-
### Persistence of security settings policy
-
Security settings can persist even if a setting is no longer defined in the policy that originally applied it.
-
Security settings might persist in the following cases:
-
- The setting has not been previously defined for the device.
-
- The setting is for a registry security object.
-
- The settings are for a file system security object.
-
All settings applied through local policy or through a Group Policy Object are stored in a local database on your computer. Whenever a security setting is modified, the computer saves the security setting value to the local database, which retains a history of all the settings that have been applied to the computer. If a policy first defines a security setting and then no longer defines that setting, then the setting takes on the previous value in the database. If a previous value does not exist in the database then the setting does not revert to anything and remains defined as is. This behavior is sometimes referred to as “tattooing.”
-
Registry and file security settings will maintain the values applied through Group Policy until that setting is set to other values.
-
### Permissions required for policy to apply
-
Both Apply Group Policy and Read permissions are required to have the settings from a Group Policy Object apply to users or groups, and computers.
-
### Filtering security policy
-
By default, all GPOs have Read and Apply Group Policy both Allowed for the Authenticated Users group. The Authenticated Users group includes both users and computers. Security settings policies are computer-based. To specify which client computers will or will not have a Group Policy Object applied to them, you can deny them either the Apply Group Policy or Read permission on that Group Policy Object. Changing these permissions allows you to limit the scope of the GPO to a specific set of computers within a site, domain, or OU.
-
**Note**
Do not use security policy filtering on a domain controller as this would prevent security policy from applying to it.
-
-
### Migration of GPOs containing security settings
-
In some situations, you might want to migrate GPOs from one domain environment to another environment. The two most common scenarios are test-to-production migration, and production-to-production migration. The GPO copying process has implications for some types of security settings.
-
Data for a single GPO is stored in multiple locations and in various formats; some data is contained in Active Directory and other data is stored on the SYSVOL share on the domain controllers. Certain policy data might be valid in one domain but might be invalid in the domain to which the GPO is being copied. For example, Security Identifiers (SIDs) stored in security policy settings are often domain-specific. So copying GPOs is not as simple as taking a folder and copying it from one device to another.
-
The following security policies can contain security principals and might require some additional work to successfully move them from one domain to another.
-
- User rights assignment
-
- Restricted groups
-
- Services
-
- File system
-
- Registry
-
- The GPO DACL, if you choose to preserve it during a copy operation
-
To ensure that data is copied correctly, you can use Group Policy Management Console (GPMC). When migrating a GPO from one domain to another, GPMC ensures that all relevant data is properly copied. GPMC also offers migration tables, which can be used to update domain-specific data to new values as part of the migration process. GPMC hides much of the complexity involved in the migrating GPO operations, and it provides simple and reliable mechanisms for performing operations such as copy and backup of GPOs.
-
## In this section
-
-
@@ -476,14 +254,6 @@ To ensure that data is copied correctly, you can use Group Policy Management Con
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/security-technologies.md b/windows/keep-secure/security-technologies.md
index 741e8c2005..b1beb54dd3 100644
--- a/windows/keep-secure/security-technologies.md
+++ b/windows/keep-secure/security-technologies.md
@@ -2,13 +2,64 @@
title: Security technologies (Windows 10)
description: Learn more about the different security technologies that are available in Windows 10 and Windows 10 Mobile.
ms.assetid: BFE2DE22-B0CE-465B-8CF6-28F64464DF08
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Security technologies
+<<<<<<< HEAD
+Learn more about the different security technologies that are available in Windows 10 and Windows 10 Mobile.
+## In this section
+
+
+
+
+
+
+
+
+
+
+[AppLocker](applocker-overview.md) |
+This topic provides a description of AppLocker and can help you decide if your organization can benefit from deploying AppLocker application control policies. AppLocker helps you control which apps and files users can run. These include executable files, scripts, Windows Installer files, dynamic-link libraries (DLLs), packaged apps, and packaged app installers. |
+
+
+[BitLocker](bitlocker-overview.md) |
+This topic provides a high-level overview of BitLocker, including a list of system requirements, practical applications, and deprecated features. |
+
+
+[Encrypted Hard Drive](encrypted-hard-drive.md) |
+Encrypted Hard Drive uses the rapid encryption that is provided by BitLocker Drive Encryption to enhance data security and management. |
+
+
+[Security auditing](security-auditing-overview.md) |
+Topics in this section are for IT professionals and describes the security auditing features in Windows and how your organization can benefit from using these technologies to enhance the security and manageability of your network. |
+
+
+[Security policy settings](security-policy-settings.md) |
+This reference topic describes the common scenarios, architecture, and processes for security settings. |
+
+
+[Trusted Platform Module](trusted-platform-module-overview.md) |
+This topic for the IT professional describes the Trusted Platform Module (TPM) and how Windows uses it for access control and authentication. The topic provides links to other resources about the TPM. |
+
+
+[User Account Control](user-account-control-overview.md) |
+User Account Control (UAC) helps prevent malware from damaging a PC and helps organizations deploy a better-managed desktop. With UAC, apps and tasks always run in the security context of a non-administrator account, unless an administrator specifically authorizes administrator-level access to the system. UAC can block the automatic installation of unauthorized apps and prevent inadvertent changes to system settings. |
+
+
+[Windows Defender in Windows 10](windows-defender-in-windows-10.md) |
+This topic provides an overview of Windows Defender, including a list of system requirements and new features. |
+
+
+
+
+=======
Learn more about the different security technologies that are available in Windows 10 and Windows 10 Mobile.
@@ -24,11 +75,6 @@ Learn more about the different security technologies that are available in Windo
| [Windows Defender Advanced Threat Protection](windows-defender-advanced-threat-protection.md)| Windows Defender Advanced Threat Protection (Windows Defender ATP) is an out-of-the-box Windows enterprise security service that enables enterprise cybersecurity teams to detect and respond to advanced threats on their networks.|
| [Windows Defender in Windows 10](windows-defender-in-windows-10.md)| This topic provides an overview of Windows Defender, including a list of system requirements and new features.|
+>>>>>>> master
-
-
-
-
-
-
diff --git a/windows/keep-secure/select-types-of-rules-to-create.md b/windows/keep-secure/select-types-of-rules-to-create.md
index b40dc6855b..7f3a82de40 100644
--- a/windows/keep-secure/select-types-of-rules-to-create.md
+++ b/windows/keep-secure/select-types-of-rules-to-create.md
@@ -2,59 +2,35 @@
title: Select the types of rules to create (Windows 10)
description: This topic lists resources you can use when selecting your application control policy rules by using AppLocker.
ms.assetid: 14751169-0ed1-47cc-822c-8c01a7477784
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Select the types of rules to create
-
-
**Applies to**
-
- Windows 10
-
This topic lists resources you can use when selecting your application control policy rules by using AppLocker.
-
When determining what types of rules to create for each of your groups, you should also determine what enforcement setting to use for each group. Different rule types are more applicable for some apps, depending on the way that the applications are deployed in a specific business group.
-
The following topics provide additional information about AppLocker rules that can help you decide what rules to use for your applications:
-
- [Understanding AppLocker rule behavior](understanding-applocker-rule-behavior.md)
-
- [Understanding AppLocker rule exceptions](understanding-applocker-rule-exceptions.md)
-
- [Understanding AppLocker rule collections](understanding-applocker-rule-collections.md)
-
- [Understanding AppLocker allow and deny actions on rules](understanding-applocker-allow-and-deny-actions-on-rules.md)
-
- [Understanding AppLocker rule condition types](understanding-applocker-rule-condition-types.md)
-
- [Understanding AppLocker default rules](understanding-applocker-default-rules.md)
-
### Select the rule collection
-
The rules you create will be in one of the following rule collections:
-
- Executable files: .exe and .com
-
- Windows Installer files: .msi, .msp, and .mst
-
- Scripts: .ps1, .bat, .cmd, .vbs, and .js
-
- Packaged apps and packaged app installers: .appx
-
- DLLs: .dll and .ocx
-
By default, the rules will allow a file to run based upon user or group privilege. If you use DLL rules, a DLL allow rule has to be created for each DLL that is used by all of the allowed apps. The DLL rule collection is not enabled by default.
-
In the Woodgrove Bank example, the line-of-business app for the Bank Tellers business group is C:\\Program Files\\Woodgrove\\Teller.exe, and this app needs to be included in a rule. In addition, because this rule is part of a list of allowed applications, all the Windows files under C:\\Windows must be included as well.
-
### Determine the rule condition
-
A rule condition is criteria upon which an AppLocker rule is based and can only be one of the rule conditions in the following table.
-
@@ -86,37 +62,17 @@ A rule condition is criteria upon which an AppLocker rule is based and can only
-
-
In the Woodgrove Bank example, the line-of-business app for the Bank Tellers business group is signed and is located at C:\\Program Files\\Woodgrove\\Teller.exe. Therefore, the rule can be defined with a publisher condition. If the rule is defined to a specific version and above (for example, Teller.exe version 8.0 and above), then this will allow any updates to this app to occur without interruption of access to the users if the app's name and signed attributes stay the same.
-
### Determine how to allow system files to run
-
Because AppLocker rules build a list of allowed apps, a rule or rules must be created to allow all Windows files to run. AppLocker provides a means to ensure system files are properly considered in your rule collection by generating the default rules for each rule collection. You can use the default rules as a template when creating your own rules. However, these rules are only meant to function as a starter policy when you are first testing AppLocker rules so that the system files in the Windows folders will be allowed to run. When a default rule is created, it is denoted with "(Default rule)" in its name as it appears in the rule collection.
-
You can also create a rule for the system files based on the path condition. In the preceding example, for the Bank Tellers group, all Windows files reside under C:\\Windows and can be defined with the path rule condition type. This will permit access to these files whenever updates are applied and the files change. If you require additional application security, you might need to modify the rules created from the built-in default rule collection. For example, the default rule to allow all users to run .exe files in the Windows folder is based on a path condition that allows all files within the Windows folder to run. The Windows folder contains a Temp subfolder to which the Users group is given the following permissions:
-
- Traverse Folder/Execute File
-
- Create Files/Write Data
-
- Create Folders/Append Data
-
These permissions settings are applied to this folder for application compatibility. However, because any user can create files in this location, allowing apps to be run from this location might conflict with your organization's security policy.
-
## Next steps
-
-
After you have selected the types of rules to create, record your findings as explained in [Document your AppLocker rules](document-your-applocker-rules.md).
-
After recording your findings for the AppLocker rules to create, you will need to consider how to enforce the rules. For info about how to do this, see [Determine Group Policy structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md).
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/shut-down-the-system.md b/windows/keep-secure/shut-down-the-system.md
index 146683721a..fc101c8428 100644
--- a/windows/keep-secure/shut-down-the-system.md
+++ b/windows/keep-secure/shut-down-the-system.md
@@ -2,56 +2,33 @@
title: Shut down the system (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Shut down the system security policy setting.
ms.assetid: c8e8f890-153a-401e-a957-ba6a130304bf
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Shut down the system
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Shut down the system** security policy setting.
-
## Reference
-
-
This security setting determines if a user who is logged on locally to a device can shut down Windows.
-
Shutting down domain controllers makes them unavailable to perform functions such as processing logon requests, processing Group Policy settings, and answering Lightweight Directory Access Protocol (LDAP) queries. Shutting down domain controllers that have been assigned operations master roles (also known as flexible single master operations or FSMO roles) can disable key domain functionality; for example, processing logon requests for new passwords, which is performed by the primary domain controller (PDC) emulator master.
-
The **Shut down the system** user right is required to enable hibernation support, to set the power management settings, and to cancela shutdown.
-
Constant: SeShutdownPrivilege
-
### Possible values
-
- A user-defined list of accounts
-
- Defaults
-
- Not defined
-
### Best practices
-
1. Ensure that only Administrators and Backup Operators have the **Shut down the system** user right on member servers, and that only Administrators have the user right on domain controllers. Removing these default groups might limit the abilities of users who are assigned to specific administrative roles in your environment. Ensure that their delegated tasks will not be negatively affected.
-
2. The ability to shut down domain controllers should be limited to a very small number of trusted administrators. Even though a system shutdown requires the ability to log on to the server, you should be very careful about the accounts and groups that you allow to shut down a domain controller.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
By default this setting is Administrators, Backup Operators, Server Operators, and Print Operators on domain controllers, and Administrators and Backup Operators on stand-alone servers.
-
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
-
@@ -100,65 +77,30 @@ The following table lists the actual and effective default policy values for the
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
A restart of the computer is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
### Group Policy
-
This user right does not have the same effect as **Force shutdown from a remote system**. For more information, see [Force shutdown from a remote system](force-shutdown-from-a-remote-system.md).
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
The ability to shut down domain controllers should be limited to a very small number of trusted administrators. Although the **Shut down the system** user right requires the ability to log on to the server, you should be very careful about which accounts and groups you allow to shut down a domain controller.
-
When a domain controller is shut down, it is no longer available to process logon requests, process Group Policy settings, and answer Lightweight Directory Access Protocol (LDAP) queries. If you shut down domain controllers that possess operations master roles, you can disable key domain functionality, such as processing logon requests for new passwords, which is performed by the PDC master.
-
For other server roles, especially those where non-administrators have rights to log on to the server (such as RD Session Host servers), it is critical that this user right be removed from users that do not have a legitimate reason to restart the servers.
-
### Countermeasure
-
Ensure that only the Administrators and Backup Operators groups are assigned the **Shut down the system** user right on member servers, and ensure that only the Administrators group is assigned the user right on domain controllers.
-
### Potential impact
-
The impact of removing these default groups from the **Shut down the system** user right could limit the delegated abilities of assigned roles in your environment. You should confirm that delegated activities are not adversely affected.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/shutdown-allow-system-to-be-shut-down-without-having-to-log-on.md b/windows/keep-secure/shutdown-allow-system-to-be-shut-down-without-having-to-log-on.md
index 90d093a627..ad159693ce 100644
--- a/windows/keep-secure/shutdown-allow-system-to-be-shut-down-without-having-to-log-on.md
+++ b/windows/keep-secure/shutdown-allow-system-to-be-shut-down-without-having-to-log-on.md
@@ -2,54 +2,32 @@
title: Shutdown Allow system to be shut down without having to log on (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Shutdown Allow system to be shut down without having to log on security policy setting.
ms.assetid: f3964767-5377-4416-8eb3-e14d553a7315
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Shutdown: Allow system to be shut down without having to log on
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **Shutdown: Allow system to be shut down without having to log on** security policy setting.
-
## Reference
-
-
This policy setting determines whether a device can be shut down without having to log on to Windows. If you enable this policy setting, the **Shut Down** option is available on the logon screen in Windows. If you disable this policy setting, the **Shut Down** option is removed from the logon screen. This configuration requires that users are able to log on to the device successfully and that they have the **Shut down the system** user right before they can perform a shutdown.
-
Users who can access the console locally can shut down the system. Attackers or misguided users can connect to the server by using Remote Desktop Services, and then shut it down or restart it without having to identify themselves. A malicious user might also cause a temporary denial-of-service condition by walking up to the local console and restarting the server, or shutting down the server and thus rendering unavailable all its applications and services.
-
### Possible values
-
- Enabled
-
The shut down command is available on the logon screen.
-
- Disabled
-
The shut down option is removed from the logon screen and users must have the **Shut down the system** user right before they can perform a shutdown.
-
- Not defined
-
### Best practices
-
1. On servers, set this policy to **Disabled**. You must log on to servers to shut them down or restart them.
-
2. On client devices, set this policy to **Enabled** and define the list of those with the right to shut them down or restart them with the User Rights Assignment policy **Shut down the system**.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -88,51 +66,23 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a computer restart when they are saved locally or distributed through Group Policy.
-
### Group Policy
-
For info about the User Rights Assignment policy, **Shut down the system**, see [Shut down the system](shut-down-the-system.md).
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Users who can access the console locally could shut down the device
-
Attackers who have access to the local console could restart the server, which would cause a temporary DoS condition. Attackers could also shut down the server and leave all of its applications and services unavailable.
-
### Countermeasure
-
Disable the **Shutdown: Allow system to be shut down without having to log on** setting.
-
### Potential impact
-
You must log on to servers to shut them down or restart them.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/shutdown-clear-virtual-memory-pagefile.md b/windows/keep-secure/shutdown-clear-virtual-memory-pagefile.md
index 1076dedd2f..042254e9c7 100644
--- a/windows/keep-secure/shutdown-clear-virtual-memory-pagefile.md
+++ b/windows/keep-secure/shutdown-clear-virtual-memory-pagefile.md
@@ -2,50 +2,30 @@
title: Shutdown Clear virtual memory pagefile (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Shutdown Clear virtual memory pagefile security policy setting.
ms.assetid: 31400078-6c56-4891-a6df-6dfb403c4bc9
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Shutdown: Clear virtual memory pagefile
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **Shutdown: Clear virtual memory pagefile** security policy setting.
-
## Reference
-
-
This policy setting determines whether the virtual memory paging file is cleared when the device is shut down. Virtual memory support uses a system paging file to swap pages of memory to disk when they are not used. On a running device, this paging file is opened exclusively by the operating system, and it is well protected. However, devices that are configured to allow other operating systems to start should verify that the system paging file is cleared as the device shuts down. This confirmation ensures that sensitive information from process memory that might be placed in the paging file is not available to an unauthorized user who manages to directly access the paging file after shutdown.
-
Important information that is kept in real memory might be written periodically to the paging file. This helps devices handle multitasking functions. A malicious user who has physical access to a server that has been shut down can view the contents of the paging file. The attacker can move the system volume into a different computer and then analyze the contents of the paging file. This is a time-consuming process, but it can expose data that is cached from RAM to the paging file. A malicious user who has physical access to the server can bypass this countermeasure by simply unplugging the server from its power source.
-
### Possible values
-
- Enabled
-
The system paging file is cleared when the system shuts down normally. Also, this policy setting forces the computer to clear the hibernation file (hiberfil.sys) when hibernation is disabled on a portable device.
-
- Disabled
-
- Not defined
-
### Best practices
-
- Set this policy to **Enabled**. This causes Windows to clear the paging file when the system is shut down. Depending on the size of the paging file, this process might take several minutes before the system completely shuts down. This delay in shutting down the server is especially noticeable on servers with large paging files. For a server with 2 gigabytes (GB) of RAM and a 2-GB paging file, this setting can add more than 30 minutes to the shutdown process. For some organizations, this downtime violates their internal service level agreements. Use caution when implementing this countermeasure in your environment.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -84,50 +64,23 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a computer restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Important information that is kept in real memory may be written periodically to the paging file to help Windows handle multitasking functions. An attacker who has physical access to a server that has been shut down could view the contents of the paging file. The attacker could move the system volume into a different device and then analyze the contents of the paging file. Although this process is time consuming, it could expose data that is cached from random access memory (RAM) to the paging file.
-
**Caution**
An attacker who has physical access to the device could bypass this countermeasure by unplugging the computer from its power source.
-
-
### Countermeasure
-
Enable the **Shutdown: Clear virtual memory page file** setting. This configuration causes the operating system to clear the paging file when the device is shut down. The amount of time that is required to complete this process depends on the size of the page file. Because the process overwrites the storage area that is used by the page file several times, it could be several minutes before the device completely shuts down.
-
### Potential impact
-
It takes longer to shut down and restart the device, especially on devices with large paging files. For a device with 2 gigabytes (GB) of RAM and a 2-GB paging file, this policy setting could increase the shutdown process by more than 30 minutes. For some organizations this downtime violates their internal service level agreements. Therefore, use caution before you implement this countermeasure in your environment.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/store-passwords-using-reversible-encryption.md b/windows/keep-secure/store-passwords-using-reversible-encryption.md
index 57c859368c..1d0ae2465b 100644
--- a/windows/keep-secure/store-passwords-using-reversible-encryption.md
+++ b/windows/keep-secure/store-passwords-using-reversible-encryption.md
@@ -2,53 +2,32 @@
title: Store passwords using reversible encryption (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Store passwords using reversible encryption security policy setting.
ms.assetid: 57f958c2-f1e9-48bf-871b-0a9b3299e238
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Store passwords using reversible encryption
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **Store passwords using reversible encryption** security policy setting.
-
## Reference
-
-
The **Store password using reversible encryption** policy setting provides support for applications that use protocols that require the user's password for authentication. Storing encrypted passwords in a way that is reversible means that the encrypted passwords can be decrypted. A knowledgeable attacker who is able to break this encryption can then log on to network resources by using the compromised account. For this reason, never enable **Store password using reversible encryption** for all users in the domain unless application requirements outweigh the need to protect password information.
-
If you use the Challenge Handshake Authentication Protocol (CHAP) through remote access or Internet Authentication Services (IAS), you must enable this policy setting. CHAP is an authentication protocol that is used by remote access and network connections. Digest Authentication in Internet Information Services (IIS) also requires that you enable this policy setting.
-
### Possible values
-
- Enabled
-
- Disabled
-
- Not defined
-
### Best practices
-
Set the value for **Store password using reversible encryption** to Disabled. If you use CHAP through remote access or IAS, or Digest Authentication in IIS, you must set this value to **Enabled**. This presents a security risk when you apply the setting by using Group Policy on a user-by-user basis because it requires opening the appropriate user account object in Active Directory Users and Computers.
-
**Note**
Do not enable this policy setting unless business requirements outweigh the need to protect password information.
-
-
### Location
-
**Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Password Policy\\**
-
### Default values
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -87,36 +66,16 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Enabling this policy setting allows the operating system to store passwords in a format that can weaken your overall security.
-
### Countermeasure
-
Disable the **Store password using reversible encryption** policy setting.
-
### Potential impact
-
If your organization uses CHAP through remote access or IAS, or Digest Authentication in IIS, you must configure this policy setting to Enabled. This presents a security risk when you apply the setting through Group Policy on a user-by-user basis because it requires the appropriate user account object to be opened in Active Directory Users and Computers.
-
## Related topics
-
-
[Password Policy](password-policy.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/switch-pcr-banks-on-tpm-2-0-devices.md b/windows/keep-secure/switch-pcr-banks-on-tpm-2-0-devices.md
index 3da96de40b..ea019eb343 100644
--- a/windows/keep-secure/switch-pcr-banks-on-tpm-2-0-devices.md
+++ b/windows/keep-secure/switch-pcr-banks-on-tpm-2-0-devices.md
@@ -5,20 +5,17 @@ ms.assetid: 743FCCCB-99A9-4636-8F48-9ECB3A3D10DE
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# Switch PCR banks on TPM 2.0 devices
-
-
**Applies to**
-
- Windows 10
A Platform Configuration Register (PCR) is a memory location in the TPM that has some unique properties. The size of the value that can be stored in a PCR is determined by the size of a digest generated by an associated hashing algorithm. A SHA-1 PCR can store 20 bytes – the size of a SHA-1 digest. Multiple PCRs associated with the same hashing algorithm are referred to as a PCR bank.
To store a new value in a PCR, the existing value is extended with a new value as follows:
-
PCR\[N\] = HASHalg( PCR\[N\] || ArgumentOfExtend )
The existing value is concatenated with the argument of the TPM Extend operation. The resulting concatenation is then used as input to the associated hashing algorithm, which computes a digest of the input. This computed digest becomes the new value of the PCR.
@@ -29,28 +26,17 @@ Some TPM PCRs are used as checksums of log events. The log events are extended i
## How does Windows 10 use PCRs?
-
To bind the use of a TPM based key to a certain state of the PC, the key can be sealed to an expected set of PCR values. For instance, PCRs 0 through 7 have a well-defined value after the boot process – when the OS is loaded. When the hardware, firmware, or boot loader of the machine changes, the change can be detected in the PCR values. Windows 10 uses this capability to make certain cryptographic keys only available at certain times during the boot process. For instance, the BitLocker key can be used at a certain point in the boot, but not before or after.
-It is important to note that this binding to PCR values also includes the hashing algorithm used for the PCR. For instance, a key can be bound to a specific value of the SHA-1 PCR\[12\], if using SHA-256 PCR banks, even with the same system configuration otherwise, the PCR values will not match.
+It is important to note that this binding to PCR values also includes the hashing algorithm used for the PCR. For instance, a key can be bound to a specific value of the SHA-1 PCR\[12\], if using SHA-256 PCR banks, even with the
+same system configuration otherwise, the PCR values will not match.
## What happens when PCR banks are switched?
-
When the PCR banks are switched, the algorithm used to compute the hashed values stored in the PCRs during extend operations is changed. For the same input, each hash algorithm will return a different cryptographic signature for the same inputs.
As a result, if the currently used PCR bank is switched all keys that have been bound to the previous PCR values will no longer work. For example, if you had a key bound to the SHA-1 value of PCR\[12\] and subsequently changed the PCR banks to SHA-256, the banks wouldn’t match, and you would be unable to use that key. The BitLocker key is secured using the PCR banks and Windows 10 will not be able to unseal it if the PCR banks are switched while BitLocker is enabled.
## What can I do to switch PCRs when BitLocker is already active?
-
Before switching PCR banks you should suspend or disable BitLocker – or have your recovery key ready. For steps on how to switch PCR banks on your PC, you should contact your OEM or UEFI vendor.
-
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/synchronize-directory-service-data.md b/windows/keep-secure/synchronize-directory-service-data.md
index f27a3177b6..4554452349 100644
--- a/windows/keep-secure/synchronize-directory-service-data.md
+++ b/windows/keep-secure/synchronize-directory-service-data.md
@@ -2,48 +2,29 @@
title: Synchronize directory service data (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Synchronize directory service data security policy setting.
ms.assetid: 97b0aaa4-674f-40f4-8974-b4bfb12c232c
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Synchronize directory service data
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Synchronize directory service data** security policy setting.
-
## Reference
-
-
This policy setting determines which users and groups have authority to synchronize all directory service data, regardless of the protection for objects and properties. This privilege is required to use LDAP directory synchronization (dirsync) services. Domain controllers have this user right inherently because the synchronization process runs in the context of the **System** account on domain controllers.
-
Constant: SeSyncAgentPrivilege
-
### Possible values
-
- User-defined list of accounts
-
- Not defined
-
### Best practices
-
- Ensure that no accounts are assigned the **Synchronize directory service data** user right. Only domain controllers need this privilege, which they inherently have.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
By default this setting is not defined on domain controllers and on stand-alone servers.
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -82,59 +63,27 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
A restart of the device is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
### Group Policy
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
The **Synchronize directory service data** user right affects domain controllers (only domain controllers should be able to synchronize directory service data). Domain controllers have this user right inherently because the synchronization process runs in the context of the **System** account on domain controllers. Attackers who have this user right can view all information that is stored within the directory. They could then use some of that information to facilitate additional attacks or expose sensitive data, such as direct telephone numbers or physical addresses.
-
### Countermeasure
-
Ensure that no accounts are assigned the **Synchronize directory service data** user right.
-
### Potential impact
-
None. Not defined is the default configuration.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/system-cryptography-force-strong-key-protection-for-user-keys-stored-on-the-computer.md b/windows/keep-secure/system-cryptography-force-strong-key-protection-for-user-keys-stored-on-the-computer.md
index ccdb41c94f..811570c873 100644
--- a/windows/keep-secure/system-cryptography-force-strong-key-protection-for-user-keys-stored-on-the-computer.md
+++ b/windows/keep-secure/system-cryptography-force-strong-key-protection-for-user-keys-stored-on-the-computer.md
@@ -2,50 +2,30 @@
title: System cryptography Force strong key protection for user keys stored on the computer (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the System cryptography Force strong key protection for user keys stored on the computer security policy setting.
ms.assetid: 8cbff267-881e-4bf6-920d-b583a5ff7de0
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# System cryptography: Force strong key protection for user keys stored on the computer
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **System cryptography: Force strong key protection for user keys stored on the computer** security policy setting.
-
## Reference
-
-
This policy setting determines whether users can use private keys, such as their Secure/Multipurpose Internet Mail Extensions (S/MIME) key, without a password.
-
Configuring this policy setting so that users must provide a password every time they use a key (in addition to their domain password) makes it more difficult for a malicious user to access locally-stored user keys, even if the attacker takes control of the user's device and determines their logon password.
-
### Possible values
-
- **User input is not required when new keys are stored and used**
-
- **User is prompted when the key is first used**
-
- **User must enter a password each time they use a key**
-
- Not defined
-
### Best practices
-
- Set this policy to **User must enter a password each time they use a key**. Users must enter their password every time they access a key that is stored on their computer. For example, if users use an S/MIME certificate to digitally sign their email, they will be forced to enter the password for that certificate every time they send a signed email message. For some organizations, the overhead that is caused by using this value might be too high, but they should set the value at a minimum to **User is prompted when the key is first used**.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -84,45 +64,20 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
If a user's account is compromised or the user's device is inadvertently left unsecured, the malicious user can use the keys that are stored for the user to access protected resources.
-
### Countermeasure
-
Configure the **System cryptography: Force strong key protection for user keys stored on the computer** setting to **User must enter a password each time they use a key** so that users must provide a password that is distinct from their domain password every time they use a key. This configuration makes it more difficult for an attacker to access locally stored user keys, even if the attacker takes control of the user's computer and determines the logon password.
-
### Potential impact
-
Users must type their password every time they access a key that is stored on their device. For example, if users use an S/MIME certificate to digitally sign their email, they are forced to type the password for that certificate every time they send a signed email message. For some organizations, the overhead that is involved by using this configuration may be too high. At a minimum, this setting should be set to **User is prompted when the key is first used**.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/system-cryptography-use-fips-compliant-algorithms-for-encryption-hashing-and-signing.md b/windows/keep-secure/system-cryptography-use-fips-compliant-algorithms-for-encryption-hashing-and-signing.md
index 8c2c61ba3e..b762727564 100644
--- a/windows/keep-secure/system-cryptography-use-fips-compliant-algorithms-for-encryption-hashing-and-signing.md
+++ b/windows/keep-secure/system-cryptography-use-fips-compliant-algorithms-for-encryption-hashing-and-signing.md
@@ -2,64 +2,37 @@
title: System cryptography Use FIPS compliant algorithms for encryption, hashing, and signing (Windows 10)
description: This security policy reference topic for the IT professional describes the best practices, location, values, policy management and security considerations for this policy setting.
ms.assetid: 83988865-dc0f-45eb-90d1-ee33495eb045
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing
-
-
**Applies to**
-
- Windows 10
-
This security policy reference topic for the IT professional describes the best practices, location, values, policy management and security considerations for this policy setting.
-
## Reference
-
-
The Federal Information Processing Standard (FIPS) 140 is a security implementation that is designed for certifying cryptographic software. Windows implements these certified algorithms to meet the requirements and standards for cryptographic modules for use by departments and agencies of the United States federal government.
-
**TLS/SSL**
-
This policy setting determines whether the TLS/SSL security provider supports only the FIPS-compliant strong cipher suite known as TLS\_RSA\_WITH\_3DES\_EDE\_CBC\_SHA, which means that the provider only supports the TLS protocol as a client computer and as a server, if applicable. It uses only the Triple Data Encryption Standard (3DES) encryption algorithm for the TLS traffic encryption, only the Rivest-Shamir-Adleman (RSA) public key algorithm for the TLS key exchange and authentication, and only the Secure Hash Algorithm version 1 (SHA-1) hashing algorithm for the TLS hashing requirements.
-
**Encrypting File System (EFS)**
-
For the EFS service, this policy setting supports the 3DES and Advanced Encryption Standard (AES) encryption algorithms for encrypting file data supported by the NTFS file system. To encrypt file data, by default EFS uses the Advanced Encryption Standard (AES) algorithm with a 256-bit key in the Windows Server 2003, Windows Vista, and later, and it uses a DESX algorithm in Windows XP.
-
**Remote Desktop Services (RDS)**
-
For encrypting Remote Desktop Services network communication, this policy setting supports only the Triple DES encryption algorithm.
-
**BitLocker**
-
For BitLocker, this policy setting needs to be enabled before any encryption key is generated.
-
Recovery passwords created on Windows Server 2012 R2 and Windows 8.1 and later when this policy is enabled are incompatible with BitLocker on operating systems prior to Windows Server 2012 R2 and Windows 8.1; BitLocker will prevent the creation or use of recovery passwords on these systems, so recovery keys should be used instead.
-
### Possible values
-
- Enabled
-
- Disabled
-
- Not defined
-
### Best practices
-
- For use with TLS, set this policy to **Enabled**. Client devices with this policy setting enabled will be unable to communicate through digitally encrypted or signed protocols with servers that do not support these algorithms. Client devices that are connected to the network and do not support these algorithms cannot use servers that require the algorithms for network communications. If you enable this policy setting, you must also configure Internet Explorer to use TLS.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -98,15 +71,10 @@ The following table lists the actual and effective default values for this polic
-
-
### Operating system version differences
-
When this setting is enabled, the Encrypting File System (EFS) service supports only the Triple DES encryption algorithm for encrypting file data. By default, the Windows Vista and the Windows Server 2003 implementation of EFS uses the Advanced Encryption Standard (AES) with a 256-bit key. The Windows XP implementation uses DESX.
-
When this setting is enabled, BitLocker generates recovery password or recovery keys applicable to versions listed in the following:
-
@@ -137,49 +105,22 @@ When this setting is enabled, BitLocker generates recovery password or recovery
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Group Policy
-
Setting and deploying this policy using Group Policy takes precedence over the setting on the local device. If the Group Policy is set to **Not Configured**, local settings will apply.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
You can enable this policy setting to ensure that the device uses the most powerful algorithms that are available for digital encryption, hashing, and signing. Use of these algorithms minimize the risk of compromise of digitally encrypted or signed data by an unauthorized user.
-
### Countermeasure
-
Enable the **System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing** setting.
-
### Potential impact
-
Client devices that have this policy setting enabled cannot communicate by means of digitally encrypted or signed protocols with servers that do not support these algorithms. Network clients that do not support these algorithms cannot use servers that require them for network communications. For example, many Apache-based Web servers are not configured to support TLS. If you enable this setting, you must also configure Internet Explorer® to use TLS. This policy setting also affects the encryption level that is used for the Remote Desktop Protocol (RDP). The Remote Desktop Connection tool uses the RDP protocol to communicate with servers that run Terminal Services and client computers that are configured for remote control; RDP connections fail if both devices are not configured to use the same encryption algorithms.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/system-objects-require-case-insensitivity-for-non-windows-subsystems.md b/windows/keep-secure/system-objects-require-case-insensitivity-for-non-windows-subsystems.md
index d26e95bbce..ed8f8e7cdb 100644
--- a/windows/keep-secure/system-objects-require-case-insensitivity-for-non-windows-subsystems.md
+++ b/windows/keep-secure/system-objects-require-case-insensitivity-for-non-windows-subsystems.md
@@ -2,52 +2,31 @@
title: System objects Require case insensitivity for non-Windows subsystems (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the System objects Require case insensitivity for non-Windows subsystems security policy setting.
ms.assetid: 340d6769-8f33-4067-8470-1458978d1522
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# System objects: Require case insensitivity for non-Windows subsystems
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **System objects: Require case insensitivity for non-Windows subsystems** security policy setting.
-
## Reference
-
-
This policy setting determines whether case insensitivity is enforced for all subsystems. The Microsoft Win32 subsystem is not case sensitive; however, the kernel supports case sensitivity for other subsystems, such as Portable Operating System Interface for UNIX (POSIX). Enabling this policy setting enforces case insensitivity for all directory objects, symbolic links, and input/output (I/O) objects, including file objects. Disabling this policy setting does not allow the Win32 subsystem to become case sensitive.
-
Because Windows is case insensitive but the POSIX subsystem will support case sensitivity, if this policy setting is not enforced, it is possible for a user of that subsystem to create a file with the same name as another file but with a different mix of capital letters. That might confuse users when they try to access these files by using normal Win32 tools, because only one of the files will be available.
-
### Possible values
-
- Enabled
-
Case insensitivity is enforced for all directory objects, symbolic links, and IO objects, including file objects.
-
- Disabled
-
Will not allow the Win32 subsystem to become case sensitive.
-
- Not defined
-
### Best practices
-
- Set this policy to **Enabled**. All subsystems will be forced to observe case insensitivity. However, this might confuse users who are familiar with one of the UNIX-based operating systems and are used to a case sensitive operating system.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -86,45 +65,20 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Because Windows is case insensitive but the POSIX subsystem supports case sensitivity, failure to enable this policy setting makes it possible for a user of that subsystem to create a file with the same name as another file but with a different mix of uppercase and lowercase letters. Such a situation could potentially confuse users when they try to access such files from normal Win32 tools because only one of the files is available.
-
### Countermeasure
-
Enable the **System objects: Require case insensitivity for non-Windows subsystems** setting.
-
### Potential impact
-
All subsystems are forced to observe case insensitivity. This configuration may confuse users who are familiar with any UNIX-based operating systems that are case sensitive.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/system-objects-strengthen-default-permissions-of-internal-system-objects.md b/windows/keep-secure/system-objects-strengthen-default-permissions-of-internal-system-objects.md
index 3927b70a25..1aee1c46fa 100644
--- a/windows/keep-secure/system-objects-strengthen-default-permissions-of-internal-system-objects.md
+++ b/windows/keep-secure/system-objects-strengthen-default-permissions-of-internal-system-objects.md
@@ -2,46 +2,28 @@
title: System objects Strengthen default permissions of internal system objects (e.g. Symbolic Links) (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the System objects Strengthen default permissions of internal system objects (e.g. Symbolic Links) security policy setting.
ms.assetid: 3a592097-9cf5-4fd0-a504-7cbfab050bb6
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# System objects: Strengthen default permissions of internal system objects (e.g. Symbolic Links)
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **System objects: Strengthen default permissions of internal system objects (e.g. Symbolic Links)** security policy setting.
-
## Reference
-
-
This policy setting determines the strength of the default discretionary access control list (DACL) for objects. Windows maintains a global list of shared system resources such as MS-DOS device names, mutexes, and semaphores. By using this list, processes can locate and share objects. Each type of object is created with a default DACL that specifies who can access the objects with what permissions. Enabling this policy setting strengthens the default DACL and allows users who are not administrators to read, but not to modify, shared objects that they did not create.
-
### Possible values
-
- Enabled
-
- Disabled
-
- Not defined
-
### Best practices
-
- It is advisable to set this policy to **Enabled**.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\ Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -80,45 +62,20 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
This policy setting is enabled by default to protect against a known vulnerability that can be used with hard links or symbolic links. Hard links are actual directory entries in the file system. With hard links, the same data in a file system can be referred to by different file names. Symbolic links are text files that provide a pointer to the file that is interpreted and followed by the operating system as a path to another file or directory. Because symbolic links are a separate file, they can exist independently of the target location. If a symbolic link is deleted, its target location remains unaffected. When this setting is disabled, it is possible for a malicious user to destroy a data file by creating a link that looks like a temporary file that the system automatically creates, such as a sequentially named log file, but it points to the data file that the malicious user wants to eradicate. When the system writes the files with that name, the data is overwritten. Enabling **System objects: Strengthen default permissions of internal system objects (e.g., Symbolic Links)** prevents an attacker from exploiting programs that create files with predictable names by not allowing them to write to objects that they did not create.
-
### Countermeasure
-
Enable the **System objects: Strengthen default permissions of global system objects (for example, Symbolic Links)** setting.
-
### Potential impact
-
None. This is the default configuration.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/system-settings-optional-subsystems.md b/windows/keep-secure/system-settings-optional-subsystems.md
index 6dc7df6ae0..96633aece6 100644
--- a/windows/keep-secure/system-settings-optional-subsystems.md
+++ b/windows/keep-secure/system-settings-optional-subsystems.md
@@ -2,46 +2,28 @@
title: System settings Optional subsystems (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the System settings Optional subsystems security policy setting.
ms.assetid: 5cb6519a-4f84-4b45-8072-e2aa8a72fb78
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# System settings: Optional subsystems
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **System settings: Optional subsystems** security policy setting.
-
## Reference
-
-
This policy setting determines which subsystems support your applications. You can use this security setting to specify as many subsystems as your environment demands.
-
The subsystem introduces a security risk that is related to processes that can potentially persist across logons. If a user starts a process and then logs out, the next user who logs on to the system might access the process that the previous user started. This is dangerous, because the process started by the first user can retain that user's system user rights; therefore, anything that the second user does using that process is performed with the user rights of the first user. This makes it difficult to trace who creates processes and objects, which is essential for post-security incident forensics.
-
### Possible values
-
- User-defined list of subsystems
-
- Not defined
-
### Best practices
-
- Set this policy setting to a null value. The default value is **POSIX**, so applications that rely on the POSIX subsystem will no longer run. For example, Microsoft Services for UNIX 3.0 installs an updated version of the POSIX subsystem. Reset this policy setting in Group Policy for any servers that use Services for UNIX 3.0.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -80,47 +62,21 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
The POSIX subsystem is an Institute of Electrical and Electronic Engineers (IEEE) standard that defines a set of operating system services. The POSIX subsystem is required if the server supports applications that use that subsystem.
-
The POSIX subsystem introduces a security risk that relates to processes that can potentially persist across logons. If a user starts a process and then logs out, there is a potential that the next user who logs on to the computer could access the previous user's process. This would allow the second user to take actions on the process by using the privileges of the first user.
-
### Countermeasure
-
Configure the **System settings: Optional subsystems setting** to a null value. The default value is POSIX.
-
### Potential impact
-
Applications that rely on the POSIX subsystem no longer operate. For example, Microsoft Services for UNIX (SFU) installs an updated version of the POSIX subsystem that is required, so you must reconfigure this setting in Group Policy for any servers that use SFU.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/system-settings-use-certificate-rules-on-windows-executables-for-software-restriction-policies.md b/windows/keep-secure/system-settings-use-certificate-rules-on-windows-executables-for-software-restriction-policies.md
index 278033dbc8..ce05d099f5 100644
--- a/windows/keep-secure/system-settings-use-certificate-rules-on-windows-executables-for-software-restriction-policies.md
+++ b/windows/keep-secure/system-settings-use-certificate-rules-on-windows-executables-for-software-restriction-policies.md
@@ -2,46 +2,28 @@
title: System settings Use certificate rules on Windows executables for Software Restriction Policies (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the System settings Use certificate rules on Windows executables for Software Restriction Policies security policy setting.
ms.assetid: 2380d93b-b553-4e56-a0c0-d1ef740d089c
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# System settings: Use certificate rules on Windows executables for Software Restriction Policies
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **System settings: Use certificate rules on Windows executables for Software Restriction Policies** security policy setting.
-
## Reference
-
-
This policy setting determines whether digital certificates are processed when software restriction policies are enabled and a user or process attempts to run software with an .exe file name extension. This security setting enables or disables certificate rules (which are a type of software restriction policy). With a software restriction policy, you can create a certificate rule that allows or disallows Microsoft Authenticode®-signed software to run, based on the digital certificate that is associated with the software. For certificate rules to work in software restriction policies, you must enable this security setting.
-
### Possible values
-
- Enabled
-
- Disabled
-
- Not defined
-
### Best practices
-
- Set this policy to **Enabled**. Enabling certificate rules results in software restriction policies checking a certificate revocation list (CRL) to make sure that the software's certificate and signature are valid. When you start signed programs, this setting can decrease system performance. You can disable CRLs by editing the software restriction policies in the desired GPO. In the **Trusted Publishers Properties** dialog box, clear the **Publisher** and **Timestamp** check boxes.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -80,45 +62,20 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Without the use of software restriction policies, users and device might be exposed to unauthorized software that could include malware.
-
### Countermeasure
-
Enable the **System settings: Use certificate rules on Windows executables for Software Restriction Policies** setting.
-
### Potential impact
-
If you enable certificate rules, software restriction policies check a certificate revocation list (CRL) to verify that the software's certificate and signature are valid. This checking process may negatively affect performance when signed programs start. To disable this feature, you can edit the software restriction policies in the appropriate GPO. In the **Trusted Publishers Properties** dialog box, clear the **Publisher** and **Timestamp** check boxes.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/take-ownership-of-files-or-other-objects.md b/windows/keep-secure/take-ownership-of-files-or-other-objects.md
index 6ec1df5665..5274e1f278 100644
--- a/windows/keep-secure/take-ownership-of-files-or-other-objects.md
+++ b/windows/keep-secure/take-ownership-of-files-or-other-objects.md
@@ -2,52 +2,31 @@
title: Take ownership of files or other objects (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Take ownership of files or other objects security policy setting.
ms.assetid: cb8595d1-74cc-4176-bb15-d97663eebb2d
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Take ownership of files or other objects
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management, and security considerations for the **Take ownership of files or other objects** security policy setting.
-
## Reference
-
-
This policy setting determines which users can take ownership of any securable object in the device, including Active Directory objects, NTFS files and folders, printers, registry keys, services, processes, and threads.
-
Every object has an owner, whether the object resides in an NTFS volume or Active Directory database. The owner controls how permissions are set on the object and to whom permissions are granted.
-
By default, the owner is the person who or the process which created the object. Owners can always change permissions to objects, even when they are denied all access to the object.
-
Constant: SeTakeOwnershipPrivilege
-
### Possible values
-
- User-defined list of accounts
-
- Not defined
-
### Best practices
-
- Assigning this user right can be a security risk. Because owners of objects have full control of them, only assign this user right to trusted users.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
-
### Default values
-
By default this setting is Administrators on domain controllers and on stand-alone servers.
-
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
-
@@ -86,75 +65,35 @@ The following table lists the actual and effective default policy values. Defaul
-
-
## Policy management
-
-
This section describes features, tools, and guidance to help you manage this policy.
-
A restart of the device is not required for this policy setting to be effective.
-
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
-
Ownership can be taken by:
-
- An administrator. By default, the Administrators group is given the **Take ownership of files or other objects** user right.
-
- Anyone or any group who has the **Take ownership** user right on the object.
-
- A user who has the **Restore files and directories** user right.
-
Ownership can be transferred in the following ways:
-
- The current owner can grant the **Take ownership** user right to another user if that user is a member of a group defined in the current owner's access token. The user must take ownership to complete the transfer.
-
- An administrator can take ownership.
-
- A user who has the **Restore files and directories** user right can double-click **Other users and groups** and choose any user or group to assign ownership to.
-
### Group Policy
-
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
-
1. Local policy settings
-
2. Site policy settings
-
3. Domain policy settings
-
4. OU policy settings
-
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Any users with the **Take ownership of files or other objects user right** can take control of any object, regardless of the permissions on that object, and then make any changes that they want to make to that object. Such changes could result in exposure of data, corruption of data, or a denial-of-service condition.
-
### Countermeasure
-
Ensure that only the local Administrators group has the **Take ownership of files or other objects** user right.
-
### Potential impact
-
None. Restricting the **Take ownership of files or other objects** user right to the local Administrators group is the default configuration.
-
## Related topics
-
-
[User Rights Assignment](user-rights-assignment.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/test-an-applocker-policy-by-using-test-applockerpolicy.md b/windows/keep-secure/test-an-applocker-policy-by-using-test-applockerpolicy.md
index 288b71b44d..09ccf98b7d 100644
--- a/windows/keep-secure/test-an-applocker-policy-by-using-test-applockerpolicy.md
+++ b/windows/keep-secure/test-an-applocker-policy-by-using-test-applockerpolicy.md
@@ -2,52 +2,28 @@
title: Test an AppLocker policy by using Test-AppLockerPolicy (Windows 10)
description: This topic for IT professionals describes the steps to test an AppLocker policy prior to importing it into a Group Policy Object (GPO) or another computer.
ms.assetid: 048bfa38-6825-4a9a-ab20-776cf79f402a
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Test an AppLocker policy by using Test-AppLockerPolicy
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals describes the steps to test an AppLocker policy prior to importing it into a Group Policy Object (GPO) or another computer.
-
The **Test-AppLockerPolicy** Windows PowerShell cmdlet can be used to determine whether any of the rules in your rule collections will be blocked on your reference computer or the computer on which you maintain policies. Perform the following steps on any computer where the AppLocker policies are applied.
-
Any user account can be used to complete this procedure.
-
**To test an AppLocker policy by using Test-AppLockerPolicy**
-
1. Export the effective AppLocker policy. To do this, you must use the **Get-AppLockerPolicy** Windows PowerShell cmdlet.
-
1. Open a Windows PowerShell command prompt window as an administrator.
-
2. Use the **Get-AppLockerPolicy** cmdlet to export the effective AppLocker policy to an XML file:
-
`Get-AppLockerPolicy –Effective –XML > `
-
2. Use the **Get-ChildItem** cmdlet to specify the directory that you want to test, specify the **Test-AppLockerPolicy** cmdlet with the XML file from the previous step to test the policy, and use the **Export-CSV** cmdlet to export the results to a file to be analyzed:
-
`Get-ChildItem -Filter -Recurse | Convert-Path | Test-AppLockerPolicy –XMLPolicy -User -Filter | Export-CSV `
-
The following shows example input for **Test-AppLockerPolicy**:
-
`PS C:\ Get-AppLockerPolicy –Effective –XML > C:\Effective.xml`
-
`PS C:\ Get-ChildItem 'C:\Program Files\Microsoft Office\' –filter *.exe –Recurse | Convert-Path | Test-AppLockerPolicy –XMLPolicy C:\Effective.xml –User contoso\zwie –Filter Denied,DeniedByDefault | Export-CSV C:\BlockedFiles.csv`
-
In the example, the effective AppLocker policy is exported to the file C:\\Effective.xml. The **Get-ChildItem** cmdlet is used to recursively gather path names for the .exe files in C:\\Program Files\\Microsoft Office\\. The XMLPolicy parameter specifies that the C:\\Effective.xml file is an XML AppLocker policy file. By specifying the User parameter, you can test the rules for specific users, and the **Export-CSV** cmdlet allows the results to be exported to a comma-separated file. In the example, `-FilterDenied,DeniedByDefault` displays only those files that will be blocked for the user under the policy.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/test-and-update-an-applocker-policy.md b/windows/keep-secure/test-and-update-an-applocker-policy.md
index 5157667a41..4ae1a87af2 100644
--- a/windows/keep-secure/test-and-update-an-applocker-policy.md
+++ b/windows/keep-secure/test-and-update-an-applocker-policy.md
@@ -2,77 +2,37 @@
title: Test and update an AppLocker policy (Windows 10)
description: This topic discusses the steps required to test an AppLocker policy prior to deployment.
ms.assetid: 7d53cbef-078c-4d20-8b00-e821e33b6ea1
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Test and update an AppLocker policy
-
-
**Applies to**
-
- Windows 10
-
This topic discusses the steps required to test an AppLocker policy prior to deployment.
-
You should test each set of rules to ensure that the rules perform as intended. If you use Group Policy to manage AppLocker policies, complete the following steps for each Group Policy Object (GPO) where you have created AppLocker rules. Because AppLocker rules are inherited from linked GPOs, you should deploy all of the rules for simultaneous testing in all of your test GPOs.
-
## Step 1: Enable the Audit only enforcement setting
-
-
By using the **Audit only** enforcement setting, you can ensure that the AppLocker rules that you have created are properly configured for your organization. This setting can be enabled on the **Enforcement** tab of the **AppLocker Properties** dialog box. For the procedure to do this, see [Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md).
-
## Step 2: Configure the Application Identity service to start automatically
-
-
Because AppLocker uses the Application Identity service to verify the attributes of a file, you must configure it to start automatically in any one GPO that applies AppLocker rules. For the procedure to do this, see [Configure the Application Identity Service](configure-the-application-identity-service.md). For AppLocker policies that are not managed by a GPO, you must ensure that the service is running on each PC in order for the policies to be applied.
-
## Step 3: Test the policy
-
-
Test the AppLocker policy to determine if your rule collection needs to be modified. Because you have created AppLocker rules, enabled the Application Identity service, and enabled the **Audit only** enforcement setting, the AppLocker policy should be present on all client PC that are configured to receive your AppLocker policy.
-
The **Test-AppLockerPolicy** Windows PowerShell cmdlet can be used to determine whether any of the rules in your rule collection will be blocked on your reference PCs. For the procedure to do this, see [Test an AppLocker policy by using Test-AppLockerPolicy](test-an-applocker-policy-by-using-test-applockerpolicy.md).
-
## Step 4: Analyze AppLocker events
-
-
You can either manually analyze AppLocker events or use the **Get-AppLockerFileInformation** Windows PowerShell cmdlet to automate the analysis.
-
**To manually analyze AppLocker events**
-
You can view the events either in Event Viewer or a text editor and then sort those events to perform an analysis, such as looking for patterns in application usage events, access frequencies, or access by user groups. If you have not configured an event subscription, then you will have to review the logs on a sampling of computers in your organization. For more information about using Event Viewer, see [Monitor application usage with AppLocker](monitor-application-usage-with-applocker.md).
-
**To analyze AppLocker events by using Get-AppLockerFileInformation**
-
You can use the **Get-AppLockerFileInformation** Windows PowerShell cmdlet to analyze AppLocker events from a remote computer. If an app is being blocked and should be allowed, you can use the AppLocker cmdlets to help troubleshoot the problem.
-
For both event subscriptions and local events, you can use the **Get-AppLockerFileInformation** cmdlet to determine which files have been blocked or would have been blocked (if you are using the **Audit only** enforcement mode) and how many times the event has occurred for each file. For the procedure to do this, see [Monitor Application Usage with AppLocker](monitor-application-usage-with-applocker.md).
-
After using **Get-AppLockerFileInformation** to determine how many times that a file would have been blocked from running, you should review your rule list to determine whether a new rule should be created for the blocked file or whether an existing rule is too strictly defined. Ensure that you check which GPO is currently preventing the file from running. To determine this, you can use the Group Policy Results Wizard to view rule names.
-
## Step 5: Modify the AppLocker policy
-
-
After you have identified which rules need to be edited or added to the policy, you can use the Group Policy Management Console to modify the AppLocker rules in the relevant GPOs. For AppLocker policies that are not managed by a GPO, you can use the Local Security Policy snap-in (secpol.msc). For info how to modify an AppLocker policy, see, [Edit an AppLocker policy](edit-an-applocker-policy.md).
-
## Step 6: Repeat policy testing, analysis, and policy modification
-
-
Repeat the previous steps 3–5 until all the rules perform as intended before applying enforcement.
-
## Additional resources
-
-
- For steps to perform other AppLocker policy tasks, see [Administer AppLocker](administer-applocker.md).
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/tools-to-use-with-applocker.md b/windows/keep-secure/tools-to-use-with-applocker.md
index bef26fd57a..ed1080877e 100644
--- a/windows/keep-secure/tools-to-use-with-applocker.md
+++ b/windows/keep-secure/tools-to-use-with-applocker.md
@@ -2,63 +2,33 @@
title: Tools to use with AppLocker (Windows 10)
description: This topic for the IT professional describes the tools available to create and administer AppLocker policies.
ms.assetid: db2b7cb3-7643-4be5-84eb-46ba551e1ad1
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Tools to use with AppLocker
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional describes the tools available to create and administer AppLocker policies.
-
The following tools can help you administer the application control policies created by using AppLocker on the local device or by using Group Policy. For info about the basic requirements for using AppLocker, see [Requirements to use AppLocker](requirements-to-use-applocker.md).
-
- **AppLocker Local Security Policy MMC snap-in**
-
The AppLocker rules can be maintained by using the Local Security Policy snap-in (secpol.msc) of the Microsoft Management Console (MMC). For procedures to create, modify, and delete AppLocker rules, see [Working with AppLocker rules](working-with-applocker-rules.md).
-
- **Generate Default Rules tool**
-
AppLocker includes default rules for each rule collection accessed through the Local Security Policy snap-in. These rules are intended to help ensure that the files that are required for Windows to operate properly are allowed in an AppLocker rule collection. For info about how to use this tool, see [Create AppLocker default rules](create-applocker-default-rules.md).
-
- **Automatically Generate AppLocker Rules wizard**
-
By using the Local Security Policy snap-in, you can automatically generate rules for all files within a folder. The wizard will scan the specified folder and create the condition types that you choose for each file in that folder. For info about how to use this wizard, see [Run the Automatically Generate Rules wizard](run-the-automatically-generate-rules-wizard.md).
-
- **Group Policy**
-
You can edit an AppLocker policy by adding, changing, or removing rules by using the Group Policy Management Console (GPMC).
-
If you want additional features to manage AppLocker policies, such as version control, use Group Policy management software that allows you to create versions of Group Policy Objects (GPOs). An example of this type of software is the Advanced Group Policy Management feature from the Microsoft Desktop Optimization Pack.
-
- **Remote Server Administration Tools (RSAT)**
-
You can use a device with a supported operating system that has the Remote Server Administration Tools (RSAT) installed to create and maintain AppLocker policies.
-
- **Event Viewer**
-
The AppLocker log contains information about applications that are affected by AppLocker rules. For info about using Event Viewer to review the AppLocker logs, see [Using Event Viewer with AppLocker](using-event-viewer-with-applocker.md), and [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md).
-
- **AppLocker PowerShell cmdlets**
-
The AppLocker Windows PowerShell cmdlets are designed to streamline the administration of AppLocker policy. They can be used to help create, test, maintain, and troubleshoot an AppLocker policy. The cmdlets are intended to be used in conjunction with the AppLocker user interface that is accessed through the Local Security Policy snap-in and the GPMC. For information about the cmdlets, see the [AppLocker PowerShell Command Reference](http://technet.microsoft.com/library/hh847210.aspx).
-
## Related topics
-
-
[AppLocker technical reference](applocker-technical-reference.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/tpm-fundamentals.md b/windows/keep-secure/tpm-fundamentals.md
index 13e2bd4415..26e6b4403e 100644
--- a/windows/keep-secure/tpm-fundamentals.md
+++ b/windows/keep-secure/tpm-fundamentals.md
@@ -2,100 +2,53 @@
title: TPM fundamentals (Windows 10)
description: This topic for the IT professional provides a description of the components of the Trusted Platform Module (TPM 1.2 and TPM 2.0) and explains how they are used to mitigate dictionary attacks.
ms.assetid: ac90f5f9-9a15-4e87-b00d-4adcf2ec3000
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# TPM fundamentals
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional provides a description of the components of the Trusted Platform Module (TPM 1.2 and TPM 2.0) and explains how they are used to mitigate dictionary attacks.
-
A Trusted Platform Module (TPM) is a microchip designed to provide basic security-related functions, primarily involving encryption keys. The TPM is usually installed on the motherboard of a computer, and it communicates with the remainder of the system by using a hardware bus.
-
Computers that incorporate a TPM can create cryptographic keys and encrypt them so that they can only be decrypted by the TPM. This process, often called wrapping or binding a key, can help protect the key from disclosure. Each TPM has a master wrapping key, called the storage root key, which is stored within the TPM itself. The private portion of a storage root key or endorsement key that is created in a TPM is never exposed to any other component, software, process, or user.
-
You can specify whether encryption keys that are created by the TPM can be migrated or not. If you specify that they can be migrated, the public and private portions of the key can be exposed to other components, software, processes, or users. If you specify that encryption keys cannot be migrated, the private portion of the key is never exposed outside the TPM.
-
Computers that incorporate a TPM can also create a key that has not only been wrapped, but is also tied to certain platform measurements. This type of key can be unwrapped only when those platform measurements have the same values that they had when the key was created. This process is referred to as “sealing the key to the TPM.” Decrypting the key is called unsealing. The TPM can also seal and unseal data that is generated outside the TPM. With this sealed key and software, such as BitLocker Drive Encryption, you can lock data until specific hardware or software conditions are met.
-
With a TPM, private portions of key pairs are kept separate from the memory that is controlled by the operating system. Keys can be sealed to the TPM, and certain assurances about the state of a system (assurances that define the trustworthiness of a system) can be made before the keys are unsealed and released for use. Because the TPM uses its own internal firmware and logic circuits to process instructions, it does not rely on the operating system, and it is not exposed to vulnerabilities that might exist in the operating system or application software.
-
For info about which versions of Windows support which versions of the TPM, see [Trusted Platform Module technology overview](trusted-platform-module-overview.md). The features that are available in the versions are defined in specifications by the Trusted Computing Group (TCG). For more info, see the Trusted Platform Module page on the Trusted Computing Group website: [Trusted Platform Module](http://www.trustedcomputinggroup.org/developers/trusted_platform_module).
-
The following sections provide an overview of the technologies that support the TPM:
-
- [TPM-based Virtual Smart Card](#bkmk-vsc)
-
- [Measured Boot with support for attestation](#bkmk-measuredboot)
-
- [Automated provisioning and management of the TPM](#bkmk-autoprov)
-
- [TPM-based certificate storage](#bkmk-tpmcs)
-
- [Physical presence interface](#bkmk-physicalpresenceinterface)
-
- [TPM Cmdlets](#bkmk-tpmcmdlets)
-
- [TPM Owner Authorization Value](#bkmk-authvalue)
-
- [States of existence in a TPM](#bkmk-stateex)
-
- [Endorsement keys](#bkmk-endorsementkeys)
-
- [TPM Key Attestation](#bkmk-ketattestation)
-
- [How the TPM mitigates dictionary attacks](#bkmk-howtpmmitigates)
-
- [How do I check the state of my TPM?](#bkmk-checkstate)
-
- [What can I do if my TPM is in reduced functionality mode?](#bkmk-fixrfm)
-
The following topic describes the TPM Services that can be controlled centrally by using Group Policy settings:
-
[Trusted Platform Module Services Group Policy Settings](trusted-platform-module-services-group-policy-settings.md)
-
## Automated provisioning and management of the TPM
-
-
TPM provisioning can be streamlined to make it easier to deploy systems that are ready for BitLocker and other TPM-dependent features. These enhancements include simplifying the TPM state model to report **Ready**, **Ready with reduced functionality**, or **Not ready**. You can also automatically provision TPMs in the **Ready** state, remote provisioning to remove the requirement for the physical presence of a technician for the initial deployment. In addition, the TPM stack is available in the Windows Preinstallation Environment (Windows PE).
-
A number of management settings have been added for easier management and configuration of the TPM through Group Policy. The primary new settings include Active Directory-based backup of TPM owner authentication, the level of owner authentication that should be stored locally on the TPM, and the software-based TPM lockout settings for standard users. For more info about backing up owner authentication to Windows Server 2008 R2 AD DS domains, see [AD DS schema extensions to support TPM backup](ad-ds-schema-extensions-to-support-tpm-backup.md).
-
## Measured Boot with support for attestation
-
-
The Measured Boot feature provides antimalware software with a trusted (resistant to spoofing and tampering) log of all boot components. Antimalware software can use the log to determine whether components that ran before it are trustworthy versus infected with malware. It can also send the Measured Boot logs to a remote server for evaluation. The remote server can initiate remediation actions by interacting with software on the client or through out-of-band mechanisms, as appropriate.
-
## TPM-based Virtual Smart Card
-
-
The Virtual Smart Card emulates the functionality of traditional smart cards, but Virtual Smart Cards use the TPM chip that is available on an organization’s computers, rather than requiring the use of a separate physical smart card and reader. This greatly reduces the management and deployment cost of smart cards in an enterprise. To the end user, the Virtual Smart Card is always available on the computer. If a user needs to use more than one computer, a Virtual Smart Card must be issued to the user for each computer. A computer that is shared among multiple users can host multiple Virtual Smart Cards, one for each user.
-
## TPM-based certificate storage
-
-
The TPM can be used to protect certificates and RSA keys. The TPM key storage provider (KSP) provides easy, convenient use of the TPM as a way of strongly protecting private keys. The TPM KSP can be used to generate keys when an organization enrolls for certificates, and the KSP is managed by templates in the UI. The TPM can also be used to protect certificates that are imported from an outside source. TPM-based certificates can be used exactly as standard certificates with the added functionality that the certificate can never leave the TPM from which the keys were generated. The TPM can now be used for crypto-operations through Cryptography API: Next Generation (CNG). For more info, see [Cryptography API: Next Generation](http://msdn.microsoft.com/library/windows/desktop/aa376210.aspx).
-
## TPM Owner Authorization Value
-
-
For Windows 8 a change to how the TPM owner authorization value is stored in AD DS was implemented in the AD DS schema. The TPM owner authorization value is now stored in a separate object which is linked to the Computer object. This value was stored as a property in the Computer object itself for the default Windows Server 2008 R2 schemas. Windows Server 2012 domain controllers have the default schema to backup TPM owner authorization information in the separate object. If you are not upgrading your domain controller to Windows Server 2012 you need to extend the schema to support this change. If Active Directory backup of the TPM owner authorization value is enabled in a Windows Server 2008 R2 environment without extending the schema, the TPM provisioning will fail and the TPM will remain in a Not Ready state for computers running Windows 8.
-
If your computer is not being joined to a domain the TPM owner authorization value will be stored in the local computer registry. Using BitLocker to encrypt the operating system drive will protect the owner authorization value from being disclosed when the computer is at rest, but there is a risk that a malicious user could obtain the TPM owner authorization value when the computer is unlocked. Therefore, we recommend that in this situation you configure your computer to automatically lock after 30 seconds of inactivity. If automatic locking is not used, then you should consider removing full owner authorization from the computer registry.
-
**Registry information**
-
Registry key: HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Policies\\Microsoft\\TPM
-
DWORD: OSManagedAuthLevel
-
@@ -122,40 +75,23 @@ DWORD: OSManagedAuthLevel
-
-
**Note**
If the operating system managed TPM authentication setting is changed from "Full" to "Delegated" the full TPM owner authorization value will be regenerated and any copies of the original TPM owner authorization value will be invalid. If you are backing up the TPM owner authorization value to AD DS, the new owner authorization value will be automatically backed up to AD DS when it is changed.
-
-
## TPM Cmdlets
-
-
If you are using PowerShell to script and manage your computers, you can now manage the TPM using Windows PowerShell as well. To install the TPM cmdlets use the following command:
-
**dism /online /enable-feature /FeatureName:tpm-psh-cmdlets**
-
For details about the individual cmdlets, see [TPM Cmdlets in Windows PowerShell](http://technet.microsoft.com/library/jj603116.aspx)
-
## Physical presence interface
-
-
The TCG specifications for TPMs require physical presence to perform some TPM administrative functions, such as turning on and turning off the TPM. Physical presence means a person must physically interact with the system and the TPM interface to confirm or reject changes to TPM status. This typically cannot be automated with scripts or other automation tools unless the individual OEM supplies them. Here are some are examples of TPM administrative tasks that require physical presence:
-
- Activating the TPM
- Clearing the existing owner information from the TPM without the owner’s password
- Deactivating the TPM
- Disabling the TPM temporarily without the owner’s password
-
## States of existence in a TPM
-
-
For each of these TPM 1.2 states of existence, the TPM can transition into another state (for example, moving from disabled to enabled). The states are not exclusive.
-
These states of existence do not apply for Trusted Platform Module 2.0 because it cannot be turned off from within the operating system environment.
-
@@ -196,117 +132,56 @@ These states of existence do not apply for Trusted Platform Module 2.0 because
-
-
**Important**
Applications cannot use the TPM until the state is enabled, activated, and owned. All operations are available only when the TPM is in this state.
-
-
The state of the TPM exists independently of the computer’s operating system. When the TPM is enabled, activated, and owned, the state of the TPM is preserved if the operating system is reinstalled.
-
## Endorsement keys
-
-
For a TPM to be usable by a trusted application, it must contain an endorsement key, which is an RSA key pair. The private half of the key pair is held inside the TPM, and it is never revealed or accessible outside the TPM. If the TPM does not contain an endorsement key, the application might cause the TPM to generate one automatically as part of the setup.
-
An endorsement key can be created at various points in the TPM’s lifecycle, but it needs to be created only once for the lifetime of the TPM. The existence of an endorsement key is a requirement before TPM ownership can be taken.
-
## Key attestation
-
-
TPM key attestation allows a certification authority to verify that a private key is actually protected by a TPM and that the TPM is one that the certification authority trusts. Endorsement keys which have been proven valid can be used to bind the user identity to a device. Moreover, the user certificate with a TPM attested key provides higher security assurance backed up by the non-exportability, anti-hammering, and isolation of keys provided by a TPM.
-
## How the TPM mitigates dictionary attacks
-
-
When a TPM processes a command, it does so in a protected environment, for example, a dedicated microcontroller on a discrete chip or a special hardware-protected mode on the main CPU. A TPM can be used to create a cryptographic key that is not disclosed outside the TPM, but is able to be used in the TPM after the correct authorization value is provided.
-
TPMs have dictionary attack logic that is designed to prevent brute force attacks that attempt to determine authorization values for using a key. The basic approach is for the TPM to allow only a limited number of authorization failures before it prevents more attempts to use keys and locks. Providing a failure count for individual keys is not technically practical, so TPMs have a global lockout when too many authorization failures occur.
-
Because many entities can use the TPM, a single authorization success cannot reset the TPM’s dictionary attack logic. This prevents an attacker from creating a key with a known authorization value and then using it to reset the TPM’s dictionary attack logic. Generally TPMs are designed to forget about authorization failures after a period of time so the TPM does not enter a lockout state unnecessarily. A TPM owner password can be used to reset the TPM’s lockout logic.
-
### TPM 2.0 dictionary attack behavior
-
TPM 2.0 has well defined dictionary attack logic behavior. This is in contrast to TPM 1.2 for which the dictionary attack logic was set by the manufacturer, and the logic varied widely throughout the industry.
-
**Warning**
For the purposes of this topic, Windows 8 Certified Hardware also pertains to Windows 8.1 systems. The following references to “Windows” include these supported Windows versions.
-
-
For Windows 8 Certified Hardware systems with TPM 2.0, the TPM is configured by Windows to lock after 32 authorization failures and to forget one authorization failure every two hours. This means that a user could quickly attempt to use a key with the wrong authorization value 32 times. For each of the 32 attempts, the TPM records if the authorization value was correct or not. This inadvertently causes the TPM to enter a locked state after 32 failed attempts.
-
Attempts to use a key with an authorization value for the next two hours would not return success or failure; instead the response indicates that the TPM is locked. After two hours, one authorization failure is forgotten and the number of authorization failures remembered by the TPM drops to 31, so the TPM leaves the locked state and returns to normal operation. With the correct authorization value, keys could be used normally if no authorization failures occur during the next two hours. If a period of 64 hours elapses with no authorization failures, the TPM does not remember any authorization failures, and 32 failed attempts could occur again.
-
Windows 8 Certification does not require TPM 2.0 systems to forget about authorization failures when the system is fully powered off or when the system has hibernated. Windows does require that authorization failures are forgotten when the system is running normally, in a sleep mode, or in low power states other than off. If a Windows system with TPM 2.0 is locked, the TPM leaves lockout mode if the system is left on for two hours.
-
The dictionary attack logic for TPM 2.0 can be fully reset immediately by sending a reset lockout command to the TPM and providing the TPM owner password. By default, Windows automatically provisions TPM 2.0 and stores the TPM owner password for use by system administrators.
-
In some enterprise situations, the TPM owner authorization value is configured to be stored centrally in Active Directory, and it is not stored on the local system. An administrator can launch the TPM MMC and choose to reset the TPM lockout time. If the TPM owner password is stored locally, it is used to reset the lockout time. If the TPM owner password is not available on the local system, the administrator needs to provide it. If an administrator attempts to reset the TPM lockout state with the wrong TPM owner password, the TPM does not allow another attempt to reset the lockout state for 24 hours.
-
TPM 2.0 allows some keys to be created without an authorization value associated with them. These keys can be used when the TPM is locked. For example, BitLocker with a default TPM-only configuration is able to use a key in the TPM to start Windows, even when the TPM is locked.
-
### Rationale behind the Windows 8.1 and Windows 8 defaults
-
Windows relies on the TPM 2.0 dictionary attack protection for multiple features. The defaults that are selected for Windows 8 balance trade-offs for different scenarios.
-
For example, when BitLocker is used with a TPM plus PIN configuration, it needs the number of PIN guesses to be limited over time. If the computer is lost, someone could make only 32 PIN guesses immediately, and then only one more guess every two hours. This totals about 4415 guesses per year. This makes a good standard for system administrators to determine how many PIN characters to use for BitLocker deployments.
-
The Windows TPM-based smart card, which is a virtual smart card, can be configured to allow sign in to the system. In contrast with physical smart cards, the sign-in process uses a TPM-based key with an authorization value. The following list shows the advantages of virtual smart cards:
-
Physical smart cards can enforce lockout for only the physical smart card PIN, and they can reset the lockout after the correct PIN is entered. With a virtual smart card, the TPM’s dictionary attack is not reset after a successful authentication. The allowed number of authorization failures before the TPM enters lockout includes many factors.
-
Hardware manufacturers and software developers have the option to use the security features of the TPM to meet their requirements.
-
The intent of selecting 32 failures as the lock-out threshold is so users rarely lock the TPM (even when learning to type new passwords or if they frequently lock and unlock their computers). If users lock the TPM, they must to wait two hours or use some other credential to sign in, such as a user name and password.
-
## How do I check the state of my TPM?
-
-
You can check the state of the TPM on a PC by running the Trusted Platform Module snap-in (tpm.msc). The **Status** heading tells you the state of your TPM. The TPM can be in one of the following states: **Ready for use**, **Ready for use, with reduced functionality**, and **Not ready for use**. To take advantage of most of the TPM features in Windows 10, the TPM must be **Ready for use**.
-
## What can I do if my TPM is in reduced functionality mode?
-
-
If your TPM is in reduced functionality mode, some features that rely on the TPM will not function correctly. This is most often caused by doing a clean installation of Windows 10 on a device where Windows 8.1, Windows 8, or Windows 7 had previously been installed on the same hardware. If your TPM is in reduced functionality mode, the Status heading in the Trusted Platform Module snap-in shows **The TPM is ready for use, with reduced functionality**. You can fix this by clearing the TPM.
-
**To clear the TPM**
-
1. Open the Trusted Platform Module snap-in (tpm.msc).
-
2. Click **Clear TPM**, and then click **Restart.**
-
3. When the PC is restarting, you might be prompted to press a button on the keyboard to clear the TPM.
-
4. After the PC restarts, your TPM will be automatically prepared for use by Windows 10.
-
**Note**
Clearing the TPM causes you to lose all TPM keys and data protected by those keys, such as a virtual smart card. You should not perform this procedure on a device you do not own, such as a work or school PC, without being instructed to do so by your IT administrator.
-
-
## Additional resources
-
-
[Trusted Platform Module Technology Overview](trusted-platform-module-overview.md)
-
[Trusted Platform Module Services Group Policy Settings](trusted-platform-module-services-group-policy-settings.md)
-
[TPM Cmdlets in Windows PowerShell](http://technet.microsoft.com/library/jj603116.aspx)
-
[Schema Extensions for Windows Server 2008 R2 to support AD DS backup of TPM information from Windows 8 clients](ad-ds-schema-extensions-to-support-tpm-backup.md)
-
[TPM WMI providers](http://go.microsoft.com/fwlink/p/?LinkId=93478)
-
[Prepare your organization for BitLocker: Planning and Policies - TPM configurations](http://technet.microsoft.com/library/jj592683.aspx)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/tpm-recommendations.md b/windows/keep-secure/tpm-recommendations.md
index 651ed1468f..b9e5bc42f5 100644
--- a/windows/keep-secure/tpm-recommendations.md
+++ b/windows/keep-secure/tpm-recommendations.md
@@ -2,59 +2,37 @@
title: TPM recommendations (Windows 10)
description: This topic provides recommendations for Trusted Platform Module (TPM) technology for Windows 10.
ms.assetid: E85F11F5-4E6A-43E7-8205-672F77706561
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# TPM recommendations
-
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
- Windows Server 2016 Technical Preview
- Windows 10 IoT Core (IoT Core)
-
This topic provides recommendations for Trusted Platform Module (TPM) technology for Windows 10.
-
## Overview
-
-
Trusted Platform Module (TPM) technology is designed to provide hardware-based, security-related functions. It has a security-related crypto-processor that is designed to carry out cryptographic operations in a variety of devices and form factors. It includes multiple physical security mechanisms to help prevent malicious software from tampering with the security functions of the TPM. Some of the key advantages of using TPM technology are that you can:
-
1. Generate, store, use, and protected cryptographic keys,
2. Use TPM technology for platform device authentication by using a unique endorsement key (EK), and
3. Help enhance platform integrity by taking and storing security measurements.
-
The most common TPM functions are used for system integrity measurements and for key creation and use. During the boot process of a system, the boot code that is loaded (including firmware and the operating system components) can be measured and recorded in the TPM. The integrity measurements can be used as evidence for how a system started and to make sure that a TPM-based key was used only when the correct software was used to boot the system.
-
Traditionally, TPMs have been discrete chips soldered to a computer’s motherboard. Such implementations allow the computer’s original equipment manufacturer (OEM) to evaluate and certify the TPM separate from the rest of the system. Although discrete TPM implementations are still common, they can be problematic for integrated devices that are small or have low power consumption. Some newer TPM implementations integrate TPM functionality into the same chipset as other platform components while still providing logical separation similar to discrete TPM chips.
-
TPMs are passive: they receive commands and return responses. To realize the full benefit of a TPM, the OEM must carefully integrate system hardware and firmware with the TPM to send it commands and react to its responses. TPMs were originally designed to provide security and privacy benefits to a platform’s owner and users, but newer versions can provide security and privacy benefits to the system hardware itself. Before it can be used for advanced scenarios, however, a TPM must be provisioned. Windows 10 automatically provisions a TPM, but if the user reinstalls the operating system, he or she may need to tell the operating system to explicitly provision the TPM again before it can use all the TPM’s features.
-
The Trusted Computing Group (TCG) is the nonprofit organization that publishes and maintains the TPM specification. The TCG exists to develop, define, and promote vendor-neutral, global industry standards that support a hardware-based root of trust for interoperable trusted computing platforms. The TCG also publishes the TPM specification as the international standard ISO/IEC 11889, using the Publicly Available Specification Submission Process that the Joint Technical Committee 1 defines between the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC).
-
OEMs implement the TPM as a component in a trusted computing platform, such as a PC, tablet, or phone. Trusted computing platforms use the TPM to support privacy and security scenarios that software alone cannot achieve. For example, software alone cannot reliably report whether malware is present during the system startup process. The close integration between TPM and platform increases the transparency of the startup process and supports evaluating device health by enabling reliable measuring and reporting of the software that starts the device. Implementation of a TPM as part of a trusted computing platform provides a hardware root of trust—that is, it behaves in a trusted way. For example, if a key stored in a TPM has properties that disallow exporting the key, that key truly cannot leave the TPM.
-
The TCG designed the TPM as a low-cost, mass-market security solution that addresses the requirements of different customer segments. There are variations in the security properties of different TPM implementations just as there are variations in customer and regulatory requirements for different sectors. In public-sector procurement, for example, some governments have clearly defined security requirements for TPMs whereas others do not.
-
**Note**
Some information relates to pre-released product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
-
-
## TPM 1.2 vs. 2.0 comparison
-
-
From an industry standard, Microsoft has been an industry leader in moving and standardizing on TPM 2.0, which has many key realized benefits across algorithms, crypto, hierarchy, root keys, authorization and NV RAM.
-
## Why TPM 2.0?
-
TPM 2.0 products and systems have important security advantages over TPM 1.2, including:
-
- The TPM 1.2 spec only allows for the use of RSA and the SHA-1 hashing algorithm.
- For security reasons, some entities are moving away from SHA-1. Notably, NIST has required many federal agencies to move to SHA-256 as of 2014, and technology leaders, including Microsoft and Google have announced they will remove support for SHA-1 based signing or certificates in 2017.
- TPM 2.0 **enables greater crypto agility** by being more flexible with respect to cryptographic algorithms.
@@ -69,49 +47,31 @@ TPM 2.0 products and systems have important security advantages over TPM 1.2, in
- For AMD chips, it is the AMD Security Processor
- For ARM chips, it is a Trustzone Trusted Application (TA).
- In the case of firmware TPM for desktop Windows systems, the chip vendor provides the firmware TPM implementation along with the other chip firmware to OEMs.
-
## Discrete or firmware TPM?
-
Windows uses discrete and firmware TPM in the same way. Windows gains no functional advantage or disadvantage from either option.
-
From a security standpoint, discrete and firmware share the same characteristics;
-
- Both use hardware based secure execution.
- Both use firmware for portions of the TPM functionality.
- Both are equipped with tamper resistance capabilities.
- Both have unique security limitations/risks.
-
For more info, see [fTPM: A Firmware-based TPM 2.0 Implementation](http://research.microsoft.com/apps/pubs/?id=258236).
-
## Is there any importance for TPM for consumer?
For end consumers, TPM is behind the scenes but still very relevant for Hello, Passport and in the future, many other key features in Windows 10. It offers the best Passport experience, helps encrypt passwords, secures streaming high quality 4K content and builds on our overall Windows 10 experience story for security as a critical pillar. Using Windows on a system with a TPM enables a deeper and broader level of security coverage.
-
## TPM 2.0 Compliance for Windows 10
-
### Windows 10 for desktop editions (Home, Pro, Enterprise, and Education)
-
- As of July 28, 2016, all new device models, lines or series (or if you are updating the hardware configuration of a existing model, line or series with a major update, such as CPU, graphic cards) must implement and enable by default TPM 2.0 (details in section 3.7, https://msdn.microsoft.com/library/windows/hardware/dn915086(v=vs.85).aspx)
## Two implementation options:
• Discrete TPM chip as a separate discrete component
• Firmware TPM solution using Intel PTT (platform trust technology) or AMD
-
### Windows 10 Mobile
-
- All devices shipping with Windows 10 Mobile must implement TPM 2.0 and ship with the TPM 2.0 enabled.
-
### IoT Core
-
- TPM is optional on IoT Core.
-
### Windows Server 2016 Technical Preview
-
- TPM is optional for Windows Server SKUs unless the SKU meets the additional qualification (AQ) criteria for the Host Guardian Services scenario in which case TPM 2.0 is required.
-
## TPM and Windows Features
-
The following table defines which Windows features require TPM support. Some features are not applicable to Windows 7/8/8.1 and are noted accordingly.
-
@@ -223,16 +183,10 @@ The following table defines which Windows features require TPM support. Some fea
-
-
## Chipset options for TPM 2.0
-
-
There are a variety of TPM manufacturers for both discrete and firmware.
-
### Discrete TPM
-
@@ -254,11 +208,8 @@ There are a variety of TPM manufacturers for both discrete and firmware.
-
-
### Firmware TPM
-
@@ -302,25 +253,11 @@ There are a variety of TPM manufacturers for both discrete and firmware.
-
-
## OEM Feedback and Status on TPM 2.0 system availability
-
-
### Certified TPM parts
-
Government customers and enterprise customers in regulated industries may have acquisition standards that require use of common certified TPM parts. As a result, OEMs, who provide the devices, may be required to use only certified TPM components on their commercial class systems. Discrete TPM 2.0 vendors have completion certification.
-
### Windows 7 32-bit support
-
Even though Windows 7 shipped before the TPM 2.0 spec or products existed, Microsoft backported TPM 2.0 support to Windows 7 64-bit and released it in summer 2014 as a downloadable Windows hotfix for UEFI based Windows 7 systems. Microsoft is not currently planning to backport support to Windows 7 32-bit support.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/troubleshoot-windows-defender-in-windows-10.md b/windows/keep-secure/troubleshoot-windows-defender-in-windows-10.md
index 6928c30828..24182d9e16 100644
--- a/windows/keep-secure/troubleshoot-windows-defender-in-windows-10.md
+++ b/windows/keep-secure/troubleshoot-windows-defender-in-windows-10.md
@@ -2,43 +2,30 @@
title: Troubleshoot Windows Defender in Windows 10 (Windows 10)
description: IT professionals can review information about event IDs in Windows Defender for Windows 10 and see any relevant action they can take.
ms.assetid: EE488CC1-E340-4D47-B50B-35BD23CB4D70
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: manage
ms.sitesec: library
author: jasesso
---
-
# Troubleshoot Windows Defender in Windows 10
-
-
**Applies to**
-
- Windows 10
-
IT professionals can review information about event IDs in Windows Defender for Windows 10 and see any relevant action they can take.
-
## Windows Defender client event IDs
-
-
This section provides the following information about Windows Defender client events:
-
- The text of the message as it appears in the event
- The name of the source of the message
- The symbolic name that identifies each message in the programming source code
- Additional information about the message
-
Use the information in this table to help troubleshoot Windows Defender client events; these are located in the **Windows Event Viewer**, under **Windows Logs**.
-
**To view a Windows Defender client event**
-
1. Open **Event Viewer**.
2. In the console tree, expand **Applications and Services Logs**, then **Microsoft**, then **Windows**, then **Windows Defender**.
3. Double-click on **Operational**.
4. In the details pane, view the list of individual events to find your event.
5. Click the event to see specific details about an event in the lower pane, under the **General** and **Details** tabs.
-
You can find a complete list of the Microsoft antimalware event IDs, the symbol, and the description of each ID in [Windows Server Antimalware Events TechNet](https://technet.microsoft.com/library/dn913615.aspx).
-
| Event ID: 1000 |
@@ -314,7 +301,6 @@ Description of the error.
The Windows Defender client encountered an error, and the current scan has stopped. The scan might fail due to a client-side issue. This event record includes the scan ID, type of scan (antivirus, antispyware, antimalware), scan parameters, the user that started the scan, the error code, and a description of the error.
-
To troubleshoot this event:
@@ -1476,7 +1462,6 @@ Description of the error.
- Click the Update definitions button on the Update tab in Windows Defender.
 Or,
- Download the latest definitions from the Microsoft Malware Protection Center.
-
Note: The size of the definitions file downloaded from the Microsoft Malware Protection Center can exceed 60 MB and should not be used as a long-term solution for updating definitions.
@@ -1580,7 +1565,6 @@ Description of the error.
Click the Update definitions button on the Update tab in Windows Defender. Or,
Download the latest definitions from the Microsoft Malware Protection Center.
-
Note: The size of the definitions file downloaded from the Microsoft Malware Protection Center can exceed 60 MB and should not be used as a long-term solution for updating definitions.
@@ -1637,7 +1621,6 @@ Description of the error.
- Restart the computer and try again.
- Download the latest definitions from the Microsoft Malware Protection Center.
-
Note: The size of the definitions file downloaded from the Microsoft Malware Protection Center can exceed 60 MB and should not be used as a long-term solution for updating definitions.
- Contact Microsoft Technical Support.
@@ -2469,9 +2452,6 @@ or Hang
- Try to restart the service.
- For antimalware, antivirus and spyware, at an elevated command prompt, type net stop msmpsvc, and then type net start msmpsvc to restart the antimalware engine.
- For the Network Inspection System, at an elevated command prompt, type net start nissrv, and then type net start nissrv to restart the Network Inspection System engine by using the NiSSRV.exe file.
-
-
-
@@ -2672,20 +2652,13 @@ Description of the error.
|
-
## Windows Defender client error codes
-
-
If Windows Defender experiences any issues it will usually give you an error code to help you troubleshoot the issue. Most often an error means there was a problem installing an update.
-
This section provides the following information about Windows Defender client errors.
-
- The error code
- The possible reason for the error
- Advice on what to do now
-
Use the information in these tables to help troubleshoot Windows Defender error codes.
-
| External error codes |
@@ -2737,7 +2710,6 @@ Use the information in these tables to help troubleshoot Windows Defender error
Click the Update definitions button on the Update tab in Windows Defender. Or,
Download the latest definitions from the Microsoft Malware Protection Center.
-
Note: The size of the definitions file downloaded from the Microsoft Malware Protection Center can exceed 60 MB and should not be used as a long-term solution for updating definitions.
@@ -2981,7 +2953,6 @@ article.
Click the Update definitions button on the Update tab in Windows Defender. Or,
Download the latest definitions from the Microsoft Malware Protection Center.
-
Note: The size of the definitions file downloaded from the Microsoft Malware Protection Center can exceed 60 MB and should not be used as a long-term solution for updating definitions.
@@ -3286,18 +3257,8 @@ article.
-
## Related topics
-
[Configure Windows Defender in Windows 10](configure-windows-defender-in-windows-10.md)
-
[Update and manage Windows Defender in Windows 10](get-started-with-windows-defender-for-windows-10.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/trusted-platform-module-overview.md b/windows/keep-secure/trusted-platform-module-overview.md
index 8d48e9a658..02ba8d12dc 100644
--- a/windows/keep-secure/trusted-platform-module-overview.md
+++ b/windows/keep-secure/trusted-platform-module-overview.md
@@ -2,74 +2,41 @@
title: Trusted Platform Module Technology Overview (Windows 10)
description: This topic for the IT professional describes the Trusted Platform Module (TPM) and how Windows uses it for access control and authentication. The topic provides links to other resources about the TPM.
ms.assetid: face8932-b034-4319-86ac-db1163d46538
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Trusted Platform Module Technology Overview
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional describes the Trusted Platform Module (TPM) and how Windows uses it for access control and authentication. The topic provides links to other resources about the TPM.
-
## Feature description
-
-
Trusted Platform Module (TPM) technology is designed to provide hardware-based, security-related functions. A TPM chip is a secure crypto-processor that is designed to carry out cryptographic operations. The chip includes multiple physical security mechanisms to make it tamper resistant, and malicious software is unable to tamper with the security functions of the TPM. Some of the key advantages of using TPM technology are that you can:
-
- Generate, store, and limit the use of cryptographic keys.
-
- Use TPM technology for platform device authentication by using the TPM’s unique RSA key, which is burned into itself.
-
- Help ensure platform integrity by taking and storing security measurements.
-
The most common TPM functions are used for system integrity measurements and for key creation and use. During the boot process of a system, the boot code that is loaded (including firmware and the operating system components) can be measured and recorded in the TPM. The integrity measurements can be used as evidence for how a system started and to make sure that a TPM-based key was used only when the correct software was used to boot the system.
-
TPM-based keys can be configured in a variety of ways. One option is to make a TPM-based key unavailable outside the TPM. This is good to mitigate phishing attacks because it prevents the key from being copied and used without the TPM. TPM-based keys can also be configured to require an authorization value to use them. If too many incorrect authorization guesses occur, the TPM will activate its dictionary attack logic and prevent further authorization value guesses.
-
Different versions of the TPM are defined in specifications by the Trusted Computing Group (TCG). For more information, consult the TCG Web site ().
-
Windows can automatically provision and manage the TPM. Group Policy settings can be configured to control whether the TPM owner authorization value is backed up in Active Directory. Because the TPM state persists across operating system installations, TPM information is stored in a location in Active Directory that is separate from computer objects. Depending on an enterprise’s security goals, Group Policy can be configured to allow or prevent local administrators from resetting the TPM’s dictionary attack logic. Standard users can use the TPM, but Group Policy controls limit how many authorization failures standard users can attempt so that one user is unable to prevent other users or the administrator from using the TPM. TPM technology can also be used as a virtual smart card and for secure certificate storage. With BitLocker Network Unlock, domain-joined computers are not prompted for a BitLocker PIN.
-
## Practical applications
-
-
Certificates can be installed or created on computers that are using the TPM. After a computer is provisioned, the RSA private key for a certificate is bound to the TPM and cannot be exported. The TPM can also be used as a replacement for smart cards, which reduces the costs associated with creating and disbursing smart cards.
-
Automated provisioning in the TPM reduces the cost of TPM deployment in an enterprise. New APIs for TPM management can determine if TPM provisioning actions require physical presence of a service technician to approve TPM state change requests during the boot process.
-
Antimalware software can use the boot measurements of the operating system start state to prove the integrity of a computer running Windows 10, Windows 8.1, Windows 8, Windows Server 2012 R2, or Windows Server 2012. These measurements include the launch of Hyper-V to test that datacenters using virtualization are not running untrusted hypervisors. With BitLocker Network Unlock, IT administrators can push an update without concerns that a computer is waiting for PIN entry.
-
The TPM has several Group Policy settings that can be used to manage how it is used. These settings can be used to manage the owner authorization value, the blocked TPM commands, the standard user lockout, and the backup of the TPM to AD DS. For more info, see [Trusted Platform Module Services Group Policy Settings](trusted-platform-module-services-group-policy-settings.md).
-
## New and changed functionality
-
-
For more info on new and changed functionality for Trusted Platform Module in Windows 10, see [What's new in Trusted Platform Module?](../whats-new/trusted-platform-module.md).
-
## Device health attestation
-
-
Device health attestation enables enterprises to establish trust based on hardware and software components of a managed device. With device heath attestation, you can configure an MDM server to query a health attestation service that will allow or deny a managed device access to a secure resource.
-
Some things that you can check on the device are:
-
- Is Data Execution Prevention supported and enabled?
- Is BitLocker Drive Encryption supported and enabled?
- Is SecureBoot supported and enabled?
-
**Note** The device must be running Windows 10 and it must support at least TPM 2.0.
-
-
## Supported versions
-
-
@@ -104,27 +71,12 @@ Some things that you can check on the device are:
-
-
## Additional Resources
-
-
[TPM Fundamentals](tpm-fundamentals.md)
-
[TPM Group Policy settings](trusted-platform-module-services-group-policy-settings.md)
-
[TPM Cmdlets in Windows PowerShell](http://technet.microsoft.com/library/jj603116.aspx)
-
[AD DS schema extensions to support TPM backup](ad-ds-schema-extensions-to-support-tpm-backup.md)
-
[Prepare your organization for BitLocker: Planning and Policies - TPM configurations](http://technet.microsoft.com/library/jj592683.aspx)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/trusted-platform-module-services-group-policy-settings.md b/windows/keep-secure/trusted-platform-module-services-group-policy-settings.md
index e03f0a8624..4b274eecc5 100644
--- a/windows/keep-secure/trusted-platform-module-services-group-policy-settings.md
+++ b/windows/keep-secure/trusted-platform-module-services-group-policy-settings.md
@@ -2,28 +2,19 @@
title: TPM Group Policy settings (Windows 10)
description: This topic for the IT professional describes the Trusted Platform Module (TPM) Services that can be controlled centrally by using Group Policy settings.
ms.assetid: 54ff1c1e-a210-4074-a44e-58fee26e4dbd
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# TPM Group Policy settings
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional describes the Trusted Platform Module (TPM) Services that can be controlled centrally by using Group Policy settings.
-
##
-
-
The TPM Services Group Policy settings are located at:
-
**Computer Configuration\\Administrative Templates\\System\\Trusted Platform Module Services\\**
-
@@ -110,114 +101,63 @@ The TPM Services Group Policy settings are located at:
-
-
### Turn on TPM backup to Active Directory Domain Services
-
This policy setting allows you to manage the Active Directory Domain Services (AD DS) backup of TPM owner information.
-
**Note**
This policy setting applies to the Windows operating systems listed in the [version table](#bkmk-version-table).
-
-
TPM owner information includes a cryptographic hash of the TPM owner password. Certain TPM commands can be run only by the TPM owner. This hash authorizes the TPM to run these commands.
-
**Important**
To back up TPM owner information from a computer running Windows 10, Windows 8.1, or Windows 8, you might need to first set up appropriate schema extensions and access control settings on the domain so that the AD DS backup can succeed. Windows Server 2012 R2 and Windows Server 2012 include the required schema extensions by default. For more information, see [AD DS schema extensions to support TPM backup](ad-ds-schema-extensions-to-support-tpm-backup.md).
-
-
The TPM cannot be used to provide enhanced security features for BitLocker Drive Encryption and other applications without first setting an owner. To take ownership of the TPM with an owner password, on a local computer at the command prompt, type **tpm.msc** to open the TPM Management Console and select the action to **Initialize TPM**. If the TPM owner information is lost or is not available, limited TPM management is possible by running **tpm.msc**.
-
If you enable this policy setting, TPM owner information will be automatically and silently backed up to AD DS when you use Windows to set or change a TPM owner password. When this policy setting is enabled, a TPM owner password cannot be set or changed unless the computer is connected to the domain and the AD DS backup succeeds.
-
If you disable or do not configure this policy setting, TPM owner information will not be backed up to AD DS.
-
### Configure the list of blocked TPM commands
-
This policy setting allows you to manage the Group Policy list of Trusted Platform Module (TPM) commands that are blocked by Windows.
-
**Note**
This policy setting applies to the Windows operating systems listed in the [version table](#bkmk-version-table).
-
-
If you enable this policy setting, Windows will block the specified commands from being sent to the TPM on the computer. TPM commands are referenced by a command number. For example, command number 129 is **TPM\_OwnerReadInternalPub**, and command number 170 is **TPM\_FieldUpgrade**. To find the command number that is associated with each TPM command, at the command prompt, type **tpm.msc**to open the TPM Management Console and navigate to the **Command Management** section.
-
If you disable or do not configure this policy setting, only those TPM commands that are specified through the default or local lists can be blocked by Windows. The default list of blocked TPM commands is preconfigured by Windows.
-
- You can view the default list by typing **tpm.msc** at the command prompt, navigating to the **Command Management** section, and exposing the **On Default Block List** column.
-
- The local list of blocked TPM commands is configured outside of Group Policy by running the TPM Management Console or scripting using the **Win32\_Tpm** interface.
-
For information how to enforce or ignore the default and local lists of blocked TPM commands, see
-
- [Ignore the default list of blocked TPM commands](#bkmk-tpmgp-idlb)
-
- [Ignore the local list of blocked TPM commands](#bkmk-tpmgp-illb)
-
### Ignore the default list of blocked TPM commands
-
This policy setting allows you to enforce or ignore the computer's default list of blocked Trusted Platform Module (TPM) commands.
-
**Note**
This policy setting applies to the Windows operating systems listed in the [version table](#bkmk-version-table).
-
-
The default list of blocked TPM commands is preconfigured by Windows. You can view the default list by typing **tpm.msc** at the command prompt to open the TPM Management Console, navigating to the **Command Management** section, and exposing the **On Default Block List** column. Also see the related policy setting, [Configure the list of blocked TPM commands](#bkmk-tpmgp-clbtc).
-
If you enable this policy setting, the Windows operating system will ignore the computer's default list of blocked TPM commands, and it will block only those TPM commands that are specified by Group Policy or the local list.
-
If you disable or do not configure this policy setting, Windows will block the TPM commands in the default list, in addition to the commands that are specified by Group Policy and the local list of blocked TPM commands.
-
### Ignore the local list of blocked TPM commands
-
This policy setting allows you to enforce or ignore the computer's local list of blocked Trusted Platform Module (TPM) commands.
-
**Note**
This policy setting applies to the Windows operating systems listed in the [version table](#bkmk-version-table).
-
-
The local list of blocked TPM commands is configured outside of Group Policy by typing **tpm.msc** at the command prompt to open the TPM Management Console, or scripting using the **Win32\_Tpm** interface. (The default list of blocked TPM commands is preconfigured by Windows.) Also see the related policy setting to **Configure the list of blocked TPM commands**.
-
If you enable this policy setting, the Windows operating system will ignore the computer's local list of blocked TPM commands, and it will block only those TPM commands that are specified by Group Policy or the default list.
-
If you disable or do not configure this policy setting, Windows will block the TPM commands in the local list, in addition to the commands that are specified in Group Policy and the default list of blocked TPM commands.
-
### Configure the level of TPM owner authorization information available to the operating system
-
This policy setting configures how much of the TPM owner authorization information is stored in the registry of the local computer. Depending on the amount of TPM owner authorization information that is stored locally, the Windows operating system and TPM-based applications can perform certain actions in the TPM that require TPM owner authorization without requiring the user to enter the TPM owner password.
-
**Note**
This policy setting applies to the Windows operating systems listed in the [version table](#bkmk-version-table).
-
-
There are three TPM owner authentication settings that are managed by the Windows operating system. You can choose a value of **Full**, **Delegate**, or **None**.
-
- **Full** This setting stores the full TPM owner authorization, the TPM administrative delegation blob, and the TPM user delegation blob in the local registry. With this setting, you can use the TPM without requiring remote or external storage of the TPM owner authorization value. This setting is appropriate for scenarios that do not require you to reset the TPM anti-hammering logic or change the TPM owner authorization value. Some TPM-based applications may require that this setting is changed before features that depend on the TPM anti-hammering logic can be used.
-
- **Delegated** This setting stores only the TPM administrative delegation blob and the TPM user delegation blob in the local registry. This setting is appropriate for use with TPM-based applications that depend on the TPM antihammering logic. When you use this setting, we recommend using external or remote storage for the full TPM owner authorization value—for example, backing up the value in Active Directory Domain Services (AD DS).
-
- **None** This setting provides compatibility with previous operating systems and applications. You can also use it for scenarios when TPM owner authorization cannot be stored locally. Using this setting might cause issues with some TPM-based applications.
-
**Note**
If the operating system managed TPM authentication setting is changed from **Full** to **Delegated**, the full TPM owner authorization value will be regenerated, and any copies of the previously set TPM owner authorization value will be invalid. If you are backing up the TPM owner authorization value to AD DS, the new owner authorization value is automatically backed up to AD DS when it is changed.
-
-
**Registry information**
-
Registry key: HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Policies\\Microsoft\\TPM
-
DWORD: OSManagedAuthLevel
-
The following table shows the TPM owner authorization values in the registry.
-
@@ -244,96 +184,48 @@ The following table shows the TPM owner authorization values in the registry.
-
-
If you enable this policy setting, the Windows operating system will store the TPM owner authorization in the registry of the local computer according to the TPM authentication setting you choose.
-
If you disable or do not configure this policy setting, and the **Turn on TPM backup to Active Directory Domain Services** policy setting is also disabled or not configured, the default setting is to store the full TPM authorization value in the local registry. If this policy is disabled or not configured, and the **Turn on TPM backup to Active Directory Domain Services** policy setting is enabled, only the administrative delegation and the user delegation blobs are stored in the local registry.
-
### Standard User Lockout Duration
-
This policy setting allows you to manage the duration in minutes for counting standard user authorization failures for Trusted Platform Module (TPM) commands requiring authorization. An authorization failure occurs each time a standard user sends a command to the TPM and receives an error response that indicates an authorization failure occurred. Authorization failures that are older than the duration you set are ignored. If the number of TPM commands with an authorization failure within the lockout duration equals a threshold, a standard user is prevented from sending commands that require authorization to the TPM.
-
**Note**
This policy setting applies to the Windows operating systems listed in the [version table](#bkmk-version-table).
-
-
The TPM is designed to protect itself against password guessing attacks by entering a hardware lockout mode when it receives too many commands with an incorrect authorization value. When the TPM enters a lockout mode, it is global for all users (including administrators) and for Windows features such as BitLocker Drive Encryption.
-
The number of authorization failures that a TPM allows and how long it stays locked vary by TPM manufacturer. Some TPMs may enter lockout mode for successively longer periods of time, with fewer authorization failures, depending on past failures. Some TPMs may require a system restart to exit the lockout mode. Other TPMs may require that the system is on so enough clock cycles elapse before the TPM exits the lockout mode.
-
This setting helps administrators prevent the TPM hardware from entering a lockout mode by slowing the speed at which standard users can send commands that require authorization to the TPM.
-
For each standard user, two thresholds apply. Exceeding either threshold prevents the user from sending a command that requires authorization to the TPM. Use the following policy settings to set the lockout duration:
-
- [Standard User Individual Lockout Threshold](#bkmk-individual) This value is the maximum number of authorization failures that each standard user can have before the user is not allowed to send commands that require authorization to the TPM.
-
- [Standard User Total Lockout Threshold](#bkmk-total) This value is the maximum total number of authorization failures that all standard users can have before all standard users are not allowed to send commands that require authorization to the TPM.
-
An administrator with the TPM owner password can fully reset the TPM's hardware lockout logic by using the TPM Management Console (tpm.msc). Each time an administrator resets the TPM's hardware lockout logic, all prior standard user TPM authorization failures are ignored. This allows standard users to immediately use the TPM normally.
-
If you do not configure this policy setting, a default value of 480 minutes (8 hours) is used.
-
### Standard User Individual Lockout Threshold
-
This policy setting allows you to manage the maximum number of authorization failures for each standard user for the Trusted Platform Module (TPM). This value is the maximum number of authorization failures that each standard user can have before the user is not allowed to send commands that require authorization to the TPM. If the number of authorization failures for the user within the duration that is set for the **Standard User Lockout Duration** policy setting equals this value, the standard user is prevented from sending commands that require authorization to the Trusted Platform Module (TPM).
-
**Note**
This policy setting applies to the Windows operating systems listed in the [version table](#bkmk-version-table).
-
-
This setting helps administrators prevent the TPM hardware from entering a lockout mode by slowing the speed at which standard users can send commands that require authorization to the TPM.
-
An authorization failure occurs each time a standard user sends a command to the TPM and receives an error response indicating an authorization failure occurred. Authorization failures older than the duration are ignored.
-
An administrator with the TPM owner password can fully reset the TPM's hardware lockout logic by using the TPM Management Console (tpm.msc). Each time an administrator resets the TPM's hardware lockout logic, all prior standard user TPM authorization failures are ignored. This allows standard users to immediately use the TPM normally.
-
If you do not configure this policy setting, a default value of 4 is used. A value of zero means that the operating system will not allow standard users to send commands to the TPM, which might cause an authorization failure.
-
### Standard User Total Lockout Threshold
-
This policy setting allows you to manage the maximum number of authorization failures for all standard users for the Trusted Platform Module (TPM). If the total number of authorization failures for all standard users within the duration that is set for the **Standard User Lockout Duration** policy equals this value, all standard users are prevented from sending commands that require authorization to the Trusted Platform Module (TPM).
-
**Note**
This policy setting applies to the Windows operating systems listed in the [version table](#bkmk-version-table).
-
-
This setting helps administrators prevent the TPM hardware from entering a lockout mode because it slows the speed standard users can send commands requiring authorization to the TPM.
-
An authorization failure occurs each time a standard user sends a command to the TPM and receives an error response indicating an authorization failure occurred. Authorization failures older than the duration are ignored.
-
For each standard user two thresholds apply. Exceeding either threshold will prevent the standard user from sending a command to the TPM that requires authorization.
-
1. The standard user individual lockout value is the maximum number of authorization failures each standard user may have before the user is not allowed to send commands requiring authorization to the TPM.
-
2. The standard user total lockout threshold value is the maximum total number of authorization failures all standard users may have before all standard users are not allowed to send commands requiring authorization to the TPM.
-
The TPM is designed to protect itself against password guessing attacks by entering a hardware lockout mode when it receives too many commands with an incorrect authorization value. When the TPM enters a lockout mode, it is global for all users (including administrators) and for Windows features such as BitLocker Drive Encryption..
-
The number of authorization failures a TPM allows and how long it stays locked out vary by TPM manufacturer. Some TPMs may enter lockout mode for successively longer periods of time with fewer authorization failures depending on past failures. Some TPMs may require a system restart to exit the lockout mode. Other TPMs may require the system to be on so enough clock cycles elapse before the TPM exits the lockout mode.
-
An administrator with the TPM owner password can fully reset the TPM's hardware lockout logic by using the TPM Management Console (tpm.msc). Each time an administrator resets the TPM's hardware lockout logic, all prior standard user TPM authorization failures are ignored. This allows standard users to immediately use the TPM normally.
-
If you do not configure this policy setting, a default value of 9 is used. A value of zero means that the operating system will not allow standard users to send commands to the TPM, which might cause an authorization failure.
-
## Additional resources
-
-
[Trusted Platform Module Technology Overview](trusted-platform-module-overview.md)
-
[TPM Cmdlets in Windows PowerShell](http://technet.microsoft.com/library/jj603116.aspx)
-
[Prepare your organization for BitLocker: Planning and Policies - TPM configurations](http://technet.microsoft.com/library/jj592683.aspx)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/types-of-attacks-for-volume-encryption-keys.md b/windows/keep-secure/types-of-attacks-for-volume-encryption-keys.md
index b9da17ac68..057ed8dad2 100644
--- a/windows/keep-secure/types-of-attacks-for-volume-encryption-keys.md
+++ b/windows/keep-secure/types-of-attacks-for-volume-encryption-keys.md
@@ -2,159 +2,81 @@
title: Types of attacks for volume encryption keys (Windows 10)
description: There are many ways Windows helps protect your organization from attacks, including Unified Extensible Firmware Interface (UEFI) secure boot, Trusted Platform Module (TPM), Group Policy, complex passwords, and account lockouts.
ms.assetid: 405060a9-2009-44fc-9f84-66edad32c6bc
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Types of attacks for volume encryption keys
-
-
**Applies to**
-
- Windows 10
-
There are many ways Windows helps protect your organization from attacks, including Unified Extensible Firmware Interface (UEFI) secure boot, Trusted Platform Module (TPM), Group Policy, complex passwords, and account lockouts.
-
The next few sections describe each type of attack that could be used to compromise a volume encryption key, whether for BitLocker or a non-Microsoft encryption solution. After an attacker has compromised a volume encryption key, the attacker can read data from your system drive or even install malware while Windows is offline. Each section begins with a graphical overview of the attack’s strengths and weaknesses as well as suggested mitigations.
-
### Bootkit and rootkit attacks
-
Rootkits are a sophisticated and dangerous type of malware that runs in kernel mode, using the same privileges as the operating system. Because rootkits have the same or possibly even more rights than the operating system, they can completely hide themselves from Windows and even an antimalware solution. Often, rootkits are part of an entire suite of malware that can bypass local logins, record passwords, transfer private files, and capture cryptography keys.
-
Different types of bootkits and rootkits load at different software levels:
-
- **Kernel level.** Rootkits running at the kernel level have the highest privilege in the operating system. They may be able to inject malicious code or replace portions of the core operating system, including both the kernel and device drivers.
-
- **Application level.** These rootkits are aimed to replace application binaries with malicious code, such as a Trojan, and can even modify the behavior of existing applications.
-
- **Library level.** The purpose of library-level rootkits is to hook, patch, or replace system calls with malicious code that can hide the malware’s presence.
-
- **Hypervisor level.** Hypervisor rootkits target the boot sequence. Their primary purpose is to modify the boot sequence to load themselves as a hypervisor.
-
- **Firmware level.** These rootkits overwrite the PC’s BIOS firmware, giving the malware low-level access and potentially the ability to install or hide malware, even if it’s cleaned or removed from the hard disk.
-
Regardless of the operating system or encryption method, rootkits have access to confidential data once installed. Application-level rootkits can read any files the user can access, bypassing volume-level encryption. Kernel-, library-, hypervisor-, and firmware-level rootkits have direct access to system files on encrypted volumes and can also retrieve an encryption key from memory.
-
Windows offers substantial protection from bootkits and rootkits, but it is possible to bypass operating system security when an attacker has physical access to the device and can install the malware to the device while Windows is offline. For example, an attacker might boot a PC from a USB flash drive containing malware that starts before Windows. The malware can replace system files or the PC’s firmware or simply start Windows under its control.
-
To sufficiently protect a PC from boot and rootkits, devices must use pre-boot authentication or Secure Boot, or the encryption solution must use the device’s Trusted Platform Module (TPM) as a means of monitoring the integrity of the end-to-end boot process. Pre-boot authentication is available for any device, regardless of the hardware, but because it is inconvenient to users, it should be used only to mitigate threats that are applicable to the device. On devices with Secure Boot enabled, you do not need to use pre-boot authentication to protect against boot and rootkit attacks.
-
Although password protection of the UEFI configuration is important for protecting a device’s configuration and preventing an attacker from disabling Secure Boot, use of a TPM and its Platform Configuration Register (PCR) measurements (PCR7) to ensure that the system’s bootloader (whether a Windows or non-Microsoft encryption solution) is tamper free and the first code to start on the device is critical. An encryption solution that doesn’t use a device’s TPM to protect its components from tampering may be unable to protect itself from bootkit-level infections that could log a user’s password or acquire encryption keys.
-
For this reason, when BitLocker is configured on devices that include a TPM, the TPM and its PCRs are always used to secure and confirm the integrity of the pre–operating system environment before making encrypted volumes accessible.
-
Any changes to the UEFI configuration invalidates the PCR7 and require the user to enter the BitLocker recovery key. Because of this feature, it’s not critical to password-protect your UEFI configuration. If an attacker successfully turns off Secure Boot or otherwise changes the UEFI configuration, they will need to enter the BitLocker recovery key, but UEFI password protection is a best practice and is still required for systems not using a TPM (such as non-Microsoft alternatives).
-
### Brute-force Sign-in Attacks
-
Attackers can find any password if you allow them to guess enough times. The process of trying millions of different passwords until you find the right one is known as a *brute-force sign-in attack*. In theory, an attacker could obtain any password by using this method.
-
Three opportunities for brute-force attacks exist:
-
- **Against the pre-boot authenticator.** An attacker could attack the device directly by attempting to guess the user’s BitLocker PIN or an equivalent authenticator. The TPM mitigates this approach by invoking an anti-hammering lockout capability that requires the user to wait until the lockout period ends or enter the BitLocker recovery key.
-
- **Against the recovery key.** An attacker could attempt to guess the 48-digit BitLocker recovery key. Even without a lockout period, the key is long enough to make brute-force attacks impractical. Specifically, the BitLocker recovery key has 128 bits of entropy; thus, the average brute-force attack would succeed after 18,446,744,073,709,551,616 guesses. If an attacker could guess 1 million passwords per second, the average brute-force attack would require more than 580,000 years to be successful.
-
- **Against the operating system sign-in authenticator.** An attacker can attempt to guess a valid user name and password. Windows implements a delay between password guesses, slowing down brute-force attacks. In addition, all recent versions of Windows allow administrators to require complex passwords and password lockouts. Similarly, administrators can use Microsoft Exchange ActiveSync policy or Group Policy to configure Windows 8.1 and Windows 8 to automatically restart and require the user to enter the BitLocker 48-digit recovery key after a specified number of invalid password attempts. When these settings are enabled and users follow best practices for complex passwords, brute-force attacks against the operating system sign-in are impractical.
-
In general, brute-force sign-in attacks are not practical against Windows when administrators enforce complex passwords and account lockouts.
-
### Direct Memory Access Attacks
-
Direct memory access (DMA) allows certain types of hardware devices to communicate directly with a device’s system memory. For example, if you use Thunderbolt to connect another device to your computer, the second device automatically has Read and Write access to the target computer’s memory.
-
Unfortunately, DMA ports don’t use authentication and access control to protect the contents of the computer’s memory. Whereas Windows can often prevent system components and apps from reading and writing to protected parts of memory, a device can use DMA to read any location in memory, including the location of any encryption keys.
-
DMA attacks are relatively easy to execute and require little technical skills. Anyone can download a tool from the Internet, such as those made by [Passware](http://www.lostpassword.com/), [ElcomSoft](http://elcomsoft.com/), and others, and then use a DMA attack to read confidential data from a PC’s memory. Because encryption solutions store their encryption keys in memory, they can be accessed by a DMA attack.
-
Not all port types are vulnerable to DMA attacks. USB in particular does not allow DMA, but devices that have any of the following port types are vulnerable:
-
- FireWire
-
- Thunderbolt
-
- ExpressCard
-
- PCMCIA
-
- PCI
-
- PCI-X
-
- PCI Express
-
To perform a DMA attack, attackers typically connect a second PC that is running a memory-scanning tool (for example, Passware, ElcomSoft) to the FireWire or Thunderbolt port of the target computer. When connected, the software scans the system memory of the target and locates the encryption key. Once acquired, the key can be used to decrypt the drive and read or modify its contents.
-
A much more efficient form of this attack exists in theory: An attacker crafts a custom FireWire or Thunderbolt device that has the DMA attack logic programmed on it. Now, the attacker simply needs to physically connect the device. If the attacker does not have physical access, they could disguise it as a free USB flash drive and distribute it to employees of a target organization. When connected, the attacking device could use a DMA attack to scan the PC’s memory for the encryption key. It could then transmit the key (or any data in the PC’s memory) using the PC’s Internet connection or its own wireless connection. This type of attack would require an extremely high level of sophistication, because it requires that the attacker create a custom device (devices of these types are not readily available in the marketplace at this time).
-
Today, one of the most common uses for DMA ports on Windows devices is for developer debugging, a task that some developers need to perform and one that few consumers will ever perform. Because USB; DisplayPort; and other, more secure port types satisfy consumers, most new mobile PCs do not include DMA ports. Microsoft’s view is that because of the inherent security risks of DMA ports, they do not belong on mobile devices, and Microsoft has prohibited their inclusion on any InstantGo-certified devices. InstantGo devices offer mobile phone–like power management and instant-on capabilities; at the time of writing, they are primarily found in Windows tablets.
-
DMA-based expansion slots are another avenue of attack, but these slots generally appear only on desktop PCs that are designed for expansion. Organizations can use physical security to prevent outside attacks against their desktop PCs. In addition, a DMA attack on the expansion slot would require a custom device; as a result, an attacker would most likely insert an interface with a traditional DMA port (for example, FireWire) into the slot to attack the PC.
-
To mitigate a port-based DMA attack an administrator can configure policy settings to disable FireWire and other device types that have DMA. Also, many PCs allow those devices to be disabled by using firmware settings. Although the need for pre-boot authentication can be eliminated at the device level or through Windows configuration, the BitLocker pre-boot authentication feature is still available when needed. When used, it successfully mitigates all types of DMA port and expansion slot attacks on any type of device.
-
### Hyberfil.sys Attacks
-
The hyberfil.sys file is the Windows hibernation file. It contains a snapshot of system memory that is generated when a device goes into hibernation and includes the encryption key for BitLocker and other encryption technologies. Attackers have claimed that they have successfully extracted encryption keys from the hyberfil.sys file.
-
Like the DMA port attack discussed in the previous section, tools are available that can scan the hyberfile.sys file and locate the encryption key, including a tool made by [Passware](http://www.lostpassword.com/). Microsoft does not consider Windows to be vulnerable to this type of attack, because Windows stores the hyberfil.sys file within the encrypted system volume. As a result, the file would be accessible only if the attacker had both physical and sign-in access to the PC. When an attacker has sign-in access to the PC, there are few reasons for the attacker to decrypt the drive, because they would already have full access to the data within it.
-
In practice, the only reason an attack on hyberfil.sys would grant an attacker additional access is if an administrator had changed the default Windows configuration and stored the hyberfil.sys file on an unencrypted drive. By default, Windows 10 is designed to be secure against this type of attack.
-
### Memory Remanence Attacks
-
A memory remanence attack is a side-channel attack that reads the encryption key from memory after restarting a PC. Although a PC’s memory is often considered to be cleared when the PC is restarted, memory chips don’t immediately lose their memory when you disconnect power. Therefore, an attacker who has physical access to the PC’s memory might be able to read data directly from the memory—including the encryption key.
-
When performing this type of cold boot attack, the attacker accesses the PC’s physical memory and recovers the encryption key within a few seconds or minutes of disconnecting power. This type of attack was demonstrated by researchers at [Princeton University](http://www.youtube.com/watch?v=JDaicPIgn9U). With the encryption key, the attacker would be able to decrypt the drive and access its files.
-
To acquire the keys, attackers follow this process:
-
1. Freeze the PC’s memory. For example, an attacker can freeze the memory to −50°C by spraying it with aerosol air duster spray.
-
2. Restart the PC.
-
3. Instead of restarting Windows, boot to another operating system. Typically, this is done by connecting a bootable flash drive or loading a bootable DVD.
-
4. The bootable media loads the memory remanence attack tools, which the attacker uses to scan the system memory and locate the encryption keys.
-
5. The attacker uses the encryption keys to access the drive’s data.
-
If the attacker is unable to boot the device to another operating system (for example, if bootable flash drives have been disabled or Secure Boot is enabled), the attacker can attempt to physically remove the frozen memory from the device and attach it to a different, possibly identical device. Fortunately, this process has proven extremely unreliable, as evidenced by the Defence Research and Development Canada (DRDC) Valcartier group’s analysis (see [An In-depth Analysis of the Cold Boot Attack](http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA545078)). On an increasing portion of modern devices, this type of attack is not even possible, because memory is soldered directly to the motherboard.
-
Although Princeton’s research proved that this type of attack was possible on devices that have removable memory, device hardware has changed since the research was published in 2008:
-
- Secure Boot prevents the malicious tools that the Princeton attack depends on from running on the target device.
-
- Windows systems with BIOS or UEFI can be locked down with a password, and booting to a USB drive can be prevented.
-
- If booting to USB is required on the device, it can be limited to starting trusted operating systems by using Secure Boot.
-
- The discharge rates of memory are highly variable among devices, and many devices have memory that is completely immune to memory remanence attacks.
-
- Increased density of memory diminishes their remanence properties and reduces the likelihood that the attack can be successfully executed, even when memory is physically removed and placed in an identical system where the system’s configuration may enable booting to the malicious tools.
-
Because of these factors, this type of attack is rarely possible on modern devices. Even in cases where the risk factors exist on legacy devices, attackers will find the attack unreliable. For detailed info about the practical uses for forensic memory acquisition and the factors that make a computer vulnerable or resistant to memory remanence attacks, read [An In-depth Analysis of the Cold Boot Attack](http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA545078).
-
The BitLocker pre-boot authentication feature can successfully mitigate memory remanence attacks on most devices, but you can also mitigate such attacks by protecting the system UEFI or BIOS and prevent the PC from booting from external media (such as a USB flash drive or DVD). The latter option is often a better choice, because it provides sufficient protection without inconveniencing users with pre-boot authentication.
-
## See also
-
-
- [BitLocker countermeasures](bitlocker-countermeasures.md)
-
- [Choose the right BitLocker countermeasure](choose-the-right-bitlocker-countermeasure.md)
-
- [Protect BitLocker from pre-boot attacks](protect-bitlocker-from-pre-boot-attacks.md)
-
- [BitLocker overview](bitlocker-overview.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/understand-applocker-enforcement-settings.md b/windows/keep-secure/understand-applocker-enforcement-settings.md
index 7b977fc57a..f62646c2e9 100644
--- a/windows/keep-secure/understand-applocker-enforcement-settings.md
+++ b/windows/keep-secure/understand-applocker-enforcement-settings.md
@@ -2,23 +2,17 @@
title: Understand AppLocker enforcement settings (Windows 10)
description: This topic describes the AppLocker enforcement settings for rule collections.
ms.assetid: 48773007-a343-40bf-8961-b3ff0a450d7e
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Understand AppLocker enforcement settings
-
-
**Applies to**
-
- Windows 10
-
This topic describes the AppLocker enforcement settings for rule collections.
-
Rule enforcement is applied only to a collection of rules, not to individual rules. AppLocker divides the rules into four collections: executable files, Windows Installer files, scripts, and DLL files. For more info about rule collections, see [Understanding AppLocker rule collections](understanding-applocker-rule-collections.md). By default, if enforcement is not configured and rules are present in a rule collection, those rules are enforced. The following table details the three AppLocker rule enforcement settings in Group Policy for each rule collection.
-
@@ -45,18 +39,8 @@ Rule enforcement is applied only to a collection of rules, not to individual rul
-
-
For the AppLocker policy to be enforced on a device, the Application Identity service must be running. For more info about the Application Identity service, see [Configure the Application Identity service](configure-the-application-identity-service.md).
-
When AppLocker policies from various GPOs are merged, the enforcement modes are merged by using the standard Group Policy order of inheritance, which is local, domain, site, and organizational unit (OU). The Group Policy setting that was last written or applied by order of inheritance is used for the enforcement mode, and all rules from linked GPOs are applied.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/understand-applocker-policy-design-decisions.md b/windows/keep-secure/understand-applocker-policy-design-decisions.md
index d34824f7d7..ea6833ec44 100644
--- a/windows/keep-secure/understand-applocker-policy-design-decisions.md
+++ b/windows/keep-secure/understand-applocker-policy-design-decisions.md
@@ -2,43 +2,27 @@
title: Understand AppLocker policy design decisions (Windows 10)
description: This topic for the IT professional lists the design questions, possible answers, and ramifications of the decisions when you plan a deployment of application control policies by using AppLocker within a Windows operating system environment.
ms.assetid: 3475def8-949a-4b51-b480-dc88b5c1e6e6
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Understand AppLocker policy design decisions
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional lists the design questions, possible answers, and ramifications of the decisions when you plan a deployment of application control policies by using AppLocker within a Windows operating system environment.
-
When you begin the design and planning process, you should consider the ramifications of your design choices. The resulting decisions will affect your policy deployment scheme and subsequent application control policy maintenance.
-
You should consider using AppLocker as part of your organization's application control policies if all the following are true:
-
- You have deployed or plan to deploy the supported versions of Windows in your organization. For specific operating system version requirements, see [Requirements to Use AppLocker](requirements-to-use-applocker.md).
-
- You need improved control over the access to your organization's applications and the data your users access.
-
- The number of applications in your organization is known and manageable.
-
- You have resources to test policies against the organization's requirements.
-
- You have resources to involve Help Desk or to build a self-help process for end-user application access issues.
-
- The group's requirements for productivity, manageability, and security can be controlled by restrictive policies.
-
The following questions are not in priority or sequential order. They should be considered when you deploy application control policies (as appropriate for your targeted environment).
-
### Which apps do you need to control in your organization?
-
You might need to control a limited number of apps because they access sensitive data, or you might have to exclude all applications except those that are sanctioned for business purposes. There might be certain business groups that require strict control, and others that promote independent application usage.
-
@@ -78,47 +62,27 @@ You might need to control a limited number of apps because they access sensitive
-
-
**Important**
The following list contains files or types of files that cannot be managed by AppLocker:
-
- AppLocker does not protect against running 16-bit DOS binaries in a NT Virtual DOS Machine (NTVDM). This technology allows running legacy DOS and 16-bit Windows programs on computers that are using Intel 80386 or higher when there is already another operating system running and controlling the hardware. The result is that 16-bit binaries can still run on Windows Server 2008 R2 and Windows 7 when AppLocker is configured to otherwise block binaries and libraries. If it is a requirement to prevent 16-bit applications from running, you must configure the Deny rule in the Executable rule collection for NTVDM.exe.
-
- You cannot use AppLocker to prevent code from running outside the Win32 subsystem. In particular, this applies to the (POSIX) subsystem in Windows NT. If it is a requirement to prevent applications from running in the POSIX subsystem, you must disable the subsystem.
-
- AppLocker can only control VBScript, JScript, .bat files, .cmd files and Windows PowerShell scripts. It does not control all interpreted code that runs within a host process, for example Perl scripts and macros. Interpreted code is a form of executable code that runs within a host process. For example, Windows batch files (\*.bat) run within the context of the Windows Command Host (cmd.exe). To use AppLocker to control interpreted code, the host process must call AppLocker before it runs the interpreted code, and then enforce the decision that is returned by AppLocker. Not all host processes call into AppLocker. Therefore, AppLocker cannot control every kind of interpreted code, for example Microsoft Office macros.
-
**Important**
You should configure the appropriate security settings of these host processes if you must allow them to run. For example, configure the security settings in Microsoft Office to ensure that only signed and trusted macros are loaded.
-
-
- AppLocker rules allow or prevent an app from launching. AppLocker does not control the behavior of apps after they are launched. Applications could contain flags that are passed to functions that signal AppLocker to circumvent the rules and allow another .exe or .dll file to be loaded. In practice, an app that is allowed by AppLocker could use these flags to bypass AppLocker rules and launch child processes. You must follow a process that best suits your needs to thoroughly vet each app before allowing them to run using AppLocker rules.
-
For more info, see [Security considerations for AppLocker](security-considerations-for-applocker.md).
-
-
### Comparing Classic Windows applications and Universal Windows apps for AppLocker policy design decisions
-
AppLocker policies for Universal Windows apps can only be applied to apps that are installed on computers running Windows operating systems that support Windows Store apps. However, Classic Windows applications can be controlled in Windows Server 2008 R2 and Windows 7, in addition to those computers that support Universal Windows apps. The rules for Classic Windows applications and Universal Windows apps can be enforced together. The differences you should consider for Universal Windows apps are:
-
- All Universal Windows apps can be installed by a standard user, whereas a number of Classic Windows applications require administrative credentials to install. So in an environment where most of the users are standard users, you might not need numerous exe rules, but you might want more explicit policies for packaged apps.
-
- Classic Windows applications can be written to change the system state if they run with administrative credentials. Most Universal Windows apps cannot change the system state because they run with limited permissions. When you design your AppLocker policies, it is important to understand whether an app that you are allowing can make system-wide changes.
-
- Universal Windows apps can be acquired through the Store, or they can be side-loaded by using Windows PowerShell cmdlets. If you use Windows PowerShell cmdlets, a special Enterprise license is required to acquire Universal Windows apps. Classic Windows applications can be acquired through traditional means, such as through software vendors or retail distribution.
-
AppLocker controls Universal Windows apps and Classic Windows applications by using different rule collections. You have the choice to control Universal Windows apps, Classic Windows applications, or both.
-
For more info, see [Packaged apps and packaged app installer rules in AppLocker](packaged-apps-and-packaged-app-installer-rules-in-applocker.md).
-
### How do you currently control app usage in your organization?
-
Most organizations have evolved app control policies and methods over time. With heightened security concerns and an emphasis on tighter IT control over desktop use, your organization might decide to consolidate app control practices or design a comprehensive application control scheme. AppLocker includes improvements over SRP in the architecture and management of application control policies.
-
@@ -153,13 +117,9 @@ Most organizations have evolved app control policies and methods over time. With
-
-
### Which Windows desktop and server operating systems are running in your organization?
-
If your organization supports multiple Windows operating systems, app control policy planning becomes more complex. Your initial design decisions should consider the security and management priorities of applications that are installed on each version of the operating system.
-
@@ -210,13 +170,9 @@ If your organization supports multiple Windows operating systems, app control po
-
-
### Are there specific groups in your organization that need customized application control policies?
-
Most business groups or departments have specific security requirements that pertain to data access and the applications used to access that data. You should consider the scope of the project for each group and the group’s priorities before you deploy application control policies for the entire organization.
-
@@ -241,13 +197,9 @@ Most business groups or departments have specific security requirements that per
-
-
### Does your IT department have resources to analyze application usage, and to design and manage the policies?
-
The time and resources that are available to you to perform the research and analysis can affect the detail of your plan and processes for continuing policy management and maintenance.
-
@@ -270,13 +222,9 @@ The time and resources that are available to you to perform the research and ana
-
-
### Does your organization have Help Desk support?
-
Preventing your users from accessing known, deployed, or personal applications will initially cause an increase in end-user support. It will be necessary to address the various support issues in your organization so security policies are followed and business workflow is not hampered.
-
@@ -299,13 +247,9 @@ Preventing your users from accessing known, deployed, or personal applications w
-
-
### Do you know what applications require restrictive policies?
-
Any successful application control policy implementation is based on your knowledge and understanding of app usage within the organization or business group. In addition, the application control design is dependent on the security requirements for data and the apps that access that data.
-
@@ -328,13 +272,9 @@ Any successful application control policy implementation is based on your knowle
-
-
### How do you deploy or sanction applications (upgraded or new) in your organization?
-
Implementing a successful application control policy is based on your knowledge and understanding of application usage within the organization or business group. In addition, the application control design is dependent on the security requirements for data and the applications that access that data. Understanding the upgrade and deployment policy will help shape the construction of the application control policies.
-
@@ -361,13 +301,9 @@ Implementing a successful application control policy is based on your knowledge
-
-
### Does your organization already have SRP deployed?
-
Although SRP and AppLocker have the same goal, AppLocker is a major revision of SRP.
-
@@ -397,13 +333,9 @@ Although SRP and AppLocker have the same goal, AppLocker is a major revision of
-
-
### What are your organization's priorities when implementing application control policies?
-
Some organizations will benefit from application control policies as shown by an increase in productivity or conformance, while others will be hindered in performing their duties. Prioritize these aspects for each group to allow you to evaluate the effectiveness of AppLocker.
-
@@ -430,13 +362,9 @@ Some organizations will benefit from application control policies as shown by an
-
-
### How are apps currently accessed in your organization?
-
AppLocker is very effective for organizations that have application restriction requirements if they have environments with a simple topography and application control policy goals that are straightforward. For example, AppLocker can benefit an environment where non-employees have access to computers that are connected to the organizational network, such as a school or library. Large organizations also benefit from AppLocker policy deployment when the goal is to achieve a detailed level of control on the desktop computers with a relatively small number of applications to manage, or when the applications are manageable with a small number of rules.
-
@@ -468,13 +396,9 @@ AppLocker is very effective for organizations that have application restriction
-
-
### Is the structure in Active Directory Domain Services based on the organization's hierarchy?
-
Designing application control policies based on an organizational structure that is already built into Active Directory Domain Services (AD DS) is easier than converting the existing structure to an organizational structure. Because the effectiveness of application control policies is dependent on the ability to update policies, consider what organizational work needs to be accomplished before deployment begins.
-
@@ -497,23 +421,10 @@ Designing application control policies based on an organizational structure that
-
-
## Record your findings
-
-
The next step in the process is to record and analyze your answers to the preceding questions. If AppLocker is the right solution for your goals, tyou can set your application control policy objectives and plan your AppLocker rules. This process culminates in creating your planning document.
-
- For info about setting your policy goals, see [Determine your application control objectives](determine-your-application-control-objectives.md).
-
- For info about creating your planning document, see [Create your AppLocker planning document](create-your-applocker-planning-document.md).
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/understand-applocker-rules-and-enforcement-setting-inheritance-in-group-policy.md b/windows/keep-secure/understand-applocker-rules-and-enforcement-setting-inheritance-in-group-policy.md
index ac54fef39f..c4438ba57b 100644
--- a/windows/keep-secure/understand-applocker-rules-and-enforcement-setting-inheritance-in-group-policy.md
+++ b/windows/keep-secure/understand-applocker-rules-and-enforcement-setting-inheritance-in-group-policy.md
@@ -2,63 +2,34 @@
title: Understand AppLocker rules and enforcement setting inheritance in Group Policy (Windows 10)
description: This topic for the IT professional describes how application control policies configured in AppLocker are applied through Group Policy.
ms.assetid: c1c5a3d3-540a-4698-83b5-0dab5d27d871
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Understand AppLocker rules and enforcement setting inheritance in Group Policy
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional describes how application control policies configured in AppLocker are applied through Group Policy.
-
Rule enforcement is applied only to collections of rules, not individual rules. AppLocker divides the rules into the following collections: executable files, Windows Installer files, scripts, packaged apps and packaged app installers, and DLL files. The options for rule enforcement are **Not configured**, **Enforce rules**, or **Audit only**. Together, all AppLocker rule collections compose the application control policy, or AppLocker policy.
-
Group Policy merges AppLocker policy in two ways:
-
- **Rules.** Group Policy does not overwrite or replace rules that are already present in a linked Group Policy Object (GPO). For example, if the current GPO has 12 rules and a linked GPO has 50 rules, 62 rules are applied to all computers that receive the AppLocker policy.
-
**Important**
When determining whether a file is permitted to run, AppLocker processes rules in the following order:
-
1. **Explicit deny.** An administrator created a rule to deny a file.
-
2. **Explicit allow.** An administrator created a rule to allow a file.
-
3. **Implicit deny.** This is also called the default deny because all files that are not affected by an allow rule are automatically blocked.
-
-
- **Enforcement settings.** The last write to the policy is applied. For example, if a higher-level GPO has the enforcement setting configured to **Enforce rules** and the closest GPO has the setting configured to **Audit only**, **Audit only** is enforced. If enforcement is not configured on the closest GPO, the setting from the closest linked GPO will be enforced.
-
Because a computer's effective policy includes rules from each linked GPO, duplicate rules or conflicting rules could be enforced on a user's computer. Therefore, you should carefully plan your deployment to ensure that only rules that are necessary are present in a GPO.
-
The following figure demonstrates how AppLocker rule enforcement is applied through linked GPOs.
-
-
In the preceding illustration, note that all GPOs linked to Contoso are applied in order as configured. The rules that are not configured are also applied. For example, the result of the Contoso and Human Resources GPOs is 33 rules enforced, as shown in the client HR-Term1. The Human Resources GPO contains 10 non-configured rules. When the rule collection is configured for **Audit only**, no rules are enforced.
-
When constructing the Group Policy architecture for applying AppLocker policies, it is important to remember:
-
- Rule collections that are not configured will be enforced.
-
- Group Policy does not overwrite or replace rules that are already present in a linked GPO.
-
- AppLocker processes the explicit deny rule configuration before the allow rule configuration.
-
- For rule enforcement, the last write to the GPO is applied.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/understand-the-applocker-policy-deployment-process.md b/windows/keep-secure/understand-the-applocker-policy-deployment-process.md
index 71a486b003..225dc8c0c2 100644
--- a/windows/keep-secure/understand-the-applocker-policy-deployment-process.md
+++ b/windows/keep-secure/understand-the-applocker-policy-deployment-process.md
@@ -2,45 +2,24 @@
title: Understand the AppLocker policy deployment process (Windows 10)
description: This planning and deployment topic for the IT professional describes the process for using AppLocker when deploying application control policies.
ms.assetid: 4cfd95c1-fbd3-41fa-8efc-d23c1ea6fb16
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Understand the AppLocker policy deployment process
-
-
**Applies to**
-
- Windows 10
-
This planning and deployment topic for the IT professional describes the process for using AppLocker when deploying application control policies.
-
To successfully deploy AppLocker policies, you need to identify your application control objectives and construct the policies for those objectives. The key to the process is taking an accurate inventory of your organization's applications, which requires investigation of all the targeted business groups. With an accurate inventory, you can create rules and set enforcement criteria that will allow the organization to use the required applications and allow the IT department to manage a controlled set of applications.
-
The following diagram shows the main points in the design, planning, and deployment process for AppLocker.
-
-
## Resources to support the deployment process
-
-
The following topics contain information about designing, planning, deploying, and maintaining AppLocker policies:
-
- For info about the AppLocker policy design and planning requirements and process, see [AppLocker Design Guide](applocker-policies-design-guide.md).
-
- For info about the AppLocker policy deployment requirements and process, see [AppLocker deployment guide](applocker-policies-deployment-guide.md).
-
- For info about AppLocker policy maintenance and monitoring, see [Administer AppLocker](administer-applocker.md).
-
- For info about AppLocker policy architecture, components, and processing, see [AppLocker technical reference](applocker-technical-reference.md).
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/understanding-applocker-allow-and-deny-actions-on-rules.md b/windows/keep-secure/understanding-applocker-allow-and-deny-actions-on-rules.md
index aba279a4c9..30f5de5bcc 100644
--- a/windows/keep-secure/understanding-applocker-allow-and-deny-actions-on-rules.md
+++ b/windows/keep-secure/understanding-applocker-allow-and-deny-actions-on-rules.md
@@ -2,32 +2,21 @@
title: Understanding AppLocker allow and deny actions on rules (Windows 10)
description: This topic explains the differences between allow and deny actions on AppLocker rules.
ms.assetid: ea0370fa-2086-46b5-a0a4-4a7ead8cbed9
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Understanding AppLocker allow and deny actions on rules
-
-
**Applies to**
-
- Windows 10
-
This topic explains the differences between allow and deny actions on AppLocker rules.
-
## Allow action versus deny action on rules
-
-
Unlike Software Restriction Policies (SRP), each AppLocker rule collection functions as an allowed list of files. Only the files that are listed within the rule collection are allowed to run. This configuration makes it easier to determine what will occur when an AppLocker rule is applied.
-
You can also create rules that use the deny action. When applying rules, AppLocker first checks whether any explicit deny actions are specified in the rule list. If you have denied a file from running in a rule collection, the deny action will take precedence over any allow action, regardless of which Group Policy Object (GPO) the rule was originally applied in. Because AppLocker functions as an allowed list by default, if no rule explicitly allows or denies a file from running, AppLocker's default deny action will block the file.
-
### Deny rule considerations
-
Although you can use AppLocker to create a rule to allow all files to run and then use rules to deny specific files, this configuration is not recommended. The deny action is generally less secure than the allow action because a malicious user could modify the file to invalidate the rule. Deny actions can also be circumvented. For example, if you configure a deny action for a file or folder path, the user can still run the file from any other path. The following table details security concerns for different rule conditions with deny actions.
-
@@ -54,24 +43,11 @@ Although you can use AppLocker to create a rule to allow all files to run and th
-
-
**Important**
If you choose to use the deny action on rules, you must ensure that you first create rules that allow the Windows system files to run. AppLocker enforces rules for allowed applications by default, so after one or more rules have been created for a rule collection (affecting the Windows system files), only the apps that are listed as being allowed will be permitted to run. Therefore, creating a single rule in a rule collection to deny a malicious file from running will also deny all other files on the computer from running.
-
-
## Related topics
-
-
[How AppLocker works](how-applocker-works-techref.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/understanding-applocker-default-rules.md b/windows/keep-secure/understanding-applocker-default-rules.md
index 8cfd4ceadc..cf10480b26 100644
--- a/windows/keep-secure/understanding-applocker-default-rules.md
+++ b/windows/keep-secure/understanding-applocker-default-rules.md
@@ -2,41 +2,26 @@
title: Understanding AppLocker default rules (Windows 10)
description: This topic for IT professional describes the set of rules that can be used to ensure that required Windows system files are allowed to run when the policy is applied.
ms.assetid: bdb03d71-05b7-41fb-96e3-a289ce1866e1
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Understanding AppLocker default rules
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professional describes the set of rules that can be used to ensure that required Windows system files are allowed to run when the policy is applied.
-
AppLocker includes default rules for each rule collection. These rules are intended to help ensure that the files that are required for Windows to operate properly are allowed in an AppLocker rule collection.
-
**Important**
You can use the default rules as a template when creating your own rules. However, these rules are only meant to function as a starter policy when you are first testing AppLocker rules so that the system files in the Windows folders will be allowed to run.
-
-
If you require additional app security, you might need to modify the rules created from the built-in default rule collection. For example, the default rule to allow all users to run .exe files in the Windows folder is based on a path condition that allows all files within the Windows folder to run. The Windows folder contains a Temp subfolder to which the Users group is given the following permissions:
-
- Traverse Folder/Execute File
-
- Create Files/Write Data
-
- Create Folders/Append Data
-
These permissions settings are applied to this folder for app compatibility. However, because any user can create files in this location, allowing applications to be run from this location might conflict with your organization's security policy.
-
## In this section
-
-
@@ -71,19 +56,8 @@ These permissions settings are applied to this folder for app compatibility. How
-
-
## Related topics
-
-
[How AppLocker works](how-applocker-works-techref.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/understanding-applocker-rule-behavior.md b/windows/keep-secure/understanding-applocker-rule-behavior.md
index e641befe4b..b065509210 100644
--- a/windows/keep-secure/understanding-applocker-rule-behavior.md
+++ b/windows/keep-secure/understanding-applocker-rule-behavior.md
@@ -2,44 +2,24 @@
title: Understanding AppLocker rule behavior (Windows 10)
description: This topic describes how AppLocker rules are enforced by using the allow and deny options in AppLocker.
ms.assetid: 3e2738a3-8041-4095-8a84-45c1894c97d0
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Understanding AppLocker rule behavior
-
-
**Applies to**
-
- Windows 10
-
This topic describes how AppLocker rules are enforced by using the allow and deny options in AppLocker.
-
If no AppLocker rules for a specific rule collection exist, all files with that file format are allowed to run. However, when an AppLocker rule for a specific rule collection is created, only the files explicitly allowed in a rule are permitted to run. For example, if you create an executable rule that allows .exe files in *%SystemDrive%\\FilePath* to run, only executable files located in that path are allowed to run.
-
A rule can be configured to use either an allow or deny action:
-
- **Allow**. You can specify which files are allowed to run in your environment and for which users or groups of users. You can also configure exceptions to identify files that are excluded from the rule.
-
- **Deny**. You can specify which files are not allowed to run in your environment and for which users or groups of users. You can also configure exceptions to identify files that are excluded from the rule.
-
**Important**
You can use a combination of allow actions and deny actions. However, we recommend using allow actions with exceptions because deny actions override allow actions in all cases. Deny actions can also be circumvented. For example, if you configure a deny action for a file or folder path, the user can still run the file from any other path.
-
-
## Related topics
-
-
[How AppLocker works](how-applocker-works-techref.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/understanding-applocker-rule-collections.md b/windows/keep-secure/understanding-applocker-rule-collections.md
index a6f772c351..950a47ebfe 100644
--- a/windows/keep-secure/understanding-applocker-rule-collections.md
+++ b/windows/keep-secure/understanding-applocker-rule-collections.md
@@ -2,52 +2,28 @@
title: Understanding AppLocker rule collections (Windows 10)
description: This topic explains the five different types of AppLocker rules used to enforce AppLocker policies.
ms.assetid: 03c05466-4fb3-4880-8d3c-0f6f59fc5579
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Understanding AppLocker rule collections
-
-
**Applies to**
-
- Windows 10
-
This topic explains the five different types of AppLocker rules used to enforce AppLocker policies.
-
An AppLocker rule collection is a set of rules that apply to one of five types:
-
- Executable files: .exe and .com
-
- Windows Installer files: .msi, mst, and .msp
-
- Scripts: .ps1, .bat, .cmd, .vbs, and .js
-
- DLLs: .dll and .ocx
-
- Packaged apps and packaged app installers: .appx
-
If you use DLL rules, a DLL allow rule has to be created for each DLL that is used by all of the allowed apps.
-
**Important**
Each app can load several DLLs, and AppLocker must check each DLL before it is allowed to run. Therefore, creating DLL rules might cause performance problems on some computers. Denying some DLLs from running can also create app compatibility problems. As a result, the DLL rule collection is not enabled by default.
-
-
For info about how to enable the DLL rule collection, see [Enable the DLL rule collection](enable-the-dll-rule-collection.md).
-
## Related topics
-
-
[How AppLocker works](how-applocker-works-techref.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/understanding-applocker-rule-condition-types.md b/windows/keep-secure/understanding-applocker-rule-condition-types.md
index 6969952dce..e6b6e8505a 100644
--- a/windows/keep-secure/understanding-applocker-rule-condition-types.md
+++ b/windows/keep-secure/understanding-applocker-rule-condition-types.md
@@ -2,73 +2,39 @@
title: Understanding AppLocker rule condition types (Windows 10)
description: This topic for the IT professional describes the three types of AppLocker rule conditions.
ms.assetid: c21af67f-60a1-4f7d-952c-a6f769c74729
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Understanding AppLocker rule condition types
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional describes the three types of AppLocker rule conditions.
-
Rule conditions are criteria that the AppLocker rule is based on. Primary conditions are required to create an AppLocker rule. The three primary rule conditions are publisher, path, and file hash.
-
**Publisher**
-
To use a publisher condition, the files must be digitally signed by the software publisher, or you must do so by using an internal certificate. Rules that are specified to the version level might have to be updated when a new version of the file is released. For more info about this rule condition, see [Understanding the publisher rule condition in AppLocker](understanding-the-publisher-rule-condition-in-applocker.md).
-
**Path**
-
Any file can be assigned this rule condition; however, because path rules specify locations within the file system, any subdirectory will also be affected by the rule (unless explicitly exempted). For more info about this rule condition, see [Understanding the path rule condition in AppLocker](understanding-the-path-rule-condition-in-applocker.md).
-
**File hash**
-
Any file can be assigned this rule condition; however, the rule must be updated each time a new version of the file is released because the hash value is unique to that the version of the file. For more info about this rule condition, see [Understanding the file hash rule condition in AppLocker](understanding-the-file-hash-rule-condition-in-applocker.md).
-
### Considerations
-
Selecting the appropriate condition for each rule depends on the overall application control policy goals of the organization, the AppLocker rule maintenance goals, and the condition of the existing (or planned) application deployment. The following questions can help you decide which rule condition to use.
-
1. Is the file digitally signed by a software publisher?
-
If the file is signed by a software publisher, we recommend that you create rules with publisher conditions. You may still create file hash and path conditions for signed files. However, if the file is not digitally signed by a software publisher, you can:
-
- Sign the file by using an internal certificate.
-
- Create a rule by using a file hash condition.
-
- Create a rule by using a path condition.
-
**Note**
To determine how many applications on a reference computer are digitally signed, you can use the **Get-AppLockerFileInformation** Windows PowerShell cmdlet for a directory of files. For example, `Get-AppLockerFileInformation –Directory C:\Windows\ -FileType EXE -recurse` displays the properties for all .exe and .com files within the Windows directory.
-
-
2. What rule condition type does your organization prefer?
-
If your organization is already using Software Restriction Policies (SRP) to restrict what files users can run, rules using file hash or path conditions are probably already in place.
-
**Note**
For a list of supported operating system versions and editions to which SRP and AppLocker rules can be applied, see [Requirements to use AppLocker](requirements-to-use-applocker.md).
-
-
## Related topics
-
-
[How AppLocker works](how-applocker-works-techref.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/understanding-applocker-rule-exceptions.md b/windows/keep-secure/understanding-applocker-rule-exceptions.md
index a5a24f0b8f..0a89f17cc7 100644
--- a/windows/keep-secure/understanding-applocker-rule-exceptions.md
+++ b/windows/keep-secure/understanding-applocker-rule-exceptions.md
@@ -2,35 +2,19 @@
title: Understanding AppLocker rule exceptions (Windows 10)
description: This topic describes the result of applying AppLocker rule exceptions to rule collections.
ms.assetid: e6bb349f-ee60-4c8d-91cd-6442f2d0eb9c
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Understanding AppLocker rule exceptions
-
-
**Applies to**
-
- Windows 10
-
This topic describes the result of applying AppLocker rule exceptions to rule collections.
-
You can apply AppLocker rules to individual users or a group of users. If you apply a rule to a group of users, all users in that group are affected by that rule. If you need to allow a subset of a user group to use an app, you can create a special rule for that subset.
-
For example, the rule "Allow Everyone to run Windows except Registry Editor" allows everyone in the organization to run Windows but does not allow anyone to run Registry Editor. The effect of this rule would prevent users such as help desk personnel from running a program that is necessary for their support tasks. To resolve this problem, create a second rule that applies to the Helpdesk user group: "Allow Helpdesk to run Registry Editor." If you create a deny rule that does not allow any users to run Registry Editor, the deny rule will override the second rule that allows the Helpdesk user group to run Registry Editor.
-
## Related topics
-
-
[How AppLocker works](how-applocker-works-techref.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/understanding-the-file-hash-rule-condition-in-applocker.md b/windows/keep-secure/understanding-the-file-hash-rule-condition-in-applocker.md
index d014968a92..1be8c8cc55 100644
--- a/windows/keep-secure/understanding-the-file-hash-rule-condition-in-applocker.md
+++ b/windows/keep-secure/understanding-the-file-hash-rule-condition-in-applocker.md
@@ -2,23 +2,17 @@
title: Understanding the file hash rule condition in AppLocker (Windows 10)
description: This topic explains the AppLocker file hash rule condition, the advantages and disadvantages, and how it is applied.
ms.assetid: 4c6d9af4-2b1a-40f4-8758-1a6f9f147756
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Understanding the file hash rule condition in AppLocker
-
-
**Applies to**
-
- Windows 10
-
This topic explains the AppLocker file hash rule condition, the advantages and disadvantages, and how it is applied.
-
File hash rules use a system-computed cryptographic hash of the identified file. For files that are not digitally signed, file hash rules are more secure than path rules. The following table describes the advantages and disadvantages of the file hash condition.
-
@@ -37,21 +31,9 @@ File hash rules use a system-computed cryptographic hash of the identified file.
-
-
For an overview of the three types of AppLocker rule conditions and explanations of the advantages and disadvantages of each, see [Understanding AppLocker rule condition types](understanding-applocker-rule-condition-types.md).
-
## Related topics
-
-
[How AppLocker works](how-applocker-works-techref.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/understanding-the-path-rule-condition-in-applocker.md b/windows/keep-secure/understanding-the-path-rule-condition-in-applocker.md
index 80c9494b0b..2adb70d6c6 100644
--- a/windows/keep-secure/understanding-the-path-rule-condition-in-applocker.md
+++ b/windows/keep-secure/understanding-the-path-rule-condition-in-applocker.md
@@ -2,25 +2,18 @@
title: Understanding the path rule condition in AppLocker (Windows 10)
description: This topic explains the AppLocker path rule condition, the advantages and disadvantages, and how it is applied.
ms.assetid: 3fa54ded-4466-4f72-bea4-2612031cad43
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Understanding the path rule condition in AppLocker
-
-
**Applies to**
-
- Windows 10
-
This topic explains the AppLocker path rule condition, the advantages and disadvantages, and how it is applied.
-
The path condition identifies an application by its location in the file system of the computer or on the network.
-
When creating a rule that uses a deny action, path conditions are less secure than publisher and file hash conditions for preventing access to a file because a user could easily copy the file to a different location than the location specified in the rule. Because path rules specify locations within the file system, you should ensure that there are no subdirectories that are writable by non-administrators. For example, if you create a path rule for C:\\ with the allow action, any file under that location will be allowed to run, including within users' profiles. The following table describes the advantages and disadvantages of the path condition.
-
@@ -45,15 +38,10 @@ When creating a rule that uses a deny action, path conditions are less secure th
-
-
AppLocker does not enforce rules that specify paths with short names. You should always specify the full path to a file or folder when creating path rules so that the rule will be properly enforced.
-
The asterisk (\*) wildcard character can be used within **Path** field. The asterisk (\*) character used by itself represents any path. When combined with any string value, the rule is limited to the path of the file and all the files under that path. For example, %ProgramFiles%\\Internet Explorer\\\* indicates that all files and subfolders within the Internet Explorer folder will be affected by the rule.
-
AppLocker uses path variables for well-known directories in Windows. Path variables are not environment variables. The AppLocker engine can only interpret AppLocker path variables. The following table details these path variables.
-
@@ -100,21 +88,9 @@ AppLocker uses path variables for well-known directories in Windows. Path variab
-
-
For an overview of the three types of AppLocker rule conditions and explanations of the advantages and disadvantages of each, see [Understanding AppLocker rule condition types](understanding-applocker-rule-condition-types.md).
-
## Related topics
-
-
[How AppLocker works](how-applocker-works-techref.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/understanding-the-publisher-rule-condition-in-applocker.md b/windows/keep-secure/understanding-the-publisher-rule-condition-in-applocker.md
index 263db51284..053ee2e59c 100644
--- a/windows/keep-secure/understanding-the-publisher-rule-condition-in-applocker.md
+++ b/windows/keep-secure/understanding-the-publisher-rule-condition-in-applocker.md
@@ -2,25 +2,18 @@
title: Understanding the publisher rule condition in AppLocker (Windows 10)
description: This topic explains the AppLocker publisher rule condition, what controls are available, and how it is applied.
ms.assetid: df61ed8f-a97e-4644-9d0a-2169f18c1c4f
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Understanding the publisher rule condition in AppLocker
-
-
**Applies to**
-
- Windows 10
-
This topic explains the AppLocker publisher rule condition, what controls are available, and how it is applied.
-
Publisher conditions can be made only for files that are digitally signed; this condition identifies an app based on its digital signature and extended attributes. The digital signature contains information about the company that created the app (the publisher). The extended attributes, which are obtained from the binary resource, contain the name of the product that the app is part of and the version number of the app. The publisher may be a software development company, such as Microsoft, or the Information Technology department of your organization.
-
Publisher conditions are easier to maintain than file hash conditions and are generally more secure than path conditions. Rules that are specified to the version level might have to be updated when a new version of the file is released. The following table describes the advantages and disadvantages of the publisher condition.
-
@@ -47,35 +40,20 @@ Publisher conditions are easier to maintain than file hash conditions and are ge
-
-
Wildcard characters can be used as values in the publisher rule fields according to the following specifications:
-
- **Publisher**
-
The asterisk (\*) character used by itself represents any publisher. When combined with any string value, the rule is limited to the publisher with a value in the signed certificate that matches the character string. In other words, the asterisk is not treated as a wildcard character if used with other characters in this field. For example, using the characters "M\*" limits the publisher name to only a publisher with the name "M\*." Using the characters "\*x\*" limits the publisher name only to the name “\*x\*”. A question mark (?) is not a valid wildcard character in this field.
-
- **Product name**
-
The asterisk (\*) character used by itself represents any product name. When combined with any string value, the rule is limited to the product of the publisher with a value in the signed certificate that matches the character string. In other words, the asterisk is not treated as a wildcard character if used with other characters in this field. A question mark (?) is not a valid wildcard character in this field.
-
- **File name**
-
Either the asterisk (\*) or question mark (?) characters used by themselves represent any and all file names. When combined with any string value, the string is matched with any file name containing that string.
-
- **File version**
-
The asterisk (\*) character used by itself represents any file version. If you want to limit the file version to a specific version or as a starting point, you can state the file version and then use the following options to apply limits:
-
- **Exactly**. The rule applies only to this version of the app
-
- **And above**. The rule applies to this version and all later versions.
-
- **And Below**. The rule applies to this version and all earlier versions.
-
The following table describes how a publisher condition is applied.
-
@@ -125,21 +103,9 @@ The following table describes how a publisher condition is applied.
-
-
For an overview of the three types of AppLocker rule conditions and explanations of the advantages and disadvantages of each, see [Understanding AppLocker rule condition types](understanding-applocker-rule-condition-types.md).
-
## Related topics
-
-
[How AppLocker works](how-applocker-works-techref.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/use-a-reference-computer-to-create-and-maintain-applocker-policies.md b/windows/keep-secure/use-a-reference-computer-to-create-and-maintain-applocker-policies.md
index 070851aa6b..4b888e3d71 100644
--- a/windows/keep-secure/use-a-reference-computer-to-create-and-maintain-applocker-policies.md
+++ b/windows/keep-secure/use-a-reference-computer-to-create-and-maintain-applocker-policies.md
@@ -2,125 +2,62 @@
title: Use a reference device to create and maintain AppLocker policies (Windows 10)
description: This topic for the IT professional describes the steps to create and maintain AppLocker policies by using a reference computer.
ms.assetid: 10c3597f-f44c-4c8e-8fe5-105d4ac016a6
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Use a reference device to create and maintain AppLocker policies
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional describes the steps to create and maintain AppLocker policies by using a reference computer.
-
## Background and prerequisites
-
-
An AppLocker reference device is a baseline device you can use to configure policies and can subsequently be used to maintain AppLocker policies. For the procedure to configure a reference device, see [Configure the AppLocker reference device](configure-the-appLocker-reference-device.md).
-
An AppLocker reference device that is used to create and maintain AppLocker policies should contain the corresponding apps for each organizational unit (OU) to mimic your production environment.
-
**Important**
The reference device must be running one of the supported editions of Windows. For information about operating system requirements for AppLocker, see [Requirements to use AppLocker](requirements-to-use-applocker.md).
-
-
You can perform AppLocker policy testing on the reference device by using the **Audit only** enforcement setting or Windows PowerShell cmdlets. You can also use the reference device as part of a testing configuration that includes policies that are created by using Software Restriction Policies.
-
## Step 1: Automatically generate rules on the reference device
-
-
With AppLocker, you can automatically generate rules for all files within a folder. AppLocker scans the specified folder and creates the condition types that you choose for each file in that folder. For the procedure to do this, see [Run the Automatically Generate Rules wizard](run-the-automatically-generate-rules-wizard.md).
-
**Note**
If you run this wizard to create your first rules for a Group Policy Object (GPO), after you complete the wizard, you will be prompted to create the default rules, which allow critical system files to run. You can edit the default rules at any time. If your organization has decided to edit the default rules or create custom rules to allow the Windows system files to run, ensure that you delete the default rules after you replace them with your custom rules.
-
-
## Step 2: Create the default rules on the reference device
-
-
AppLocker includes default rules for each rule collection. These rules are intended to help ensure that the files that are required for Windows to operate properly are allowed in an AppLocker rule collection. You must run the default rules for each rule collection. For info about default rules and considerations for using them, see [Understanding AppLocker default rules](understanding-applocker-default-rules.md). For the procedure to create default rules, see [Create AppLocker default rules](create-applocker-default-rules.md).
-
**Important**
You can use the default rules as a template when you create your own rules. This allows files within the Windows directory to run. However, these rules are only meant to function as a starter policy when you are first testing AppLocker rules.
-
-
## Step 3: Modify rules and the rule collection on the reference device
-
-
If AppLocker policies are currently running in your production environment, export the policies from the corresponding GPOs and save them to the reference device. For the procedure to do this, see [Export an AppLocker policy from a GPO](export-an-applocker-policy-from-a-gpo.md). If no AppLocker policies have been deployed, create the rules and develop the policies by using the following procedures:
-
- [Create a rule that uses a publisher condition](create-a-rule-that-uses-a-publisher-condition.md)
-
- [Create a rule that uses a file hash condition](create-a-rule-that-uses-a-file-hash-condition.md)
-
- [Create a rule that uses a path condition](create-a-rule-that-uses-a-path-condition.md)
-
- [Edit AppLocker rules](edit-applocker-rules.md)
-
- [Add exceptions for an AppLocker rule](configure-exceptions-for-an-applocker-rule.md)
-
- [Delete an AppLocker rule](delete-an-applocker-rule.md)
-
- [Enable the DLL rule collection](enable-the-dll-rule-collection.md)
-
- [Enforce AppLocker rules](enforce-applocker-rules.md)
-
## Step 4: Test and update AppLocker policy on the reference device
-
-
You should test each set of rules to ensure that they perform as intended. The **Test-AppLockerPolicy** Windows PowerShell cmdlet can be used to determine whether any of the rules in your rule collection will be blocked on your reference device. Perform the steps on each reference device that you used to define the AppLocker policy. Ensure that the reference device is joined to the domain and that it is receiving the AppLocker policy from the appropriate GPO. Because AppLocker rules are inherited from linked GPOs, you should deploy all of the rules to simultaneously test all of your test GPOs. Use the following procedures to complete this step:
-
- [Test an AppLocker Policy with Test-AppLockerPolicy](http://technet.microsoft.com/library/ee791772(WS.10).aspx)
-
- [Discover the Effect of an AppLocker Policy](http://technet.microsoft.com/library/ee791823(WS.10).aspx)
-
**Caution**
If you have set the enforcement setting on the rule collection to **Enforce rules** or you have not configured the rule collection, the policy will be implemented when the GPO is updated in the next step. If you have set the enforcement setting on the rule collection to **Audit only**, application access events are written to the AppLocker log, and the policy will not take effect.
-
-
## Step 5: Export and import the policy into production
-
-
When the AppLocker policy has been tested successfully, it can be imported into the GPO (or imported into individual computers that are not managed by Group Policy) and checked for its intended effectiveness. To do this, perform the following procedures:
-
- [Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md)
-
- [Import an AppLocker policy into a GPO](import-an-applocker-policy-into-a-gpo.md) or
-
- [Discover the Effect of an AppLocker Policy](http://technet.microsoft.com/library/ee791823(WS.10).aspx)
-
If the AppLocker policy enforcement setting is **Audit only** and you are satisfied that the policy is fulfilling your intent, you can change it to **Enforce rules**. For info about how to change the enforcement setting, see [Configure an AppLocker policy for enforce rules](configure-an-applocker-policy-for-enforce-rules.md).
-
## Step 6: Monitor the effect of the policy in production
-
-
If additional refinements or updates are necessary after a policy is deployed, use the appropriate following procedures to monitor and update the policy:
-
- [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md)
-
- [Edit an AppLocker policy](edit-an-applocker-policy.md)
-
- [Refresh an AppLocker policy](refresh-an-applocker-policy.md)
-
## See also
-
-
[Deploy the AppLocker policy into production](deploy-the-applocker-policy-into-production.md)
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/use-applocker-and-software-restriction-policies-in-the-same-domain.md b/windows/keep-secure/use-applocker-and-software-restriction-policies-in-the-same-domain.md
index 973405d6cf..01e857dfe3 100644
--- a/windows/keep-secure/use-applocker-and-software-restriction-policies-in-the-same-domain.md
+++ b/windows/keep-secure/use-applocker-and-software-restriction-policies-in-the-same-domain.md
@@ -2,28 +2,19 @@
title: Use AppLocker and Software Restriction Policies in the same domain (Windows 10)
description: This topic for IT professionals describes concepts and procedures to help you manage your application control strategy using Software Restriction Policies and AppLocker.
ms.assetid: 2b7e0cec-df62-49d6-a2b7-6b8e30180943
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Use AppLocker and Software Restriction Policies in the same domain
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals describes concepts and procedures to help you manage your application control strategy using Software Restriction Policies and AppLocker.
-
## Using AppLocker and Software Restriction Policies in the same domain
-
-
AppLocker is supported on systems running Windows 7 and above. Software Restriction Policies (SRP) is supported on systems running Windows Vista or earlier. You can continue to use SRP for application control on your pre-Windows 7 computers, but use AppLocker for computers running Windows Server 2008 R2, Windows 7 and later. It is recommended that you author AppLocker and SRP rules in separate GPOs and target the GPO with SRP policies to systems running Windows Vista or earlier. When both SRP and AppLocker policies are applied to computers running Windows Server 2008 R2, Windows 7 and later, the SRP policies are ignored.
-
The following table compares the features and functions of Software Restriction Policies (SRP) and AppLocker.
-
@@ -157,14 +148,6 @@ The following table compares the features and functions of Software Restriction
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/use-the-applocker-windows-powershell-cmdlets.md b/windows/keep-secure/use-the-applocker-windows-powershell-cmdlets.md
index 22eddb11d1..4ccedff7ca 100644
--- a/windows/keep-secure/use-the-applocker-windows-powershell-cmdlets.md
+++ b/windows/keep-secure/use-the-applocker-windows-powershell-cmdlets.md
@@ -2,58 +2,30 @@
title: Use the AppLocker Windows PowerShell cmdlets (Windows 10)
description: This topic for IT professionals describes how each AppLocker Windows PowerShell cmdlet can help you administer your AppLocker application control policies.
ms.assetid: 374e029c-5c0a-44ab-a57a-2a9dd17dc57d
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Use the AppLocker Windows PowerShell cmdlets
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals describes how each AppLocker Windows PowerShell cmdlet can help you administer your AppLocker application control policies.
-
## AppLocker Windows PowerShell cmdlets
-
-
The five AppLocker cmdlets are designed to streamline the administration of an AppLocker policy. They can be used to help create, test, maintain, and troubleshoot an AppLocker policy. The cmdlets are intended to be used in conjunction with the AppLocker user interface that is accessed through the Microsoft Management Console (MMC) snap-in extension to the Local Security Policy snap-in and Group Policy Management Console.
-
To edit or update a Group Policy Object (GPO) by using the AppLocker cmdlets, you must have Edit Setting permission. By default, members of the **Domain Admins** group, the **Enterprise Admins** group, and the **Group Policy Creator Owners** group have this permission. To perform tasks by using the Local Security policy snap-in, you must be a member of the local **Administrators** group, or equivalent, on the computer.
-
### Retrieve application information
-
The [Get-AppLockerFileInformation](http://technet.microsoft.com/library/hh847209.aspx) cmdlet retrieves the AppLocker file information from a list of files or from an event log. File information that is retrieved can include publisher information, file hash information, and file path information. File information from an event log may not contain all of these fields. Files that are not signed do not have any publisher information.
-
### Set AppLocker policy
-
The [Set-AppLockerPolicy](http://technet.microsoft.com/library/hh847212.aspx) cmdlet sets the specified GPO to contain the specified AppLocker policy. If no Lightweight Directory Access Protocol (LDAP) is specified, the local GPO is the default.
-
### Retrieve an AppLocker policy
-
The [Get-AppLockerPolicy](http://technet.microsoft.com/library/hh847214.aspx) cmdlet gets the AppLocker policy from the local GPO, from a specified GPO, or from the effective AppLocker policy on the device. The output of the AppLocker policy is an AppLockerPolicy object or an XML-formatted string.
-
### Generate rules for a given user or group
-
The [New-AppLockerPolicy](http://technet.microsoft.com/library/hh847211.aspx) cmdlet uses a list of file information to automatically generate rules for a given user or group. It can generate rules based on publisher, hash, or path information. Use **Get-AppLockerFileInformation** to create the list of file information.
-
### Test the AppLocker Policy against a file set
-
The [Test-AppLockerPolicy](http://technet.microsoft.com/library/hh847213.aspx) cmdlet uses the specified AppLocker policy to test whether a specified list of files are allowed to run or not on the local device for a specific user.
-
## Additional resources
-
-
- For steps to perform other AppLocker policy tasks, see [Administer AppLocker](administer-applocker.md).
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/use-windows-event-forwarding-to-assist-in-instrusion-detection.md b/windows/keep-secure/use-windows-event-forwarding-to-assist-in-instrusion-detection.md
index 402e4a6ddb..cc7a0adbb4 100644
--- a/windows/keep-secure/use-windows-event-forwarding-to-assist-in-instrusion-detection.md
+++ b/windows/keep-secure/use-windows-event-forwarding-to-assist-in-instrusion-detection.md
@@ -2,376 +2,202 @@
title: Use Windows Event Forwarding to help with intrusion detection (Windows 10)
description: Learn about an approach to collect events from devices in your organization. This article talks about events in both normal operations and when an intrusion is suspected.
ms.assetid: 733263E5-7FD1-45D2-914A-184B9E3E6A3F
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: tedhardyMSFT
---
-
# Use Windows Event Forwarding to help with intrusion detection
-
-
**Applies to**
-
- Windows 10
-
Learn about an approach to collect events from devices in your organization. This article talks about events in both normal operations and when an intrusion is suspected.
-
Windows Event Forwarding (WEF) reads any operational or administrative event log on a device in your organization and forwards the events you choose to a Windows Event Collector (WEC) server.
-
To accomplish this, there are two different of subscriptions published to client devices - the Baseline subscription and the suspect subscription. The Baseline subscription enrolls all devices in your organization, and a Suspect subscription only includes devices that have been added by you. The Suspect subscription collects additional events to help build context for system activity and can quickly be updated to accommodate new events and/or scenarios as needed without impacting baseline operations.
-
This implementation helps differentiate where events are ultimately stored. Baseline events can be sent to devices with online analytical capability, such as Security Event Manager (SEM), while also sending events to a MapReduce system, such as HDInsight or Hadoop, for long-term storage and deeper analysis. Events from the Suspect subscription are sent directly to a MapReduce system due to volume and lower signal/noise ratio, they are largely used for host forensic analysis.
-
An SEM’s strength lies in being able to inspect, correlate events, and generate alerts for known patterns manner and alert security staff at machine speed.
-
A MapReduce system has a longer retention time (years versus months for an SEM), larger ingress ability (hundreds of terabytes per day), and the ability to perform more complex operations on the data like statistical and trend analysis, pattern clustering analysis, or apply Machine Learning algorithms.
-
Here's an approximate scaling guide for WEF events:
-
| Events/second range | Data store |
|---------------------|----------------------------|
| 0 - 5,000 | SQL or SEM |
| 5,000 - 50,000 | SEM |
| 50,000+ | Hadoop/HDInsight/Data Lake |
-
-
Event generation on a device must be enabled either separately or as part of the GPO for the baseline WEF implementation, including enabling of disabled event logs and setting channel permissions. For more info, see [Appendix C - Event channel settings (enable and channel access) methods](#bkmk-appendixc). This is because WEF is a passive system with regards to the event log. It cannot change the size of event log files, enable disabled event channels, change channel permissions, or adjust a security audit policy. WEF only queries event channels for existing events. Additionally, having event generation already occurring on a device allows for more complete event collection building a complete history of system activity. Otherwise, you'll be limited to the speed of GPO and WEF subscription refresh cycles to make changes to what is being generated on the device. On modern devices, enabling additional event channels and expanding the size of event log files has not resulted in noticeable performance differences.
-
For the minimum recommended audit policy and registry system ACL settings, see [Appendix A - Minimum recommended minimum audit policy](#bkmk-appendixa) and [Appendix B - Recommended minimum registry system ACL policy](#bkmk-appendixb).
-
**Note**
These are only minimum values need to meet what the WEF subscription selects.
-
-
From a WEF subscription management perspective, the event queries provided should be used in two separate subscriptions for ease of maintenance; only machines meeting specific criteria would be allowed access to the targeted subscription, this access would be determined by an algorithm or an analysts’ direction. All devices should have access to the Baseline subscription.
-
This means you would create two base subscriptions:
-
- **Baseline WEF subscription**. Events collected from all hosts, this includes some role-specific events, which will only be emitted by those machines.
- **Targeted WEF subscription**. Events collected from a limited set of hosts due to unusual activity and/or heightened awareness for those systems.
-
Each using the respective event query below. Note that for the Targeted subscription enabling the “read existing events” option should be set to true to allow collection of existing events from systems. By default, WEF subscriptions will only forward events generated after the WEF subscription was received by the client.
-
In [Appendix E – Annotated Baseline Subscription Event Query](#bkmk-appendixe) and [Appendix F – Annotated Suspect Subscription Event Query](#bkmk-appendixf), the event query XML is included when creating WEF subscriptions. These are annotated for query purpose and clarity. Individual <Query> element can be removed or edited without affecting the rest of the query.
-
### Common WEF questions
-
This section addresses common questions from IT pros and customers.
-
### Will the user notice if their machine is enabled for WEF or if WEF encounters an error?
-
The short answer is: No.
-
The longer answer is: The **Eventlog-forwardingPlugin/Operational** event channel logs the success, warning, and error events related to WEF subscriptions present on the device. Unless the user opens Event Viewer and navigates to that channel, they will not notice WEF either through resource consumption or Graphical User Interface pop-ups. Even if there is an issue with the WEF subscription, there is no user interaction or performance degradation. All success, warning, and failure events are logged to this operational event channel.
-
### Is WEF Push or Pull?
-
A WEF subscription can be configured to be push or pull, but not both. The simplest, most flexible IT deployment with the greatest scalability can be achieved by using a push, or source initiated, subscription. WEF clients are configured by using a GPO and the built-in forwarding client is activated. For pull, collector initiated, the subscription on the WEC server is pre-configured with the names of the WEF Client devices from which events are to be selected. Those clients also have to be configured ahead of time to allow the credentials used in the subscription to access their event logs remotely (normally by adding the credential to the **Event Log Readers** built-in local security group.) A useful scenario: closely monitoring a specific set of machines.
-
### Will WEF work over VPN or RAS?
-
WEF handles VPN, RAS, and DirectAccess scenarios well and will reconnect and send any accumulated backlog of events when the connection to the WEF Collector is re-established.
-
### How is client progress tracked?
-
The WEC server maintains in its registry the bookmark information and last heartbeat time for each event source for each WEF subscription. When an event source re-connects to a WEC server, the last bookmark position is sent to the device to use as a starting point to resume forwarding events. If a WEF client has no events to send, the WEF client will connect periodically to send a Heartbeat to the WEC server to indicate it is active. This heartbeat value can be individually configured for each subscription.
-
### Will WEF work in an IPv4, IPv6, or mixed IPv4/IPv6 environment?
-
Yes. WEF is transport agnostic and will work over IPv4 or IPv6.
-
### Are WEF events encrypted? I see an HTTP/HTTPS option!
-
In a domain setting, the connection used to transmit WEF events is encrypted using Kerberos, by default (with NTLM as a fallback option, which can be disabled by using a GPO). Only the WEF collector can decrypt the connection. Additionally, the connection between WEF client and WEC server is mutually authenticated regardless of authentication type (Kerberos or NTLM.) There are GPO options to force Authentication to use Kerberos Only.
-
This authentication and encryption is performed regardless if HTTP or HTTPS is selected.
-
The HTTPS option is available if certificate based authentication is used, in cases where the Kerberos based mutual authentication is not an option. The SSL certificate and provisioned client certificates are used to provide mutual authentication.
-
### Do WEF Clients have a separate buffer for events?
-
The WEF client machines local event log is the buffer for WEF for when the connection to the WEC server is lost. To increase the “buffer size”, increase the maximum file size of the specific event log file where events are being selected. For more info, see [Appendix C – Event Channel Settings (enable and Channel Access) methods](#bkmk-appendixc).
-
When the event log overwrites existing events (resulting in data loss if the device is not connected to the Event Collector), there is no notification sent to the WEF collector that events are lost from the client. Neither is there an indicator that there was a gap encountered in the event stream.
-
### What format is used for forwarded events?
-
WEF has two modes for forwarded events. The default is “Rendered Text” which includes the textual description of the event as you would see it in Event Viewer. This means that the event size is effectively doubled or tripled depending on the size of the rendered description. The alternative mode is “Events” (also sometimes referred to as “Binary” format) – which is just the event XML itself sent in binary XML format (as it would be written to the evtx file.) This is very compact and can more than double the event volume a single WEC server can accommodate.
-
A subscription “testSubscription” can be configured to use the Events format through the WECUTIL utility:
-
``` syntax
@rem required to set the DeliveryMaxItems or DeliveryMaxLatencyTime
Wecutil ss “testSubscription” /cf:Events
```
-
### How frequently are WEF events delivered?
-
Event delivery options are part of the WEF subscription configuration parameters – There are three built-in subscription delivery options: Normal, Minimize Bandwidth, and Minimize Latency. A fourth, catch-all called “Custom” is available but cannot be selected or configured through the WEF UI by using Event Ciewer. The Custom delivery option must be selected and configured using the WECUTIL.EXE command-line application. All subscription options define a maximum event count and maximum event age, if either limit is exceeded then the accumulated events are sent to the event collector.
-
This table outlines the built-in delivery options:
-
| Event delivery optimization options | Description |
|-------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Normal | This option ensures reliable delivery of events and does not attempt to conserve bandwidth. It is the appropriate choice unless you need tighter control over bandwidth usage or need forwarded events delivered as quickly as possible. It uses pull delivery mode, batches 5 items at a time and sets a batch timeout of 15 minutes. |
| Minimize bandwidth | This option ensures that the use of network bandwidth for event delivery is strictly controlled. It is an appropriate choice if you want to limit the frequency of network connections made to deliver events. It uses push delivery mode and sets a batch timeout of 6 hours. In addition, it uses a heartbeat interval of 6 hours. |
| Minimize latency | This option ensures that events are delivered with minimal delay. It is an appropriate choice if you are collecting alerts or critical events. It uses push delivery mode and sets a batch timeout of 30 seconds. |
-
-
For more info about delivery options, see [Configure Advanced Subscription Settings](http://technet.microsoft.com/library/cc749167.aspx).
-
The primary difference is in the latency which events are sent from the client. If none of the built-in options meet your requirements you can set Custom event delivery options for a given subscription from an elevated command prompt:
-
``` syntax
@rem required to set the DeliveryMaxItems or DeliveryMaxLatencyTime
Wecutil ss “SubscriptionNameGoesHere” /cm:Custom
-
@rem set DeliveryMaxItems to 1 event
Wecutil ss “SubscriptionNameGoesHere” /dmi:1
-
@rem set DeliveryMaxLatencyTime to 10 ms
Wecutil ss “SubscriptionNameGoesHere” /dmlt:10
```
-
### How do I control which devices have access to a WEF Subscription?
-
For source initiated subscriptions: Each WEF subscription on a WEC server has its own ACL for machine accounts or security groups containing machine accounts (not user accounts) that are explicitly allowed to participate in that subscription or are explicitly denied access. This ACL applies to only a single WEF subscription (since there can be multiple WEF subscriptions on a given WEC server), other WEF Subscriptions have their own separate ACL.
-
For collector initiated subscriptions: The subscription contains the list of machines from which the WEC server is to collect events. This list is managed at the WEC server, and the credentials used for the subscription must have access to read event logs from the WEF Clients – the credentials can be either the machine account or a domain account.
-
### Can a client communicate to multiple WEF Event Collectors?
-
Yes. If you desire a High-Availability environment, simply configure multiple WEC servers with the same subscription configuration and publish both WEC Server URIs to WEF clients. WEF Clients will forward events simultaneously to the configured subscriptions on the WEC servers, if they have the appropriate access.
-
### What are the WEC server’s limitations?
-
There are three factors that limit the scalability of WEC servers. The general rule for a stable WEC server on commodity hardware is “10k x 10k” – meaning, no more than 10,000 concurrently active WEF Clients per WEC server and no more than 10,000 events/second average event volume.
-
- **Disk I/O**. The WEC server does not process or validate the received event, but rather buffers the received event and then logs it to a local event log file (EVTX file). The speed of logging to the EVTX file is limited by the disk write speed. Isolating the EVTX file to its own array or using high speed disks can increase the number of events per second that a single WEC server can receive.
-
- **Network Connections**. While a WEF source does not maintain a permanent, persistent connection to the WEC server, it does not immediately disconnect after sending its events. This means that the number of WEF sources that can simultaneously connect to the WEC server is limited to the open TCP ports available on the WEC server.
-
- **Registry size**. For each unique device that connects to a WEF subscription, there is a registry key (corresponding to the FQDN of the WEF Client) created to store bookmark and source heartbeat information. If this is not pruned to remove inactive clients this set of registry keys can grow to an unmanageable size over time.
-
- When a subscription has >1000 WEF sources connect to it over its operational lifetime, also known as lifetime WEF sources, Event Viewer can become unresponsive for a few minutes when selecting the **Subscriptions** node in the left-navigation, but will function normally afterwards.
-
- At >50,000 lifetime WEF sources, Event Viewer is no longer an option and wecutil.exe (included with Windows) must be used to configure and manage subscriptions.
-
- At >100,000 lifetime WEF sources, the registry will not be readable and the WEC server will likely have to be rebuilt.
-
## Subscription information
-
-
Below lists all of the items that each subscription collects, the actual subscription XML is available in an Appendix. These are separated out into Baseline and Targeted. The intent is to subscribe all hosts to Baseline, and then enroll (and remove) hosts on an as needed basis to the Targeted subscription.
-
### Baseline subscription
-
While this appears to be the largest subscription, it really is the lowest volume on a per-device basis. (Exceptions should be allowed for unusual devices – a device performing complex developer related tasks can be expected to create an unusually high volume of process create and AppLocker events.) This subscription does not require special configuration on client devices to enable event channels or modify channel permissions.
-
The subscription is essentially a collection of query statements applied to the Event Log. This means that it is modular in nature and a given query statement can be removed or changed without impacting other query statement in the subscription. Additionally, suppress statements which filter out specific events, only apply within that query statement and are not to the entire subscription.
-
### Baseline subscription requirements
-
To gain the most value out of the baseline subscription we recommend to have the following requirements set on the device to ensure that the clients are already generating the required events to be forwarded off the system.
-
- Apply a security audit policy that is a super-set of the recommended minimum audit policy. For more info, see [Appendix A – Minimum Recommended minimum Audit Policy](#bkmk-appendixa). This ensures that the security event log is generating the required events.
-
- Apply at least an Audit-Only AppLocker policy to devices.
-
- If you are already whitelisting or blacklisting events by using AppLocker, then this requirement is met.
-
- AppLocker events contain extremely useful information, such as file hash and digital signature information for executables and scripts.
-
- Enable disabled event channels and set the minimum size for modern event files.
-
- Currently, there is no GPO template for enabling or setting the maximum size for the modern event files. This must be done by using a GPO. For more info, see [Appendix C – Event Channel Settings (enable and Channel Access) methods](#bkmk-appendixc).
-
The annotated event query can be found in the following. For more info, see [Appendix F – Annotated Baseline Subscription Event Query](#bkmk-appendixf).
-
- Anti-malware events from Microsoft Antimalware or Windows Defender. This can be configured for any given anti-malware product easily if it writes to the Windows event log.
-
- Security event log Process Create events.
-
- AppLocker Process Create events (EXE, script, packaged App installation and execution).
-
- Registry modification events. For more info, see [Appendix B – Recommended minimum Registry System ACL Policy](#bkmk-appendixb).
-
- OS startup and shutdown
-
- Startup event include operating system version, service pack level, QFE version, and boot mode.
-
- Service install
-
- Includes what the name of the service, the image path, and who installed the service.
-
- Certificate Authority audit events
-
- This is only applicable on systems with the Certificate Authority role installed.
-
- Logs certificate requests and responses.
-
- User profile events
-
- Use of a temporary profile or unable to create a user profile may indicate an intruder is interactively logging into a device but not wanting to leave a persistent profile behind.
-
- Service start failure
-
- Failure codes are localized, so you have to check the message DLL for values.
-
- Network share access events
-
- Filter out IPC$ and /NetLogon file shares, which are expected and noisy.
-
- System shutdown initiate requests
-
- Find out what initiated the restart of a device.
-
- User initiated interactive logoff event
-
- Remote Desktop Services session connect, reconnect, or disconnect.
-
- EMET events, if EMET is installed.
-
- Event forwarding plugin events
-
- For monitoring WEF subscription operations, particularly Partial Success events. This is useful for diagnosing deployment issues.
-
- Network share create and delete
-
- Enables detection of unauthorized share creation.
-
**Note** All shares are re-created when the device starts.
-
-
- Logon sessions
-
- Logon success for interactive (local and Remote Interactive/Remote Desktop)
-
- Logon success for services for non-built-in accounts, such as LocalSystem, LocalNetwork, and so on.
-
- Logon success for batch sessions
-
- Logon session close, which are logoff events for non-network sessions.
-
- Windows Error Reporting (Application crash events only)
-
- This can help detect early signs of intruder not familiar with enterprise environment using targeted malware.
- Event log service events
-
- Errors, start events, and stop events for the Windows Event Log service.
-
- Event log cleared (including the Security Event Log)
-
- This could indicate an intruder that are covering their tracks.
-
- Special privileges assigned to new logon
-
- This indicates that at the time of logon a user is either an Administrator or has the sufficient access to make themselves Administrator.
-
- Outbound Remote Desktop Services session attempts
-
- Visibility into potential beachhead for intruder
-
- System time changed
-
- SMB Client (mapped drive connections)
-
- Account credential validation
-
- Local accounts or domain accounts on domain controllers
-
- A user was added or removed from the local Administrators security group.
-
- Crypto API private key accessed
-
- Associated with signing objects using the locally stored private key.
-
- Task Scheduler task creation and delete
-
- Task Scheduler allows intruders to run code at specified times as LocalSystem.
-
- Logon with explicit credentials
-
- Detect credential use changes by intruders to access additional resources.
-
- Smartcard card holder verification events
-
- This detects when a smartcard is being used.
-
### Suspect subscription
-
This adds some possible intruder-related activity to help analyst further refine their determinations about the state of the device.
-
- Logon session creation for network sessions
-
- Enables time-series analysis of network graphs.
-
- RADIUS and VPN events
-
- Useful if you use a Microsoft IAS RADIUS/VPN implementation. It shows user-> IP address assignment with remote IP address connecting to the enterprise.
-
- Crypto API X509 object and build chain events
-
- Detects known bad certificate, CA, or sub-CA
-
- Detects unusual process use of CAPI
-
- Groups assigned to local logon
-
- Gives visibility to groups which enable account wide access
-
- Allows better planning for remediation efforts
-
- Excludes well known, built-in system accounts.
-
- Logon session exit
-
- Specific for network logon sessions.
-
- Client DNS lookup events
-
- Returns what process performed a DNS query and the results returned from the DNS server.
-
- Process exit
-
- Enables checking for processes terminating unexpectedly.
-
- Local credential validation or logon with explicit credentials
-
- Generated when the local SAM is authoritative for the account credentials being authenticated.
-
- Noisy on domain controllers
-
- On client devices this is only generated when local accounts log on.
-
- Registry modification audit events
-
- Only when a registry value is being created, modified, or deleted.
-
- Wireless 802.1x authentication
-
- Detect wireless connection with a peer MAC address
-
- Windows PowerShell logging
-
- Covers Windows PowerShell 2.0 and later and includes the Windows PowerShell 5.0 logging improvements for in-memory attacks using Windows PowerShell.
-
- Includes Windows PowerShell remoting logging
-
- User Mode Driver Framework “Driver Loaded” event
-
- Can possibly detect a USB device loading multiple device drivers. For example, a USB\_STOR device loading the keyboard or network driver.
-
## Appendix A - Minimum recommended minimum audit policy
-
-
If your organizational audit policy enables additional auditing to meet its needs, that is fine. The policy below is the minimum audit policy settings needed to enable events collected by both baseline and targeted subscriptions.
-
| Category | Subcategory | Audit settings |
|--------------------|---------------------------------|---------------------|
| Account Logon | Credential Validation | Success and Failure |
@@ -404,59 +230,30 @@ If your organizational audit policy enables additional auditing to meet its need
| System | Security State Change | Success and Failure |
| System | Security System Extension | Success and Failure |
| System | System Integrity | Success and Failure |
-
-
## Appendix B - Recommended minimum registry system ACL policy
-
-
The Run and RunOnce keys are useful for intruders and malware persistence. It allows code to be run (or run only once then removed, respectively) when a user logs into the system.
-
This can easily be extended to other Auto-Execution Start Points keys in the registry.
-
Use the following figures to see how you can configure those registry keys.
-
-
## Appendix C - Event channel settings (enable and channel access) methods
-
-
Some channels are disabled by default and have to be enabled. Others, such as Microsoft-Windows-CAPI2/Operational must have the channel access modified to allow the Event Log Readers built-in security group to read from it.
-
The recommended and most effective way to do this is to configure the baseline GPO to run a scheduled task to configure the event channels (enable, set maximum size, and adjust channel access.) This will take effect at the next GPO refresh cycle and has minimal impact on the client device.
-
The following GPO snippet performs the following:
-
- Enables the **Microsoft-Windows-Capi2/Operational** event channel.
-
- Sets the maximum file size for **Microsoft-Windows-Capi2/Operational** to 100MB.
-
- Sets the maximum file size for **Microsoft-Windows-AppLocker/EXE and DLL** to 100MB.
-
- Sets the maximum channel access for **Microsoft-Windows-Capi2/Operational** to include the built-in Event Log Readers security group.
-
- Enables the **Microsoft-Windows-DriverFrameworks-UserMode/Operational** event channel.
-
- Sets the maximum file size for **Microsoft-Windows-DriverFrameworks-UserMode/Operational** to 50MB.
-
-
## Appendix D - Minimum GPO for WEF Client configuration
-
-
Here are the minimum steps for WEF to operate:
-
1. Configure the collector URI(s).
-
2. Start the WinRM service.
-
3. Add the Network Service account to the built-in Event Log Readers security group. This allows reading from secured event channel, such as the security event channel.
-
-
## Appendix E – Annotated baseline subscription event query
-
-
``` syntax
@@ -619,10 +416,7 @@ Here are the minimum steps for WEF to operate:
```
-
## Appendix F – Annotated Suspect Subscription Event Query
-
-
``` syntax
@@ -691,25 +485,11 @@ Here are the minimum steps for WEF to operate:
```
-
## Appendix G - Online resources
-
-
You can get more info with the following links:
-
- [Event Selection](http://msdn.microsoft.com/library/aa385231(VS.85).aspx)
-
- [Event Queries and Event XML](http://msdn.microsoft.com/library/bb399427(VS.90).aspx)
-
- [Event Query Schema](http://msdn.microsoft.com/library/aa385760(VS.85).aspx)
-
- [Windows Event Collector](http://msdn.microsoft.com/library/windows/desktop/bb427443.aspx)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/user-account-control-admin-approval-mode-for-the-built-in-administrator-account.md b/windows/keep-secure/user-account-control-admin-approval-mode-for-the-built-in-administrator-account.md
index 84909d2ff2..9f31ef56eb 100644
--- a/windows/keep-secure/user-account-control-admin-approval-mode-for-the-built-in-administrator-account.md
+++ b/windows/keep-secure/user-account-control-admin-approval-mode-for-the-built-in-administrator-account.md
@@ -2,55 +2,33 @@
title: User Account Control Admin Approval Mode for the Built-in Administrator account (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the User Account Control Admin Approval Mode for the Built-in Administrator account security policy setting.
ms.assetid: d465fc27-1cd2-498b-9cf6-7ad2276e5998
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# User Account Control: Admin Approval Mode for the Built-in Administrator account
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Admin Approval Mode for the Built-in Administrator account** security policy setting.
-
## Reference
-
-
This policy setting determines the behavior of Admin Approval Mode for the built-in administrator account.
-
When the Admin Approval Mode is enabled, the local administrator account functions like a standard user account, but it has the ability to elevate privileges without logging on by using a different account. In this mode, any operation that requires elevation of privilege displays a prompt that allows the administrator to permit or deny the elevation of privilege. If Admin Approval Mode is not enabled, the built-in Administrator account logs on in Windows XP Mode, and it runs all applications by default with full administrative privileges. By default, this setting is set to **Disabled**.
-
**Note**
If a computer is upgraded from a previous version of the Windows operating system, and the administrator account is the only account on the computer, the built-in administrator account remains enabled, and this setting is also enabled.
-
-
### Possible values
-
- Enabled
-
The built-in administrator account logs on in Admin Approval Mode so that any operation that requires elevation of privilege displays a prompt that provides the administrator the option to permit or deny the elevation of privilege.
-
- Disabled
-
The built-in administrator account logs on in Windows XP Mode, and it runs all applications by default with full administrative privileges.
-
### Best practices
-
- Do not enable the built-in administrator account on the client computer, but use the standard user account and User Account Control (UAC).
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -89,49 +67,22 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
One of the risks of the User Account Control (UAC) feature is that it is intended to mitigate malicious software running under elevated credentials without the user or administrator being aware of its activity. An attack vector for malicious programs is to discover the password of the administrator account because that user account was created for all installations of the Windows. To address this risk, the built-in administrator account is disabled in computers running at least Windows Vista. In computers running at least Windows Server 2008, the administrator account is enabled, and the password must be changed the first time the Administrator logs on. In a default installation of a computer running at least Windows Vista, accounts with administrative control over the computer are initially set up in one of two ways:
-
- If the computer is not joined to a domain, the first user account you create has the equivalent permissions as a local administrator.
-
- If the computer is joined to a domain, no local administrator accounts are created. The enterprise or domain administrator must log on to the computer and create a local administrator account if one is warranted.
-
### Countermeasure
-
Enable the **User Account Control: Admin Approval Mode for the Built-in Administrator account** setting if you have the built-in Administrator account enabled.
-
### Potential impact
-
Users who log on by using the local administrator account are prompted for consent whenever a program requests an elevation in privilege.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop.md b/windows/keep-secure/user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop.md
index 3dea249901..3215dba248 100644
--- a/windows/keep-secure/user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop.md
+++ b/windows/keep-secure/user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop.md
@@ -2,77 +2,44 @@
title: User Account Control Allow UIAccess applications to prompt for elevation without using the secure desktop (Windows 10)
description: Describes the best practices, location, values, and security considerations for the User Account Control Allow UIAccess applications to prompt for elevation without using the secure desktop security policy setting.
ms.assetid: fce20472-3c93-449d-b520-13c4c74a9892
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, and security considerations for the **User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop** security policy setting.
-
## Reference
-
-
This security setting controls whether User Interface Accessibility (UIAccess or UIA) programs can automatically disable the secure desktop for elevation prompts that are used by a standard user.
-
**Note**
This setting does not change the behavior of the UAC elevation prompt for administrators.
-
-
**Background**
-
User Interface Privilege Isolation (UIPI) implements restrictions in the Windows subsystem that prevent lower-privilege applications from sending messages or installing hooks in higher-privilege processes. Higher-privilege applications are permitted to send messages to lower-privilege processes. UIPI does not interfere with or change the behavior of messages between applications at the same privilege (or integrity) level.
-
Microsoft UI Automation is the current model to support accessibility requirements in the Windows operating systems. Applications that are designed to support an accessible user experience control the behavior of other Windows applications on behalf of the user. When all applications on the automation client computer and server are running as a standard user (that is, at a medium integrity level), the UIPI restrictions do not interfere with the Microsoft UI automation model.
-
However, there might be times when an administrative user runs an application with elevated privilege based on UAC in Admin Approval Mode. Microsoft UI Automation cannot drive the UI graphics of elevated applications on the desktop without the ability to bypass the restrictions that UIPI implements. The ability to bypass UIPI restrictions across privilege levels is available for UI automation programs by using UIAccess.
-
If an application presents a UIAccess attribute when it requests privileges, the application is stating a requirement to bypass UIPI restrictions for sending messages across privilege levels. Devices implement the following policy checks before starting an application with UIAccess privilege.
-
1. The application must have a digital signature that can be verified by using a digital certificate that is associated with the Trusted Root Certification Authorities store on the local computer.
-
2. The application must be installed in a local folder that is writeable only by administrators, such as the Program Files directory. The allowed directories for UI automation applications are:
-
1. %ProgramFiles% and its subdirectories.
-
2. %WinDir% and its subdirectories, except a few subdirectories that are excluded because standard users have write access.
-
**Resulting behavior**
-
When this setting is enabled, UIAccess programs (including Windows Remote Assistance) can automatically disable the secure desktop for elevation prompts. Unless you have also disabled elevation prompts, the prompts appear on the interactive user's desktop instead of on the secure desktop. The prompts also appear on the remote administrator's view of the desktop during a Windows Remote Assistance session, and the remote administrator can provide the appropriate credentials for elevation.
-
If you disable this setting, the secure desktop can only be disabled by the user of the interactive desktop or by disabling the [User Account Control: Switch to the secure desktop when prompting for elevation](user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md) setting, which by default is enabled.
-
### Possible values
-
- Enabled
-
UIA programs can automatically disable the secure desktop for elevation prompts, and unless you have also disabled elevation prompts, the prompts appear on the interactive user's desktop instead of on the secure desktop. Prompts will also appear on the remote administrator's view of the desktop during a Windows Remote Assistance session, and the remote administrator can provide the appropriate credentials for elevation.
-
- Disabled
-
The secure desktop can be disabled only by the user of the interactive desktop or by disabling the **User Account Control: Switch to the secure desktop when prompting for elevation** policy setting.
-
### Best practices
-
- Best practices are dependent on your security policies and your remote operational requirements.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -111,61 +78,28 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a computer restart when they are saved locally or distributed through Group Policy.
-
### Group Policy
-
All auditing capabilities are integrated in Group Policy. You can configure, deploy, and manage these settings in the Group Policy Management Console (GPMC) or Local Security Policy snap-in for a domain, site, or organizational unit (OU).
-
### Policy interactions
-
If you plan to enable this setting, you should also review the effect of the [User Account Control: Behavior of the elevation prompt for standard users](user-account-control-behavior-of-the-elevation-prompt-for-standard-users.md) setting. If it is configured as **Automatically deny elevation requests**, elevation requests are not presented to the user. If you disable this setting, the secure desktop can only be disabled by the user of the interactive desktop or by disabling the [User Account Control: Switch to the secure desktop when prompting for elevation](user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md) setting, which by default is enabled.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
UIA programs are designed to interact with Windows and application programs on behalf of a user. This setting allows UIA programs to bypass the secure desktop to increase usability in certain cases, but it allows elevation requests to appear on the regular interactive desktop instead of on the secure desktop. This increases the risk that a malicious program could intercept data that is being transferred between the UI and the application. Because UIA programs must be able to respond to prompts regarding security issues, such as the UAC elevation prompt, UIA programs must be highly trusted. To be considered trusted, a UIA program must be digitally signed. By default, UIA programs can be run only from the following protected paths:
-
- ..\\Program Files\\ (and subfolders)
-
- ..\\Program Files (x86)\\ (and subfolders, in 64-bit versions of Windows only)
-
- ..\\Windows\\System32\\
-
The requirement to be in a protected path can be disabled by the [User Account Control: Only elevate UIAccess applications that are installed in secure locations](user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations.md) setting. Although this setting applies to any UIA program, it is used primarily in certain Windows Remote Assistance scenarios.
-
### Countermeasure
-
Disable the **User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop** setting.
-
### Potential impact
-
If a user requests remote assistance from an administrator and the remote assistance session is established, elevation prompts appear on the interactive user's secure desktop and the administrator's remote session is paused. To avoid pausing the remote administrator’s session during elevation requests, the user can select the "Allow IT Expert to respond to User Account Control prompts" check box when setting up the remote assistance session. However, selecting this check box requires that the interactive user respond to an elevation prompt on the secure desktop. If the interactive user is a standard user, the user does not have the required credentials to allow elevation.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode.md b/windows/keep-secure/user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode.md
index d60ccc6dc6..2f01c9ecc5 100644
--- a/windows/keep-secure/user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode.md
+++ b/windows/keep-secure/user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode.md
@@ -2,69 +2,40 @@
title: User Account Control Behavior of the elevation prompt for administrators in Admin Approval Mode (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the User Account Control Behavior of the elevation prompt for administrators in Admin Approval Mode security policy setting.
ms.assetid: 46a3c3a2-1d2e-4a6f-b5e6-29f9592f535d
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode** security policy setting.
-
## Reference
-
-
This policy setting determines the behavior of the elevation prompt for accounts that have administrative credentials.
-
### Possible values
-
- **Elevate without prompting**
-
Assumes that the administrator will permit an operation that requires elevation, and additional consent or credentials are not required.
-
**Note**
Selecting **Elevate without prompting** minimizes the protection that is provided by UAC. We do not recommend selecting this value unless administrator accounts are tightly controlled and the operating environment is highly secure.
-
-
- **Prompt for credentials on the secure desktop**
-
When an operation requires elevation of privilege, the user is prompted on the secure desktop to enter a privileged user name and password. If the user enters valid credentials, the operation continues with the user's highest available privilege.
-
- **Prompt for consent on the secure desktop**
-
When an operation requires elevation of privilege, the user is prompted on the secure desktop to select **Permit** or **Deny**. If the user selects **Permit**, the operation continues with the user's highest available privilege.
-
- **Prompt for credential**s
-
An operation that requires elevation of privilege prompts the administrator to type the user name and password. If the administrator enters valid credentials, the operation continues with the applicable privilege.
-
- **Prompt for consent**
-
An operation that requires elevation of privilege prompts the administrator to select **Permit** or **Deny**. If the administrator selects **Permit**, the operation continues with the administrator's highest available privilege.
-
- **Prompt for consent for non-Windows binaries**
-
This is the default. When an operation for a non-Microsoft application requires elevation of privilege, the user is prompted on the secure desktop to select **Permit** or **Deny**. If the user selects **Permit**, the operation continues with the user's highest available privilege.
-
### Best practices
-
- Selecting the option **Elevate without prompting** minimizes the protection that is provided by UAC. We do not recommend selecting this value unless administrator accounts are tightly controlled and the operating environment is highly secure.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -103,49 +74,22 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a computer restart when they are saved locally or distributed through Group Policy.
-
### Group Policy
-
All auditing capabilities are integrated in Group Policy. You can configure, deploy, and manage these settings in the Group Policy Management Console (GPMC) or Local Security Policy snap-in for a domain, site, or organizational unit (OU).
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
One of the risks that the UAC feature tries to mitigate is that of malicious software running under elevated credentials without the user or administrator being aware of its activity. This setting raises awareness to the administrator of elevated privilege operations, and it permits the administrator to prevent a malicious program from elevating its privilege when the program attempts to do so.
-
### Countermeasure
-
Configure the **User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode** setting to **Prompt for consent**.
-
### Potential impact
-
Administrators should be made aware that they will be prompted for consent when all binaries attempt to run.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/user-account-control-behavior-of-the-elevation-prompt-for-standard-users.md b/windows/keep-secure/user-account-control-behavior-of-the-elevation-prompt-for-standard-users.md
index 38d421d5f1..727d8b7ba1 100644
--- a/windows/keep-secure/user-account-control-behavior-of-the-elevation-prompt-for-standard-users.md
+++ b/windows/keep-secure/user-account-control-behavior-of-the-elevation-prompt-for-standard-users.md
@@ -2,54 +2,32 @@
title: User Account Control Behavior of the elevation prompt for standard users (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the User Account Control Behavior of the elevation prompt for standard users security policy setting.
ms.assetid: 1eae7def-8f6c-43b6-9474-23911fdc01ba
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# User Account Control: Behavior of the elevation prompt for standard users
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Behavior of the elevation prompt for standard users** security policy setting.
-
## Reference
-
-
This policy setting determines the behavior of the elevation prompt for standard users.
-
### Possible values
-
- **Automatically deny elevation requests**
-
This option returns an “Access denied” error message to standard users when they try to perform an operation that requires elevation of privilege. Most organizations that run desktops as standard users configure this policy to reduce Help Desk calls.
-
- **Prompt for credentials on the secure desktop**
-
This is the default. When an operation requires elevation of privilege, the user is prompted on the secure desktop to enter a different user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.
-
- **Prompt for credentials**
-
An operation that requires elevation of privilege prompts the user to type an administrative user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.
-
### Best practices
-
1. Configure the **User Account Control: Behavior of the elevation prompt for standard users** to **Automatically deny elevation requests**. This setting requires the user to log on with an administrative account to run programs that require elevation of privilege.
-
2. As a security best practice, standard users should not have knowledge of administrative passwords. However, if your users have both standard and administrator-level accounts, set **Prompt for credentials** so that the users do not choose to always log on with their administrator accounts, and they shift their behavior to use the standard user account.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -88,49 +66,22 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a computer restart when they are saved locally or distributed through Group Policy.
-
### Group Policy
-
All auditing capabilities are integrated in Group Policy. You can configure, deploy, and manage these settings in the Group Policy Management Console (GPMC) or Local Security Policy snap-in for a domain, site, or organizational unit (OU).
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
One of the risks that the UAC feature tries to mitigate is that of malicious programs running under elevated credentials without the user or administrator being aware of their activity. This setting raises awareness to the user that a program requires the use of elevated privilege operations, and it requires that the user supply administrative credentials for the program to run.
-
### Countermeasure
-
Configure the **User Account Control: Behavior of the elevation prompt for standard users** to **Automatically deny elevation requests**. This setting requires the user to log on with an administrative account to run programs that require elevation of privilege. As a security best practice, standard users should not have knowledge of administrative passwords. However, if your users have both standard and administrator-level accounts, we recommend setting **Prompt for credentials** so that the users do not choose to always log on with their administrator accounts, and they shift their behavior to use the standard user account.
-
### Potential impact
-
Users must provide administrative passwords to run programs with elevated privileges. This could cause an increased load on IT staff while the programs that are affected are identified and standard operating procedures are modified to support least privilege operations.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/user-account-control-detect-application-installations-and-prompt-for-elevation.md b/windows/keep-secure/user-account-control-detect-application-installations-and-prompt-for-elevation.md
index 53b4161dd7..067ec3619c 100644
--- a/windows/keep-secure/user-account-control-detect-application-installations-and-prompt-for-elevation.md
+++ b/windows/keep-secure/user-account-control-detect-application-installations-and-prompt-for-elevation.md
@@ -2,52 +2,31 @@
title: User Account Control Detect application installations and prompt for elevation (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the User Account Control Detect application installations and prompt for elevation security policy setting.
ms.assetid: 3f8cb170-ba77-4c9f-abb3-c3ed1ef264fc
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# User Account Control: Detect application installations and prompt for elevation
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Detect application installations and prompt for elevation** security policy setting.
-
## Reference
-
-
This policy setting determines the behavior of application installation detection for the entire system.
-
Some software might attempt to install itself after being given permission to run. The user may give permission for the program to run because the program is trusted. Then the user is prompted to install an unknown component. This security policy provides another way to identify and stop these attempted software installations before they can do damage.
-
### Possible values
-
- **Enabled**
-
Application installation packages that require an elevation of privilege to install are detected and the user is prompted for administrative credentials.
-
- **Disabled**
-
Application installation packages that require an elevation of privilege to install are not detected and the user is not prompted for administrative credentials.
-
### Best practices
-
1. Installer detection is unnecessary when enterprises run standard user desktops that capitalize on delegated installation technologies like Group Policy Software Install (GPSI) or Configuration Manager. Therefore you can set this security policy to **Disabled**.
-
2. Enable the **User Account Control: Detect application installations and prompt for elevation** setting so standard users must provide administrative credentials before software is installed.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -86,45 +65,20 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Some malicious software might attempt to install itself after being given permission to run, for example, malicious software with a trusted application shell. The user may give permission for the program to run because the program is trusted. Then the user is prompted to install an unknown component. This policy provides another way to trap the software before it can do damage.
-
### Countermeasure
-
Enable the **User Account Control: Detect application installations and prompt for elevation** setting.
-
### Potential impact
-
Users must provide administrative passwords to install programs.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/user-account-control-only-elevate-executables-that-are-signed-and-validated.md b/windows/keep-secure/user-account-control-only-elevate-executables-that-are-signed-and-validated.md
index 94fac9972b..7c3f3ccfae 100644
--- a/windows/keep-secure/user-account-control-only-elevate-executables-that-are-signed-and-validated.md
+++ b/windows/keep-secure/user-account-control-only-elevate-executables-that-are-signed-and-validated.md
@@ -2,54 +2,32 @@
title: User Account Control Only elevate executables that are signed and validated (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the User Account Control Only elevate executables that are signed and validated security policy setting.
ms.assetid: 64950a95-6985-4db6-9905-1db18557352d
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# User Account Control: Only elevate executables that are signed and validated
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Only elevate executables that are signed and validated** security policy setting.
-
## Reference
-
-
This policy setting enforces public key infrastructure (PKI) signature checks on any interactive application that requests elevation of privilege. You can control the apps that are allowed to run through the population of certificates in the local computer's Trusted Publishers store.
-
A trusted publisher is a certificate issuer that the computer’s user has chosen to trust and that has certificate details that have been added to the store of trusted publishers.
-
Windows maintains certificates in certificate stores. These stores can be represented by containers in the file system or the registry, or they can be implemented as physical stores such as smart cards. Certificate stores are associated with the computer object or they are owned by a distinct user who has a security context and profile on that computer. In addition, services can have certificate stores. A certificate store will often contain numerous certificates, possibly issued from a number of different certification authorities (CAs).
-
When certificate path discovery is initiated, Windows attempts to locate the issuing CA for the certificates, and it builds a certificate path to the trusted root certificate. Intermediate certificates are included as part of the application protocol or are picked up from Group Policy or through URLs that are specified in the Authority Information Access (AIA) extension. When the path is built, each certificate in the path is verified for validity with respect to various parameters, such as name, time, signature, revocation status, and other constraints.
-
### Possible values
-
- **Enabled**
-
Enforces the PKI certificate chain validation of a given executable file before it is permitted to run.
-
- **Disabled**
-
Does not enforce PKI certificate chain validation before a given executable file is permitted to run.
-
### Best practices
-
- Best practices are dependent on your security and performance goals.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -88,51 +66,23 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a computer restart when they are saved locally or distributed through Group Policy.
-
### Group Policy
-
All auditing capabilities are integrated in Group Policy. You can configure, deploy, and manage these settings in the Group Policy Management Console (GPMC) or Local Security Policy snap-in for a domain, site, or organizational unit (OU).
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Intellectual property, personally identifiable information, and other confidential data are normally manipulated by applications on the computer, and elevated credentials are required to access the information. Users and administrators inherently trust applications that are used with these information sources, and they provide their credentials. If one of these applications is replaced by a rogue application that appears identical to the trusted application, the confidential data could be compromised and the user's administrative credentials would also be compromised.
-
### Countermeasure
-
Enable the **User Account Control: Only elevate executables that are signed and validated**.
-
### Potential impact
-
Enabling this setting requires that you have a PKI infrastructure and that your enterprise administrators have populated the Trusted Publishers store with the certificates for the allowed applications. Some older applications are not signed, and they cannot be used in an environment that is hardened with this setting. You should carefully test your applications in a preproduction environment before implementing this setting.
-
Control over the applications that are installed on the desktops and the hardware that joins your domain should provide similar protection from the vulnerability that is addressed by this setting. Additionally, the level of protection that is provided by this setting is not an assurance that all rogue applications will be found.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations.md b/windows/keep-secure/user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations.md
index c6776e5433..b79b29a94b 100644
--- a/windows/keep-secure/user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations.md
+++ b/windows/keep-secure/user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations.md
@@ -2,77 +2,44 @@
title: User Account Control Only elevate UIAccess applications that are installed in secure locations (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the User Account Control Only elevate UIAccess applications that are installed in secure locations security policy setting.
ms.assetid: 4333409e-a5be-4f2f-8808-618f53abd22c
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# User Account Control: Only elevate UIAccess applications that are installed in secure locations
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Only elevate UIAccess applications that are installed in secure locations** security policy setting.
-
## Reference
-
-
This policy setting enforces the requirement that apps that request running with a UIAccess integrity level (by means of a marking of UIAccess=true in their app manifest), must reside in a secure location on the file system. Relatively secure locations are limited to the following directories:
-
- \\Program Files\\ including subdirectories
-
- \\Windows\\system32\\
-
- \\Program Files (x86)\\ including subdirectories for 64-bit versions of Windows
-
**Note**
Windows enforces a PKI signature check on any interactive application that requests running with a UIAccess integrity level, regardless of the state of this security setting.
-
-
**Background**
-
User Interface Privilege Isolation (UIPI) implements restrictions in the Windows subsystem that prevent lower-privilege applications from sending messages or installing hooks in higher-privilege processes. Higher-privilege applications are permitted to send messages to lower-privilege processes. UIPI does not interfere with or change the behavior of messages between applications at the same privilege (or integrity) level.
-
Microsoft UI Automation is the current model to support accessibility requirements in the Windows operating systems. Applications that are designed to support an accessible user experience control the behavior of other Windows applications on behalf of the user. When all applications on the automation client computer and server are running as a standard user (that is, at a medium integrity level), the UIPI restrictions do not interfere with the Microsoft UI automation model.
-
However, there might be times when an administrative user runs an application with elevated privilege based on UAC in Admin Approval Mode. Microsoft UI Automation cannot drive the UI graphics of elevated applications on the desktop without the ability to bypass the restrictions that UIPI implements. The ability to bypass UIPI restrictions across privilege levels is available for UI automation programs by using UIAccess.
-
If an application presents a UIAccess attribute when it requests privileges, the application is stating a requirement to bypass UIPI restrictions for sending messages across privilege levels. Devices implement the following policy checks before starting an application with UIAccess privilege.
-
1. The application must have a digital signature that can be verified by using a digital certificate that is associated with the Trusted Root Certification Authorities store on the local device
-
2. The application must be installed in a local folder that is writeable only by administrators, such as the Program Files directory. The allowed directories for UI automation applications are:
-
1. %ProgramFiles% and its subdirectories.
-
2. %WinDir% and its subdirectories, except a few subdirectories that are excluded because standard users have write access.
-
### Possible values
-
- **Enabled**
-
An application can start with UIAccess integrity only if it resides in a secure location in the file system.
-
- **Disabled**
-
An application can start with UIAccess integrity even if it does not reside in a secure location in the file system.
-
### Best practices
-
- Set this policy to **Enabled** to permit applications that are located in one of the designated secure directories to run with UIAccess integrity.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -111,59 +78,27 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they aresaved locally or distributed through Group Policy.
-
### Group Policy
-
All auditing capabilities are integrated in Group Policy. You can configure, deploy, and manage these settings in the Group Policy Management Console (GPMC) or Local Security Policy snap-in for a domain, site, or organizational unit (OU).
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
UIAccess integrity allows an application to bypass User Interface Privilege Isolation (UIPI) restrictions when an application is elevated in privilege from a standard user to an administrator. When this setting is enabled, an application that has the UIAccess flag set to true in its manifest can interchange information with applications that are running at a higher privilege level, such as logon prompts and privilege elevation prompts. This ability is required to support accessibility features such as screen readers that are transmitting user interfaces to alternative forms, but it is not required by most applications. A process that is started with UIAccess rights has the following abilities:
-
- Set the foreground window.
-
- Drive any application window by using the SendInput function.
-
- Use read input for all integrity levels by using low-level hooks, raw input, GetKeyState, GetAsyncKeyState, and GetKeyboardInput.
-
- Set journal hooks.
-
- Use AttachThreadInput to attach a thread to a higher integrity input queue.
-
### Countermeasure
-
Enable the **User Account Control: Only elevate UIAccess applications that are installed in secure locations** setting.
-
### Potential impact
-
If the application that requests UIAccess meets the UIAccess setting requirements, computers running at least the Windows Vista operating system start the application with the ability to bypass most of the UIPI restrictions. If the application does not meet the security restrictions, the application is started without UIAccess rights, and it can interact only with applications at the same or lower privilege level.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/user-account-control-overview.md b/windows/keep-secure/user-account-control-overview.md
index 5220e7b05d..f2eb1a4824 100644
--- a/windows/keep-secure/user-account-control-overview.md
+++ b/windows/keep-secure/user-account-control-overview.md
@@ -2,50 +2,30 @@
title: User Account Control (Windows 10)
description: User Account Control (UAC) helps prevent malware from damaging a PC and helps organizations deploy a better-managed desktop.
ms.assetid: 43ac4926-076f-4df2-84af-471ee7d20c38
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: operate
ms.sitesec: library
author: brianlic-msft
---
-
# User Account Control
-
**Applies to**
-
- Windows 10
- Windows Server 2016 Technical Preview
-
User Account Control (UAC) helps prevent malware from damaging a PC and helps organizations deploy a better-managed desktop. With UAC, apps and tasks always run in the security context of a non-administrator account, unless an administrator specifically authorizes administrator-level access to the system. UAC can block the automatic installation of unauthorized apps and prevent inadvertent changes to system settings.
-
UAC allows all users to log on to their computers using a standard user account. Processes launched using a standard user token may perform tasks using access rights granted to a standard user. For instance, Windows Explorer automatically inherits standard user level permissions. Additionally, any apps that are started using Windows Explorer (for example, by double-clicking a shortcut) also run with the standard set of user permissions. Many apps, including those that are included with the operating system itself, are designed to work properly in this way.
-
Other apps, especially those that were not specifically designed with security settings in mind, often require additional permissions to run successfully. These types of apps are referred to as legacy apps. Additionally, actions such as installing new software and making configuration changes to the Windows Firewall, require more permissions than what is available to a standard user account.
-
When an app needs to run with more than standard user rights, UAC can restore additional user groups to the token. This enables the user to have explicit control of apps that are making system level changes to their computer or device.
-
## Practical applications
-
Admin Approval Mode in UAC helps prevent malware from silently installing without an administrator's knowledge. It also helps protect from inadvertent system-wide changes. Lastly, it can be used to enforce a higher level of compliance where administrators must actively consent or provide credentials for each administrative process.
-
## New and changed functionality
-
To find out what's new in UAC for Windows 10, see [User Account Control](../whats-new/user-account-control.md).
-
## In this section
-
| Topic | Description |
| - | - |
| [How User Account Control works](how-user-account-control-works.md) | User Account Control (UAC) is a fundamental component of Microsoft's overall security vision. UAC helps mitigate the impact of malware. |
| [User Account Control security policy settings](user-account-control-security-policy-settings.md) | You can use security policies to configure how User Account Control works in your organization. They can be configured locally by using the Local Security Policy snap-in (secpol.msc) or configured for the domain, OU, or specific groups by Group Policy. |
| [User Account Control Group Policy and registry key settings](user-account-control-group-policy-and-registry-key-settings.md) | Here's a list of UAC Group Policy and registry key settings that your organization can use to manage UAC. |
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/user-account-control-run-all-administrators-in-admin-approval-mode.md b/windows/keep-secure/user-account-control-run-all-administrators-in-admin-approval-mode.md
index 9219e967ee..0c53ba8b97 100644
--- a/windows/keep-secure/user-account-control-run-all-administrators-in-admin-approval-mode.md
+++ b/windows/keep-secure/user-account-control-run-all-administrators-in-admin-approval-mode.md
@@ -2,53 +2,32 @@
title: User Account Control Run all administrators in Admin Approval Mode (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the User Account Control Run all administrators in Admin Approval Mode security policy setting.
ms.assetid: b838c561-7bfc-41ef-a7a5-55857259c7bf
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# User Account Control: Run all administrators in Admin Approval Mode
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Run all administrators in Admin Approval Mode** security policy setting.
-
## Reference
-
-
This policy setting determines the behavior of all User Account Control (UAC) policies for the entire system. This is the setting that turns UAC on or off.
-
### Possible values
-
- **Enabled**
-
Admin Approval Mode and all other UAC policies are dependent on this option being enabled. Changing this setting requires restarting the system.
-
- **Disabled**
-
Admin Approval Mode and all related UAC policies are disabled.
-
**Note**
If this security setting is configured to **Disabled**, the Security Center notifies the user that the overall security of the operating system has been reduced.
-
-
### Best practices
-
- Enable this policy to allow all other UAC features and policies to function.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -87,49 +66,22 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
A restart of the computer is required before this policy will be effective when changes to this policy are saved locally or distributed through Group Policy.
-
### Group Policy
-
All auditing capabilities are integrated in Group Policy. You can configure, deploy, and manage these settings in the Group Policy Management Console (GPMC) or Local Security Policy snap-in for a domain, site, or organizational unit (OU).
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
This is the setting that turns UAC on or off. If this setting is disabled, UAC is not used, and any security benefits and risk mitigations that are dependent on UAC are not present on the computer.
-
### Countermeasure
-
Enable the **User Account Control: Run all users, including administrators, as standard users** setting.
-
### Potential impact
-
Users and administrators must learn to work with UAC prompts and adjust their work habits to use least privilege operations.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/user-account-control-security-policy-settings.md b/windows/keep-secure/user-account-control-security-policy-settings.md
index 4b14dad1b3..d1a286bf5e 100644
--- a/windows/keep-secure/user-account-control-security-policy-settings.md
+++ b/windows/keep-secure/user-account-control-security-policy-settings.md
@@ -2,137 +2,66 @@
title: User Account Control security policy settings (Windows 10)
description: You can use security policies to configure how User Account Control works in your organization. They can be configured locally by using the Local Security Policy snap-in (secpol.msc) or configured for the domain, OU, or specific groups by Group Policy.
ms.assetid: 3D75A9AC-69BB-4EF2-ACB3-1769791E1B98
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: operate
ms.sitesec: library
author: brianlic-msft
---
-
# User Account Control security policy settings
-
-
**Applies to**
-
- Windows 10
-
You can use security policies to configure how User Account Control works in your organization. They can be configured locally by using the Local Security Policy snap-in (secpol.msc) or configured for the domain, OU, or specific groups by Group Policy.
-
## User Account Control: Admin Approval Mode for the Built-in Administrator account
-
-
This policy setting controls the behavior of Admin Approval Mode for the built-in Administrator account.
-
- **Enabled** The built-in Administrator account uses Admin Approval Mode. By default, any operation that requires elevation of privilege will prompt the user to approve the operation.
-
- **Disabled** (Default) The built-in Administrator account runs all applications with full administrative privilege.
-
## User Account Control: Allow UIAccess application to prompt for elevation without using the secure desktop
-
-
This policy setting controls whether User Interface Accessibility (UIAccess or UIA) programs can automatically disable the secure desktop for elevation prompts used by a standard user.
-
- **Enabled** UIA programs, including Windows Remote Assistance, automatically disable the secure desktop for elevation prompts. If you do not disable the "User Account Control: Switch to the secure desktop when prompting for elevation" policy setting, the prompts appear on the interactive user's desktop instead of the secure desktop.
-
- **Disabled** (Default) The secure desktop can be disabled only by the user of the interactive desktop or by disabling the "User Account Control: Switch to the secure desktop when prompting for elevation" policy setting.
-
## User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode
-
-
This policy setting controls the behavior of the elevation prompt for administrators.
-
- **Elevate without prompting** Allows privileged accounts to perform an operation that requires elevation without requiring consent or credentials.
-
**Note** Use this option only in the most constrained environments.
-
-
- **Prompt for credentials on the secure desktop** When an operation requires elevation of privilege, the user is prompted on the secure desktop to enter a privileged user name and password. If the user enters valid credentials, the operation continues with the user's highest available privilege.
-
- **Prompt for consent on the secure desktop** When an operation requires elevation of privilege, the user is prompted on the secure desktop to select either Permit or Deny. If the user selects Permit, the operation continues with the user's highest available privilege.
-
- **Prompt for credentials** When an operation requires elevation of privilege, the user is prompted to enter an administrative user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.
-
- **Prompt for consent** When an operation requires elevation of privilege, the user is prompted to select either Permit or Deny. If the user selects Permit, the operation continues with the user's highest available privilege.
-
- **Prompt for consent for non-Windows binaries** (Default) When an operation for a non-Microsoft application requires elevation of privilege, the user is prompted on the secure desktop to select either Permit or Deny. If the user selects Permit, the operation continues with the user's highest available privilege.
-
## User Account Control: Behavior of the elevation prompt for standard users
-
-
This policy setting controls the behavior of the elevation prompt for standard users.
-
- **Prompt for credentials** (Default) When an operation requires elevation of privilege, the user is prompted to enter an administrative user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.
-
- **Automatically deny elevation requests** When an operation requires elevation of privilege, a configurable access denied error message is displayed. An enterprise that is running desktops as standard user may choose this setting to reduce help desk calls.
-
- **Prompt for credentials on the secure desktop** When an operation requires elevation of privilege, the user is prompted on the secure desktop to enter a different user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.
-
## User Account Control: Detect application installations and prompt for elevation
-
-
This policy setting controls the behavior of application installation detection for the computer.
-
- **Enabled** (Default) When an app installation package is detected that requires elevation of privilege, the user is prompted to enter an administrative user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.
-
-
- **Disabled** App installation packages are not detected and prompted for elevation. Enterprises that are running standard user desktops and use delegated installation technologies, such as Group Policy or System Center Configuration Manager should disable this policy setting. In this case, installer detection is unnecessary.
-
## User Account Control: Only elevate executable files that are signed and validated
-
-
This policy setting enforces public key infrastructure (PKI) signature checks for any interactive applications that request elevation of privilege. Enterprise administrators can control which applications are allowed to run by adding certificates to the Trusted Publishers certificate store on local computers.
-
- **Enabled** Enforces the certificate certification path validation for a given executable file before it is permitted to run.
-
- **Disabled** (Default) Does not enforce the certificate certification path validation before a given executable file is permitted to run.
-
## User Account Control: Only elevate UIAccess applications that are installed in secure locations
-
-
This policy setting controls whether applications that request to run with a User Interface Accessibility (UIAccess) integrity level must reside in a secure location in the file system. Secure locations are limited to the following: - …\\Program Files\\, including subfolders - …\\Windows\\system32\\ - …\\Program Files (x86)\\, including subfolders for 64-bit versions of Windows
-
**Note**
Windows enforces a digital signature check on any interactive app that requests to run with a UIAccess integrity level regardless of the state of this security setting.
-
-
- **Enabled** (Default) If an app resides in a secure location in the file system, it runs only with UIAccess integrity.
-
- **Disabled** An app runs with UIAccess integrity even if it does not reside in a secure location in the file system.
-
## User Account Control: Turn on Admin Approval Mode
-
-
This policy setting controls the behavior of all User Account Control (UAC) policy settings for the computer. If you change this policy setting, you must restart your computer.
-
- **Enabled** (Default) Admin Approval Mode is enabled. This policy must be enabled and related UAC policy settings must also be set appropriately to allow the built-in Administrator account and all other users who are members of the Administrators group to run in Admin Approval Mode.
-
- **Disabled** Admin Approval Mode and all related UAC policy settings are disabled. Note: If this policy setting is disabled, the Security Center notifies you that the overall security of the operating system has been reduced.
-
## User Account Control: Switch to the secure desktop when prompting for elevation
-
-
This policy setting controls whether the elevation request prompt is displayed on the interactive user's desktop or the secure desktop.
-
- **Enabled** (Default) All elevation requests go to the secure desktop regardless of prompt behavior policy settings for administrators and standard users.
-
- **Disabled** All elevation requests go to the interactive user's desktop. Prompt behavior policy settings for administrators and standard users are used.
-
## User Account Control: Virtualize file and registry write failures to per-user locations
-
-
This policy setting controls whether application write failures are redirected to defined registry and file system locations. This policy setting mitigates applications that run as administrator and write run-time application data to %ProgramFiles%, %Windir%, %Windir%\\system32, or HKLM\\Software.
-
- **Enabled** (Default) App write failures are redirected at run time to defined user locations for both the file system and registry.
-
- **Disabled** Apps that write data to protected locations fail.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md b/windows/keep-secure/user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md
index e5bebae839..9475c83eba 100644
--- a/windows/keep-secure/user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md
+++ b/windows/keep-secure/user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md
@@ -2,52 +2,31 @@
title: User Account Control Switch to the secure desktop when prompting for elevation (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the User Account Control Switch to the secure desktop when prompting for elevation security policy setting.
ms.assetid: 77a067db-c70d-4b02-9861-027503311b8b
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# User Account Control: Switch to the secure desktop when prompting for elevation
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Switch to the secure desktop when prompting for elevation** security policy setting.
-
## Reference
-
-
This policy setting determines whether the elevation request prompts on the interactive user desktop or on the secure desktop.
-
The secure desktop presents the logon UI and restricts functionality and access to the system until the logon requirements are satisfied.
-
The secure desktop’s primary difference from the user desktop is that only trusted processes running as SYSTEM are allowed to run here (that is, nothing is running at the user’s privilege level). The path to get to the secure desktop from the user desktop must also be trusted through the entire chain.
-
### Possible values
-
- **Enabled**
-
All elevation requests by default go to the secure desktop.
-
- **Disabled**
-
All elevation requests go to the interactive user desktop.
-
### Best practices
-
- Enable the **User Account Control: Switch to the secure desktop when prompting for elevation setting**. The secure desktop helps protect against input and output spoofing by presenting the credentials dialog box in a protected section of memory that is accessible only by trusted system processes.
-
### Location
-
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -86,49 +65,22 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Group Policy
-
All auditing capabilities are integrated in Group Policy. You can configure, deploy, and manage these settings in the Group Policy Management Console (GPMC) or Local Security Policy snap-in for a domain, site, or organizational unit (OU).
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Elevation prompt dialog boxes can be spoofed, causing users to disclose their passwords to malicious software. Mouse cursors can be spoofed by hiding the real cursor and replacing it with an offset so the cursor is actually pointing to the **Allow** button.
-
### Countermeasure
-
Enable the **User Account Control: Switch to the secure desktop when prompting for elevation setting**. The secure desktop helps protect against input and output spoofing by presenting the credentials dialog box in a protected section of memory that is accessible only by trusted system processes.
-
### Potential impact
-
None. This is the default configuration.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations.md b/windows/keep-secure/user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations.md
index 72e15ea4d5..ffb892226b 100644
--- a/windows/keep-secure/user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations.md
+++ b/windows/keep-secure/user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations.md
@@ -2,52 +2,31 @@
title: User Account Control Virtualize file and registry write failures to per-user locations (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the User Account Control Virtualize file and registry write failures to per-user locations security policy setting.
ms.assetid: a7b47420-cc41-4b1c-b03e-f67a05221261
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# User Account Control: Virtualize file and registry write failures to per-user locations
-
-
**Applies to**
-
- Windows 10
-
Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Virtualize file and registry write failures to per-user locations** security policy setting.
-
## Reference
-
-
This policy setting enables or disables the redirection of the write failures of earlier applications to defined locations in the registry and the file system. This feature mitigates applications that historically ran as administrator and wrote runtime application data to %ProgramFiles%, %Windir%, %Windir%\\system32, or HKEY\_LOCAL\_MACHINE\\Software\\.
-
This feature can be disabled for applications on devices running at least Windows Vista because it is unnecessary.
-
### Possible values
-
- **Enabled**
-
Setting this value facilitates the runtime redirection of application write failures to defined user locations for the file system and the registry.
-
- **Disabled**
-
Applications that write data to protected locations fail.
-
### Best practices
-
1. If you run applications that are not Windows Vista-compliant, enable this security policy to prevent the possibility that these older applications could write data to unsecure locations.
-
2. If you only run at least Windows Vista–compliant applications, this feature is unnecessary so you can disable this policy.
-
### Location
-
\\Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
-
### Default values
-
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
-
@@ -86,49 +65,22 @@ The following table lists the actual and effective default values for this polic
-
-
## Policy management
-
-
This section describes features and tools that are available to help you manage this policy.
-
### Restart requirement
-
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
-
### Group Policy
-
All auditing capabilities are integrated in Group Policy. You can configure, deploy, and manage these settings in the Group Policy Management Console (GPMC) or Local Security Policy snap-in for a domain, site, or organizational unit (OU).
-
## Security considerations
-
-
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-
### Vulnerability
-
Earlier applications might not write data to secure locations.
-
### Countermeasure
-
Enable the **User Account Control: Virtualize file and registry write failures to per-user locations** setting.
-
### Potential impact
-
None. This is the default configuration.
-
## Related topics
-
-
[Security Options](security-options.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/user-rights-assignment.md b/windows/keep-secure/user-rights-assignment.md
index 7b4f1dff2f..3e96944b76 100644
--- a/windows/keep-secure/user-rights-assignment.md
+++ b/windows/keep-secure/user-rights-assignment.md
@@ -2,29 +2,20 @@
title: User Rights Assignment (Windows 10)
description: Provides an overview and links to information about the User Rights Assignment security policy settings user rights that are available in Windows.
ms.assetid: 99340252-60be-4c79-b0a5-56fbe1a9b0c5
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# User Rights Assignment
-
-
**Applies to**
-
- Windows 10
-
Provides an overview and links to information about the User Rights Assignment security policy settings user rights that are available in Windows.
-
User rights govern the methods by which a user can log on to a system. User rights are applied at the local device level, and they allow users to perform tasks on a device or in a domain. User rights include logon rights and permissions. Logon rights control who is authorized to log on to a device and how they can log on. User rights permissions control access to computer and domain resources, and they can override permissions that have been set on specific objects. User rights are managed in Group Policy under the **User Rights Assignment** item.
-
Each user right has a constant name and a Group Policy name associated with it. The constant names are used when referring to the user right in log events. You can configure the user rights assignment settings in the following location within the Group Policy Management Console (GPMC) under **Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment**, or on the local device by using the Local Group Policy Editor (gpedit.msc).
-
For information about setting security policies, see [Configure security policy settings](how-to-configure-security-policy-settings.md).
-
The following table links to each security policy setting and provides the constant name for each. Setting descriptions contain reference information, best practices for configuring the policy setting, default values, differences between operating system versions, and considerations for policy management and security.
-
@@ -215,19 +206,8 @@ The following table links to each security policy setting and provides the const
-
-
## Related topics
-
-
[Security policy settings reference](security-policy-settings-reference.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/using-advanced-security-auditing-options-to-monitor-dynamic-access-control-objects.md b/windows/keep-secure/using-advanced-security-auditing-options-to-monitor-dynamic-access-control-objects.md
index 30c91a3be8..fe7a396637 100644
--- a/windows/keep-secure/using-advanced-security-auditing-options-to-monitor-dynamic-access-control-objects.md
+++ b/windows/keep-secure/using-advanced-security-auditing-options-to-monitor-dynamic-access-control-objects.md
@@ -2,31 +2,20 @@
title: Using advanced security auditing options to monitor dynamic access control objects (Windows 10)
description: This guide explains the process of setting up advanced security auditing capabilities that are made possible through settings and events that were introduced in Windows 8 and Windows Server 2012.
ms.assetid: 0d2c28ea-bdaf-47fd-bca2-a07dce5fed37
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Using advanced security auditing options to monitor dynamic access control objects
-
-
**Applies to**
-
- Windows 10
-
This guide explains the process of setting up advanced security auditing capabilities that are made possible through settings and events that were introduced in Windows 8 and Windows Server 2012.
-
These procedures can be deployed with the advanced security auditing capabilities described in [Deploy Security Auditing with Central Audit Policies (Demonstration Steps)](http://technet.microsoft.com/library/hh831542.aspx).
-
## In this guide
-
-
Domain administrators can create and deploy expression-based security audit policies by using file classification information (resource attributes), user claims, and device claims to target specific users and resources to monitor potentially significant activities on one or more computers. These policies can be deployed centrally by using Group Policy, or directly on a computer, in a folder, or in individual files.
-
## In this section
-
-
@@ -73,24 +62,11 @@ Domain administrators can create and deploy expression-based security audit poli
-
-
**Important**
This procedure can be configured on computers running any of the supported Windows operating systems. The other monitoring procedures can be configured only as part of a functioning dynamic access control deployment.
-
-
## Related topics
-
-
[Security auditing](security-auditing-overview.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/using-event-viewer-with-applocker.md b/windows/keep-secure/using-event-viewer-with-applocker.md
index ae4dc7e8a1..304915e207 100644
--- a/windows/keep-secure/using-event-viewer-with-applocker.md
+++ b/windows/keep-secure/using-event-viewer-with-applocker.md
@@ -2,47 +2,29 @@
title: Using Event Viewer with AppLocker (Windows 10)
description: This topic lists AppLocker events and describes how to use Event Viewer with AppLocker.
ms.assetid: 109abb10-78b1-4c29-a576-e5a17dfeb916
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Using Event Viewer with AppLocker
-
-
**Applies to**
-
- Windows 10
-
This topic lists AppLocker events and describes how to use Event Viewer with AppLocker.
-
The AppLocker log contains information about applications that are affected by AppLocker rules. Each event in the log contains detailed info about:
-
- Which file is affected and the path of that file
-
- Which packaged app is affected and the package identifier of the app
-
- Whether the file or packaged app is allowed or blocked
-
- The rule type (path, file hash, or publisher)
-
- The rule name
-
- The security identifier (SID) for the user or group identified in the rule
-
Review the entries in the Event Viewer to determine if any applications are not included in the rules that you automatically generated. For instance, some line-of-business apps are installed to non-standard locations, such as the root of the active drive (for example: %SystemDrive%).
-
For info about what to look for in the AppLocker event logs, see [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md).
-
**To review the AppLocker log in Event Viewer**
-
1. Open Event Viewer.
-
2. In the console tree under **Application and Services Logs\\Microsoft\\Windows**, click **AppLocker**.
-
The following table contains information about the events that you can use to determine which apps are affected by AppLocker rules.
-
@@ -157,19 +139,8 @@ The following table contains information about the events that you can use to de
-
-
## Related topics
-
-
[Tools to use with AppLocker](tools-to-use-with-applocker.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/using-software-restriction-policies-and-applocker-policies.md b/windows/keep-secure/using-software-restriction-policies-and-applocker-policies.md
index ce10693cfd..e07957331b 100644
--- a/windows/keep-secure/using-software-restriction-policies-and-applocker-policies.md
+++ b/windows/keep-secure/using-software-restriction-policies-and-applocker-policies.md
@@ -2,38 +2,24 @@
title: Use Software Restriction Policies and AppLocker policies (Windows 10)
description: This topic for the IT professional describes how to use Software Restriction Policies (SRP) and AppLocker policies in the same Windows deployment.
ms.assetid: c3366be7-e632-4add-bd10-9df088f74c6d
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Use Software Restriction Policies and AppLocker policies
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional describes how to use Software Restriction Policies (SRP) and AppLocker policies in the same Windows deployment.
-
## Understand the difference between SRP and AppLocker
-
-
You might want to deploy application control policies in Windows operating systems earlier than Windows Server 2008 R2 or Windows 7. You can use AppLocker policies only on the supported versions and editions of Windows as listed in [Requirements to use AppLocker](requirements-to-use-applocker.md). However, you can use SRP on those supported editions of Windows plus Windows Server 2003 and Windows XP. To compare features and functions in SRP and AppLocker so that you can determine when to use each technology to meet your application control objectives, see [Determine your application control objectives](determine-your-application-control-objectives.md).
-
## Use SRP and AppLocker in the same domain
-
-
SRP and AppLocker use Group Policy for domain management. However, when policies are generated by SRP and AppLocker exist in the same domain, and they are applied through Group Policy, AppLocker policies take precedence over policies generated by SRP on computers that are running an operating system that supports AppLocker. For info about how inheritance in Group Policy applies to AppLocker policies and policies generated by SRP, see [Understand AppLocker rules and enforcement setting inheritance in Group Policy](understand-applocker-rules-and-enforcement-setting-inheritance-in-group-policy.md).
-
**Important**
As a best practice, use separate Group Policy Objects to implement your SRP and AppLocker policies. To reduce troubleshooting issues, do not combine them in the same GPO.
-
-
The following scenario provides an example of how each type of policy would affect a bank teller software app, where the app is deployed on different Windows desktop operating systems and managed by the Tellers GPO.
-
@@ -70,48 +56,22 @@ The following scenario provides an example of how each type of policy would affe
-
-
**Note**
For info about supported versions and editions of the Windows operating system, see [Requirements to use AppLocker](requirements-to-use-applocker.md).
-
-
## Test and validate SRPs and AppLocker policies that are deployed in the same environment
-
-
Because SRPs and AppLocker policies function differently, they should not be implemented in the same GPO. This makes testing the result of the policy straightforward, which is critical to successfully controlling application usage in the organization. Configuring a testing and policy distribution system can help you understand the result of a policy. The effects of policies generated by SRP and AppLocker policies need to be tested separately and by using different tools.
-
### Step 1: Test the effect of SRPs
-
You can use the Group Policy Management Console (GPMC) or the Resultant Set of Policy (RSoP) snap-in to determine the effect of applying SRPs by using GPOs.
-
### Step 2: Test the effect of AppLocker policies
-
You can test AppLocker policies by using Windows PowerShell cmdlets. For info about investigating the result of a policy, see:
-
- [Test an AppLocker policy by using Test-AppLockerPolicy](test-an-applocker-policy-by-using-test-applockerpolicy.md)
-
- [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md)
-
Another method to use when determining the result of a policy is to set the enforcement mode to **Audit only**. When the policy is deployed, events will be written to the AppLocker logs as if the policy was enforced. For info about using the **Audit only** mode, see:
-
[Understand AppLocker enforcement settings](understand-applocker-enforcement-settings.md)
-
[Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md)
-
## See also
-
-
[AppLocker deployment guide](applocker-policies-deployment-guide.md)
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/view-the-security-event-log.md b/windows/keep-secure/view-the-security-event-log.md
index 2ec26e4bc2..3c67e1191b 100644
--- a/windows/keep-secure/view-the-security-event-log.md
+++ b/windows/keep-secure/view-the-security-event-log.md
@@ -2,32 +2,19 @@
title: View the security event log (Windows 10)
description: The security log records each event as defined by the audit policies you set on each object.
ms.assetid: 20DD2ACD-241A-45C5-A92F-4BE0D9F198B9
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# View the security event log
-
-
**Applies to**
-
- Windows 10
-
The security log records each event as defined by the audit policies you set on each object.
-
**To view the security log**
-
1. Open Event Viewer.
2. In the console tree, expand **Windows Logs**, and then click **Security**. The results pane lists individual security events.
3. If you want to see more details about a specific event, in the results pane, click the event.
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/vpn-profile-options.md b/windows/keep-secure/vpn-profile-options.md
index 6c71e30d5a..6f336cc6e6 100644
--- a/windows/keep-secure/vpn-profile-options.md
+++ b/windows/keep-secure/vpn-profile-options.md
@@ -5,14 +5,13 @@ ms.assetid: E3F99DF9-863D-4E28-BAED-5C1B1B913523
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: networking
author: jdeckerMS
---
# VPN profile options
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
@@ -20,71 +19,42 @@ Virtual private networks (VPN) let you give your users secure remote access to y
## Always On
-
Always On is a new feature in Windows 10 which enables the active VPN profile to connect automatically on the following triggers:
-
- User sign-on
-
- Network change
When a device has multiple profiles with Always On triggers, the user can specify the active profile in **Settings** > **Network & Internet** > **VPN** > *VPN profile* > **Let apps automatically use this VPN connection**.
## App-triggered VPN
-
VPN profiles in Windows 10 can be configured to connect automatically on the launch of a specified set of applications. This feature was included in Windows 8.1 as "On demand VPN". The applications can be defined using the following:
-
- Package family name for Universal Windows Platform (UWP) apps
-
- File path for Classic Windows applications
## Traffic filters
-
Traffic Filters give enterprises the ability to decide what traffic is allowed into the corporate network based on policy . With the ever-increasing landscape of remote threats on the corporate network and lesser IT controls on machines, it becomes essential to control the traffic that is allowed through. While server-side layers of firewalls and proxies help, by adding traffic filters the first layer of filtering can be moved onto the client with more advanced filtering on the server side. There are two types of Traffic Filter rules:
- **App-based rules**. With app-based rules, a list of applications can be marked such that only traffic originating from these apps is allowed to go over the VPN interface.
-
- **Traffic-based rules**. Traffic-based rules are 5-tuple policies (ports, addresses, protocol) that can be specified such that only traffic matching these rules is allowed to go over the VPN interface.
There can be many sets of rules which are linked by **OR**. Within each set, there can be app-based rules and traffic-based rules; all the properties within the set will be linked by **AND**. This gives the IT admins a lot of power to craft the perfect policy befitting their use case.
## LockDown VPN
-
A VPN profile configured with LockDown secures the device to only allow network traffic over the VPN interface. It has the following features:
-
- The system attempts to keep the VPN connected at all times.
-
- The user cannot disconnect the VPN connection.
-
- The user cannot delete or modify the VPN profile.
-
- The VPN LockDown profile uses forced tunnel connection.
-
- If the VPN connection is not available, outbound network traffic is blocked.
-
- Only one VPN LockDown profile is allowed on a device.
-
-**Note**
-For inbox VPN, Lockdown VPN is only available for the Internet Key Exchange version 2 (IKEv2) tunnel type.
-
+> **Note:** For inbox VPN, Lockdown VPN is only available for the Internet Key Exchange version 2 (IKEv2) tunnel type.
-
## Learn more
-
[VPNv2 configuration service provider (CSP) reference](http://go.microsoft.com/fwlink/p/?LinkId=617588)
[How to Create VPN Profiles in Configuration Manager](http://go.microsoft.com/fwlink/p/?LinkId=618028)
[Help users connect to their work using VPN profiles with Microsoft Intune](http://go.microsoft.com/fwlink/p/?LinkId=618029)
-
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/what-is-applocker.md b/windows/keep-secure/what-is-applocker.md
index 28bc523226..cfa573d478 100644
--- a/windows/keep-secure/what-is-applocker.md
+++ b/windows/keep-secure/what-is-applocker.md
@@ -2,50 +2,30 @@
title: What Is AppLocker (Windows 10)
description: This topic for the IT professional describes what AppLocker is and how its features differ from Software Restriction Policies.
ms.assetid: 44a8a2bb-0f83-4f95-828e-1f364fb65869
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# What Is AppLocker?
-
-
**Applies to**
-
- Windows 10
-
This topic for the IT professional describes what AppLocker is and how its features differ from Software Restriction Policies.
-
AppLocker advances the app control features and functionality of Software Restriction Policies. AppLocker contains new capabilities and extensions that allow you to create rules to allow or deny apps from running based on unique identities of files and to specify which users or groups can run those apps.
-
Using AppLocker, you can:
-
- Control the following types of apps: executable files (.exe and .com), scripts (.js, .ps1, .vbs, .cmd, and .bat), Windows Installer files (.mst, .msi and .msp), and DLL files (.dll and .ocx), and packaged apps and packaged app installers (appx).
-
- Define rules based on file attributes derived from the digital signature, including the publisher, product name, file name, and file version. For example, you can create rules based on the publisher attribute that is persistent through updates, or you can create rules for a specific version of a file.
-
- Assign a rule to a security group or an individual user.
-
- Create exceptions to rules. For example, you can create a rule that allows all Windows processes to run except Registry Editor (Regedit.exe).
-
- Use audit-only mode to deploy the policy and understand its impact before enforcing it.
-
- Import and export rules. The import and export affects the entire policy. For example, if you export a policy, all of the rules from all of the rule collections are exported, including the enforcement settings for the rule collections. If you import a policy, all criteria in the existing policy are overwritten.
-
- Streamline creating and managing AppLocker rules by using Windows PowerShell cmdlets.
-
AppLocker helps reduce administrative overhead and helps reduce the organization's cost of managing computing resources by decreasing the number of help desk calls that result from users running unapproved apps
-
For information about the application control scenarios that AppLocker addresses, see [AppLocker policy use scenarios](applocker-policy-use-scenarios.md).
-
## What features are different between Software Restriction Policies and AppLocker?
-
-
**Feature differences**
-
The following table compares AppLocker to Software Restriction Policies.
-
@@ -117,13 +97,9 @@ The following table compares AppLocker to Software Restriction Policies.
-
-
**Application control function differences**
-
The following table compares the application control functions of Software Restriction Policies (SRP) and AppLocker.
-
@@ -189,19 +165,8 @@ The following table compares the application control functions of Software Restr
-
-
## Related topics
-
-
[AppLocker technical reference](applocker-technical-reference.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/which-editions-of-windows-support-advanced-audit-policy-configuration.md b/windows/keep-secure/which-editions-of-windows-support-advanced-audit-policy-configuration.md
index fed78d4afa..35a67350b8 100644
--- a/windows/keep-secure/which-editions-of-windows-support-advanced-audit-policy-configuration.md
+++ b/windows/keep-secure/which-editions-of-windows-support-advanced-audit-policy-configuration.md
@@ -2,46 +2,25 @@
title: Which editions of Windows support advanced audit policy configuration (Windows 10)
description: This reference topic for the IT professional describes which versions of the Windows operating systems support advanced security auditing policies.
ms.assetid: 87c71cc5-522d-4771-ac78-34a2a0825f31
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Which editions of Windows support advanced audit policy configuration
-
-
**Applies to**
-
- Windows 10
-
This reference topic for the IT professional describes which versions of the Windows operating systems support advanced security auditing policies.
-
Versions of the Windows operating system that cannot join a domain do not have access to these features. There is no difference in security auditing support between 32-bit and 64-bit versions.
-
## Are there any special considerations?
-
-
In addition, the following special considerations apply to the various tasks associated with advanced security auditing enhancements:
-
- **Creating an audit policy.** To create an advanced security auditing policy, you must use a computer running any supported version of Windows. You can use the Group Policy Management Console (GPMC) on a computer running a supported version of the Windows client operating system after installing the Remote Server Administration Tools.
-
- **Applying audit policy settings.** If you are using Group Policy to apply the advanced audit policy settings and global object access settings, client computers must be running any supported version of the Windows server operating system or Windows client operating system. In addition, only computers running any of these supported operating systems can provide "reason for access" reporting data.
-
- **Developing an audit policy model.** To plan advanced security audit settings and global object access settings, you must use the GPMC that targets a domain controller running a supported version of the Windows server operating system.
-
- **Distributing the audit policy.** After a Group Policy Object (GPO) that includes advanced security auditing settings is developed, it can be distributed by using domain controllers running any Windows Server operating system. However, if you cannot put client computers running a supported version of the Windows client operating system into a separate organizational unit (OU), you should use Windows Management Instrumentation (WMI) filtering to ensure that the advanced security auditing policy settings are applied only to client computers running a supported version of the Windows client operating system.
-
**Important**
Using both the basic auditing policy settings under **Local Policies\\Audit Policy** and the advanced auditing policy settings under **Advanced Audit Policy Configuration** can cause unexpected results in audit reporting. Therefore, the two sets of audit policy settings should not be combined. If you use advanced audit policy configuration settings, you should enable the **Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings** policy setting under **Local Policies\\Security Options**. This will prevent conflicts between similar settings by forcing basic security auditing to be ignored.
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/why-a-pin-is-better-than-a-password.md b/windows/keep-secure/why-a-pin-is-better-than-a-password.md
index b571b9abd8..5afeb6f914 100644
--- a/windows/keep-secure/why-a-pin-is-better-than-a-password.md
+++ b/windows/keep-secure/why-a-pin-is-better-than-a-password.md
@@ -2,47 +2,37 @@
title: Why a PIN is better than a password (Windows 10)
description: Microsoft Passport in Windows 10 enables users to sign in to their device using a PIN. How is a PIN different from (and better than) a password .
ms.assetid: A6FC0520-01E6-4E90-B53D-6C4C4E780212
-keywords: ["pin", "security", "password"]
+keywords: pin, security, password
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: jdeckerMS
---
# Why a PIN is better than a password
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
Microsoft Passport in Windows 10 enables users to sign in to their device using a PIN. How is a PIN different from (and better than) a password?
-
On the surface, a PIN looks much like a password. A PIN can be a set of numbers, but enterprise policy might allow complex PINs that include special characters and letters, both upper-case and lower-case. Something like **t758A!** could be an account password or a complex Passport PIN. It isn't the structure of a PIN (length, complexity) that makes it better than a password, it's how it works.
+
## PIN is tied to the device
-
-
One important difference between a password and a Passport PIN is that the PIN is tied to the specific device on which it was set up. That PIN is useless to anyone without that specific hardware. Someone who steals your password can sign in to your account from anywhere, but if they steal your PIN, they'd have to steal your physical device too!
Even you can't use that PIN anywhere except on that specific device. If you want to sign in on multiple devices, you have to set up Passport on each device.
## PIN is local to the device
-
A password is transmitted to the server -- it can be intercepted in transmission or stolen from a server. A PIN is local to the device -- it isn't transmitted anywhere and it isn't stored on the server.
-
When the PIN is created, it establishes a trusted relationship with the identity provider and creates an asymmetric key pair that is used for authentication. When you enter your PIN, it unlocks the authentication key and uses the key to sign the request that is sent to the authenticating server.
-
-**Note**
-For details on how Passport uses asymetric key pairs for authentication, see [Microsoft Passport guide](http://go.microsoft.com/fwlink/p/?LinkId=691928).
-
+> **Note:** For details on how Passport uses asymetric key pairs for authentication, see [Microsoft Passport guide](http://go.microsoft.com/fwlink/p/?LinkId=691928).
-
## PIN is backed by hardware
-
The Passport PIN is backed by a Trusted Platform Module (TPM) chip, which is a secure crypto-processor that is designed to carry out cryptographic operations. The chip includes multiple physical security mechanisms to make it tamper resistant, and malicious software is unable to tamper with the security functions of the TPM. All Windows 10 Mobile phones and many modern laptops have TPM.
User key material is generated and available within the Trusted Platform Module (TPM) of the user device, which protects it from attackers who want to capture the key material and reuse it. Because Microsoft Passport uses asymmetrical key pairs, users credentials can’t be stolen in cases where the identity provider or websites the user accesses have been compromised.
@@ -51,53 +41,35 @@ The TPM protects against a variety of known and potential attacks, including PIN
## PIN can be complex
-
The Passport PIN is subject to the same set of IT management policies as a password, such as complexity, length, expiration, and history. Although we generally think of a PIN as a simple four-digit code, administrators can set [policies](implement-microsoft-passport-in-your-organization.md) for managed devices to require a PIN complexity similar to a password. You can require or block: special characters, uppercase characters, lowercase characters, and digits.
## What if someone steals the laptop or phone?
-
To compromise a Microsoft Passport credential that TPM protects, an attacker must have access to the physical device, and then must find a way to spoof the user’s biometrics or guess his or her PIN—and all of this must be done before TPM anti-hammer capabilities lock the device.
-
You can provide additional protection for laptops that don't have TPM by enablng BitLocker and setting a policy to limit failed sign-ins.
**Configure BitLocker without TPM**
-
1. Use the Local Group Policy Editor (gpedit.msc) to enable the following policy:
**Computer Configuration** > **Administrative Templates** > **Windows Components** > **BitLocker Drive Encryption** > **Operating System Drives** > **Require additional authentication at startup**
-
+
2. In the policy option, select **Allow BitLocker without a compatible TPM**, and then click **OK.**
-
3. Go to Control Panel > **System and Security** > **BitLocker Drive Encryption** and select the operating system drive to protect.
-
**Set account lockout threshold**
-
1. Use the Local Group Policy Editor (gpedit.msc) to enable the following policy:
**Computer Configuration** >**Windows Settings** ?**Security Settings** >**Account Policies** > **Account Lockout Policy** > **Account lockout threshold**
-
+
2. Set the number of invalid logon attempts to allow, and then click OK.
## Why do you need a PIN to use Windows Hello?
-
-
Windows Hello is the biometric sign-in for Microsoft Passport in Windows 10: fingerprint, iris, or facial recognition. When you set up Windows Hello, you're asked to create a PIN first. This PIN enables you to sign in using Passport when you can’t use your preferred biometric because of an injury or because the sensor is unavailable or not working properly.
If you only had a biometric sign-in configured and, for any reason, were unable to use that method to sign in, you would have to sign in using your account name and password, which doesn't provide you the same level of protection as Passport.
## Related topics
-
[Manage identity verification using Microsoft Passport](manage-identity-verification-using-microsoft-passport.md)
[Implement Microsoft Passport in your organization](implement-microsoft-passport-in-your-organization.md)
-
-
-
-
-
-
-
-
-
+
\ No newline at end of file
diff --git a/windows/keep-secure/windows-10-enterprise-security-guides.md b/windows/keep-secure/windows-10-enterprise-security-guides.md
index 75dfd59ad1..510675e4ff 100644
--- a/windows/keep-secure/windows-10-enterprise-security-guides.md
+++ b/windows/keep-secure/windows-10-enterprise-security-guides.md
@@ -5,20 +5,19 @@ ms.assetid: 57134f84-bd4b-4b1d-b663-4a2d36f5a7f8
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: challum
+
---
# Enterprise security guides
-
## Purpose
-
Get proven guidance to help you better secure and protect your enterprise by using technologies such as Credential Guard, Device Guard, Microsoft Passport, and Windows Hello. This section offers technology overviews and step-by-step guides.
## In this section
-
@@ -53,14 +52,6 @@ Get proven guidance to help you better secure and protect your enterprise by usi
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/windows-10-mobile-security-guide.md b/windows/keep-secure/windows-10-mobile-security-guide.md
index 7995030e49..1008003440 100644
--- a/windows/keep-secure/windows-10-mobile-security-guide.md
+++ b/windows/keep-secure/windows-10-mobile-security-guide.md
@@ -2,52 +2,44 @@
title: Windows 10 Mobile security guide (Windows 10)
description: This guide provides a detailed description of the most important security features in the Windows 10 Mobile operating system—identity access and control, data protection, malware resistance, and app platform security.
ms.assetid: D51EF508-699E-4A68-A7CD-91D821A97205
-keywords: ["data protection, encryption, malware resistance, smartphone, device, Windows Store"]
+keywords: data protection, encryption, malware resistance, smartphone, device, Windows Store
ms.prod: W10
ms.mktglfcycl: manage
ms.sitesec: library
+ms.pagetype: security; mobile
author: AMeeus
---
# Windows 10 Mobile security guide
-
**Applies to**
-
- Windows 10 Mobile
This guide provides a detailed description of the most important security features in the Windows 10 Mobile operating system—identity access and control, data protection, malware resistance, and app platform security.
## Overview
-
Windows 10 Mobile is specifically designed for smartphones and small tablets. It uses the same security technologies as the Windows 10 operating system to help protect against known and emerging security threats across the spectrum of attack vectors. Several broad categories of security work went into Windows 10 Mobile:
- **Identity and access control.** Microsoft has greatly enhanced identity and access control features to simplify and improve the security of user authentication. These features include Windows Hello and Microsoft Passport, which better protect user identities through easy-to-deploy and easy-to-use multifactor authentication (MFA). (Windows Hello requires either a specialized illuminated infrared \[IR\] camera for facial recognition and iris detection or a finger print reader that supports the Windows Biometric Framework.)
-
- **Data protection.** Confidential data is better protected from compromise than ever before. Windows 10 Mobile uses several data-protection technologies and delivers them in a user-friendly and IT-manageable way.
-
- **Malware resistance.**Windows 10 Mobile helps protect critical system resources and apps to reduce the threat of malware, including support for enterprise-grade secure hardware and Secure Boot.
+- **App platform security.** The Windows 10 Mobile enterprise-grade secure app platform provides multiple layers of security. For example, Windows Store checks all apps for malware to help prevent malware from reaching devices.
-- **App platform security.** The Windows 10 Mobile enterprise-grade secure app platform provides multiple layers of security. For example, Windows Store checks all apps for malware to help prevent malware from reaching devices. In addition, AppContainer application isolation helps prevent any malicious app from compromising other apps.
+In addition, AppContainer application isolation helps prevent any malicious app from compromising other apps.
This guide explains each of these technologies and how they help protect your Windows 10 Mobile devices.
## Identity and access control
-
A fundamental component of security is the notion that a user has a unique identity and that that identity is either allowed or denied access to resources. This notion is traditionally known as access control, which has three parts:
-
- **Identification.** The user (subject) asserts a unique identity to the computer system for the purpose of accessing a resource (object), such as a file or an app.
-
- **Authentication.** Authentication is the process of proving the asserted identity and verifying that the subject is indeed the subject.
-
- **Authorization.** The system compares the authenticated subject’s access rights against the object’s permissions and either allows or denies the requested access.
The way an operating system implements these components makes a difference in preventing attackers from accessing corporate data. Only users who prove their identities and are authorized to access that data can access it. In security, however, there are varying degrees of identity proof and many different requirements for authorization limits. The access control flexibility most corporate environments need presents a challenge for any operating system. Table 1 lists typical Windows access control challenges and the solutions that Windows 10 Mobile offers.
Table 1. Windows 10 Mobile solutions for typical access control challenges
-
@@ -78,9 +70,7 @@ Table 1. Windows 10 Mobile solutions for typical access control challenges
-
-
The following sections describe these challenges and solutions in more detail.
### Microsoft Passport
@@ -88,7 +78,6 @@ The following sections describe these challenges and solutions in more detail.
Microsoft Passport provides strong MFA, fully integrated into Windows devices, to replace passwords. To authenticate, the user must have a Microsoft Azure Active Directory (Azure AD)–registered device and either a PIN or Windows Hello biometric gesture to unlock the device. Microsoft Passport is conceptually similar to a smart card but more flexible, as it doesn’t require a public key infrastructure or the implementation of additional hardware and supports biometric identification.
Microsoft Passport offers three significant advantages over the previous state of Windows authentication: it’s more flexible, it’s based on industry standards, and it more effectively mitigates risks.
-
### It's effective
Microsoft Passport eliminates the use of passwords for logon and so reduces the risk that an attacker will steal and reuse a user’s credentials. User key material, which includes the user’s private key, is available only on the device that generated it. The key material is protected with the TPM, which protects the key material from attackers who want to capture and reuse it. It is a Windows Hardware Certification Program requirement that every Windows 10 Mobile device include a TPM.
@@ -112,26 +101,18 @@ Microsoft Passport is also supported on the desktop, giving organizations a unif
### It's standardized
Both software vendors and enterprise customers have come to realize that proprietary identity and authentication systems are a dead end: the future lies with open, interoperable systems that allow secure authentication across a variety of devices, line-of-business (LOB) apps, and external applications and websites. To this end, a group of industry players formed the Fast Identity Online (FIDO) Alliance. The FIDO Alliance is a nonprofit organization that works to address the lack of interoperability among strong authentication devices as well as the problems users face in creating and remembering multiple user names and passwords. The FIDO Alliance plans to change the nature of authentication by developing specifications that define an open, scalable, interoperable set of mechanisms that supplant reliance on passwords to authenticate users of online services securely. This new standard can allow any business network, app, website, or cloud application to interface with a broad variety of existing and future FIDO-enabled devices and operating system platforms using a standardized set of interfaces and protocols.
-
In 2014, Microsoft joined the board of the FIDO Alliance. FIDO standards enable a universal framework that a global ecosystem delivers for a consistent and greatly improved user experience of strong password-less authentication. The FIDO 1.0 specifications, published in December 2014, provide for two types of authentications: password-less (known as UAF) and second factor (U2F). The FIDO Alliance is working on a set of 2.0 proposals that incorporate the best ideas from its U2F and UAF FIDO 1.0 standards and of course new ideas. Microsoft has contributed Microsoft Passport technology to the FIDO 2.0 specification workgroup for review and feedback and continues to work with the FIDO Alliance as the FIDO 2.0 specification moves forward. Interoperability of FIDO products is a hallmark of FIDO authentication. Microsoft believes that bringing a FIDO solution to market will help solve a critical need for enterprises and consumers alike.
### Windows Hello
Windows Hello is the new biometric framework for Windows 10. Because biometric identification is built directly into the operating system, it allows you to use your iris, face, or fingerprint to unlock your mobile device. Windows Hello unlocks Microsoft Passport credentials, which enable authentication to resources or relying parties such as software-as-a-service applications like Microsoft Office 365.
-
Windows Hello supports three biometric sensor options that are suitable for enterprise scenarios:
- **Facial recognition** uses special IR cameras to reliably tell the difference between a photograph or scan and a living person. Several vendors are shipping external cameras that incorporate this technology, and major manufacturers are already shipping laptops with integrated facial-recognition technology. Both Surface Pro 4 and Surface Book support this technology.
-
- **Fingerprint recognition** uses a sensor to scan the user’s fingerprint. Although fingerprint readers have been available for computers running the Windows operating system for years, the detection, anti-spoofing, and recognition algorithms in Windows 10 are more advanced than in previous Windows versions. Most existing fingerprint readers (whether external to or integrated into laptops or USB keyboards) that support the Windows Biometric Framework will work with Windows Hello.
-
- **Iris scanning** uses cameras designed to scan the user’s iris, the colorful and highly detailed portion of the eye. Because the data must be accurate, iris scanning uses a combination of an IR light source and a high-quality camera. Microsoft Lumia 950 and 950 XL devices support this technology.
-
-**Note**
-Users must create an unlock PIN before they enroll a biometric gesture. The device uses this PIN as a fallback mechanism in situations where it cannot capture the biometric gesture.
-
+> **Note:** Users must create an unlock PIN before they enroll a biometric gesture. The device uses this PIN as a fallback mechanism in situations where it cannot capture the biometric gesture.
-
All three of these biometric factors—the face, the finger, and the iris—are unique to an individual. To capture enough data to uniquely identify an individual, a biometric scanner might initially capture images in multiple conditions or with additional details. For example, an iris scanner will capture images of both eyes; or both with and without eyeglasses or contact lenses.
Spoofing biometric data is often a big concern in enterprise environments. Microsoft employs several anti-spoofing techniques in Windows 10 Mobile that verify the trustworthiness of the biometric device as well as guard against intentional collision with stored biometric measurements. These techniques help improve the false-acceptance rate (the rate at which spoofed biometric data is accepted as authentic) while maintaining the overall usability and manageability of MFA.
@@ -144,17 +125,15 @@ The device that senses the biometric factors must report the data to Windows Hel
## Data protection
-
Windows 10 Mobile continues to provide solutions that help protect information against unauthorized access and disclosure.
-### Device encryption
+### Device encryption
Windows 10 Mobile uses device encryption, based on BitLocker technology, to encrypt all internal storage, including operating system and data storage partitions. The user can activate device encryption, or the IT department can activate and enforce encryption for company-managed devices through MDM tools. When device encryption is turned on, all data stored on the phone is encrypted automatically. A Windows 10 Mobile device with encryption turned on helps protect the confidentiality of data stored if the device is lost or stolen. The combination of Windows Hello lock and data encryption makes it extremely difficult for an unauthorized party to retrieve sensitive information from the device.
You can customize how device encryption works to meet your unique security requirements. Device encryption even enables you to define your own cipher suite. For example, you can specify the algorithm and key size that Windows 10 Mobile uses for data encryption, which Transport Layer Security (TLS) cipher suites are permitted, and whether Federal Information Processing Standard (FIPS) policy is enabled. Table 2 lists the policies you can change to customize device encryption on Windows 10 Mobile devices.
Table 2. Windows 10 cryptography policies
-
@@ -186,9 +165,7 @@ Table 2. Windows 10 cryptography policies
-
-
For a complete list of policies available, see [Policy CSP](http://go.microsoft.com/fwlink/p/?LinkId=733963).
### Enterprise data protection
@@ -200,32 +177,21 @@ One growing risk is authorized users’ accidental disclosure of sensitive data
In Windows 10 Mobile, enterprise data protection (EDP) helps separate personal and enterprise data and prevent data leakage. Key features include its ability to:
- Automatically tag personal and corporate data.
-
- Protect data while it’s at rest on local or removable storage.
-
- Control which apps can access corporate data.
-
- Control which apps can access a virtual private network (VPN) connection.
-
- Prevent users from copying corporate data to public locations.
-**Note**
-EDP is currently being tested in select customer evaluation programs. For more information about EDP, see [Enterprise data protection overview](../whats-new/edp-whats-new-overview.md).
-
+> **Note:** EDP is currently being tested in select customer evaluation programs. For more information about EDP, see [Enterprise data protection overview](../whats-new/edp-whats-new-overview.md).
-
### Enlightenment
Third-party data loss protection solutions usually require developers to wrap their apps. In contrast, EDP puts the intelligence in Windows 10 Mobile so that it doesn’t require wrappers. As a result, most apps require nothing extra to work with EDP.
EDP can enforce policy without the need for an app to change. This means that an app that always handles business data (such as an LOB app) can be added to the allowed list and will always encrypt all data that it handles. However, if the app does not use common controls, cut and paste operations from this app to a non-enterprise app will silently fail. In addition, if the app needs to handle personal data, this data will also be encrypted.
-
Therefore, to improve the user experience, in some cases, developers should enlighten their apps by adding code to and compiling them to use the EDP application programming interfaces. Those cases include apps that:
-
- Don’t use common controls for saving files.
-
- Don’t use common controls for text boxes.
-
- Work on personal and enterprise data simultaneously (for example, contact apps that display personal and enterprise data in a single view; a browser that displays personal and enterprise web pages on tabs within a single instance).
Figure 1 summarizes when an app might require enlightenment to work with EDP. Microsoft Word is a good example. Not only can Word access personal and enterprise data simultaneously, but it can also transmit enterprise data (for example, email attachments containing enterprise data).
@@ -241,15 +207,10 @@ Figure 1. When is enlightenment required?
To configure EDP in an MDM solution that supports it, add authorized apps to the EDP allow list. When a device running Windows 10 Mobile enrolls in the MDM solution, apps that this policy doesn’t authorize won’t have access to enterprise data.
EDP works seamlessly until users try to access enterprise data with or try to paste enterprise data into unauthorized apps or locations on the web. For example, copying enterprise data from an authorized app to another authorized app works as usual, but EDP blocks users from copying enterprise data from an authorized app to an unauthorized app. Likewise, EDP blocks users from using an unauthorized app to open a file that contains enterprise data.
-
In addition, users cannot copy and paste data from authorized apps to unauthorized apps or locations on the Web without triggering one of the EDP protection levels:
-
- **Block.** EDP blocks users from completing the operation.
-
- **Override.** EDP notifies users that the operation is inappropriate but allows them to override the policy, although it logs the operation in the audit log.
-
- **Audit.** EDP does not block or notify users but logs the operation in the audit log.
-
- **Off.** EDP does not block or notify users and does not log operations in the audit log.
### Data separation
@@ -263,9 +224,7 @@ EDP provides the same data separation but neither uses containers nor requires a
In Windows 10 Mobile, visual cues indicate the status of EDP to users (see Figure 2):
- **Start screen.** On the Start screen, apps that an EDP policy manages display a visual cue.
-
- **Files.** In File Explorer, a visual cue indicates whether a file or folder contains enterprise data and is therefore encrypted.
-
For example, Erwin is an employee at Fabrikam. He opens Microsoft Edge from the Start screen and sees that the tile indicates that an EDP policy manages the browser. Erwin opens the Fabrikam sales website and downloads a spreadsheet. In File Explorer, Erwin sees that the file he downloaded has a visual cue which indicates that it’s encrypted and contains enterprise data. When Erwin tries to paste data from that spreadsheet into an app that no EDP policy manages (for example, his Twitter app), Erwin might see a message that allows him to override protection while logging the action, depending on the protection level configured in the EDP policy.
@@ -274,9 +233,7 @@ Figure 2. Visual cues in EDP
## Malware resistance
-
Just as software has automated so much of our lives, malware has automated attacks on our devices. Those attacks are relentless. Malware is constantly changing, and when it infects a device, it can be difficult to detect and remove.
-
The best way to fight malware is to prevent the infection from happening. Windows 10 Mobile provides strong malware resistance because it takes advantage of secured hardware and protects both the startup process and the core operating system architecture.
Table 3 lists specific malware threats and the mitigation that Windows 10 Mobile provides.
@@ -334,14 +291,9 @@ Table 3. Threats and Windows 10 Mobile mitigations
-
-
-**Note**
-Windows 10 Mobile devices use a System on a Chip (SoC) design provided by SoC vendors such as Qualcomm. With this architecture, the SoC vendor and device manufacturers provide the pre-UEFI bootloaders and the UEFI environment. The UEFI environment implements the UEFI Secure Boot standard described in section 27 of the UEFI specification, which can be found at [http://www.uefi.org/specsandtesttools](http://go.microsoft.com/fwlink/p/?LinkId=722912). This standard describes the process by which all UEFI drivers and applications are validated against keys provisioned into a UEFI-based device before they are executed.
-
+> **Note:** Windows 10 Mobile devices use a System on a Chip (SoC) design provided by SoC vendors such as Qualcomm. With this architecture, the SoC vendor and device manufacturers provide the pre-UEFI bootloaders and the UEFI environment. The UEFI environment implements the UEFI Secure Boot standard described in section 27 of the UEFI specification, which can be found at [http://www.uefi.org/specsandtesttools](http://go.microsoft.com/fwlink/p/?LinkId=722912). This standard describes the process by which all UEFI drivers and applications are validated against keys provisioned into a UEFI-based device before they are executed.
-
The following sections describe these improvements in more detail.
### Enterprise-grade secure hardware
@@ -353,11 +305,8 @@ Taking full advantage of Windows 10 Mobile security features requires advanceme
When a Windows 10 Mobile device starts, it begins the process of loading the operating system by locating the bootloader in the device’s storage system. Without safeguards in place, the phone might simply hand control over to the bootloader without even determining whether it’s a trusted operating system or malware.
UEFI is a standards-based solution that offers a modern-day replacement for the BIOS. In fact, it provides the same functionality as BIOS while adding security features and other advanced capabilities. Like BIOS, UEFI initializes devices, but UEFI components with the Secure Boot feature (version 2.3.1 or later) also help ensure that only trusted firmware in Option ROMs, UEFI apps, and operating system bootloaders can start on the mobile phone.
-
UEFI can run internal integrity checks that verify the firmware’s digital signature before running it. Because only the mobile phone’s manufacturer has access to the digital certificate required to create a valid firmware signature, UEFI has protection against firmware-based malware that loads before Windows 10 Mobile and can successfully hide its malicious behavior from Windows 10 Mobile. Firmware-based malware of this nature is typically called a bootkit.
-
When a mobile device with UEFI and Secure Boot starts, the UEFI firmware verifies the bootloader’s digital signature to verify that no one has modified it after it was digitally signed. The firmware also verifies that a trusted authority issued the bootloader’s digital signature. This check helps to ensure that the system starts only after checking that the bootloader is both trusted and unmodified since signing.
-
All Windows 10 Mobile devices always have Secure Boot enabled. In addition, they trust only the Windows operating system signature.
Neither Windows 10 Mobile, apps, or even malware can change the UEFI configuration. For more information about UEFI with Secure Boot, read [Protecting the pre-OS environment with UEFI](http://go.microsoft.com/fwlink/p/?LinkId=722909).
@@ -369,38 +318,25 @@ A Trusted Platform Module is a tamper-resistant cryptographic module that enhanc
A proper implementation of a TPM as part of a trusted computing platform provides a hardware root of trust, meaning that the hardware behaves in a trusted way. For example, if you create a key in a TPM with the property that no one can export that key from the TPM, the key absolutely cannot leave the TPM. The close integration of a TPM with a platform increases the transparency of the boot process and supports device health scenarios by enabling reliable report of the software used to start a platform.
The following list describes key functionality that a TPM provides in Windows 10 Mobile:
-
- **Manage cryptographic keys.** A TPM can create, store, and permit the use of keys in defined ways. Windows 10 Mobile uses the TPM to protect the encryption keys for BitLocker volumes, virtual smart cards, certificates, and various other keys.
-
- **Safeguard and report integrity measurements.**Windows 10 Mobile uses the TPM to record and help protect integrity-related measurements of select hardware and Windows boot components for the Measured Boot feature. In this scenario, Measured Boot measures each component, from firmware up through the drivers, and then stores those measurements in the device’s TPM. From here, you can test the measurement log remotely so that a separate system verifies the boot state of the Windows 10 Mobile device.
-
- **Prove a TPM is really a TPM.** Managing cryptographic keys and measuring integrity are so central to protecting privacy and security that a TPM must differentiate itself from malware that masquerades as a TPM.
Windows 10 Mobile supports TPM implementations that comply with the 2.0 standard. The TPM 2.0 standard includes several improvements that make it superior to the 1.2 standard, the most notable of which is cryptographic agility. TPM 1.2 is restricted to a fixed set of encryption and hash algorithms. At the time the TPM 1.2 standard appeared in the early 2000s, the security community considered these algorithms cryptographically strong. Since that time, advances in cryptographic algorithms and cryptanalysis attacks have increased expectations for stronger cryptography. TPM 2.0 supports additional algorithms that offer stronger cryptographic protection as well as the ability to plug in algorithms that certain geographies or industries may prefer. It also opens the possibility for inclusion of future algorithms without changing the TPM component itself.
-
Many people assume that original equipment manufacturers (OEMs) must implant a TPM in hardware on a motherboard as a discrete module, but TPM can also be effective when implemented in firmware. Windows 10 Mobile supports only firmware TPM that complies with the 2.0 standard. Windows does not differentiate between discrete and firmware-based solutions because both must meet the same implementation and security requirements; therefore, any Windows 10 feature that can take advantage of TPM can be used with Windows 10 Mobile.
-**Note**
-Microsoft requires TPM 2.0 on devices running any version of Windows 10 Mobile. For more information, see [Minimum hardware requirements](http://go.microsoft.com/fwlink/p/?LinkId=733964).
-
+> **Note:** Microsoft requires TPM 2.0 on devices running any version of Windows 10 Mobile. For more information, see [Minimum hardware requirements](http://go.microsoft.com/fwlink/p/?LinkId=733964).
-
Several Windows 10 Mobile security features require TPM:
-
- Virtual smart cards
-
- Measured Boot
-
- Health attestation (requires TPM 2.0 or later)
-
Still other features will use the TPM if it is available. For example, Microsoft Passport does not require TPM but uses it if it’s available. Organizations can configure policy to require TPM for Microsoft Passport.
### Biometrics
Windows 10 Mobile makes biometrics a core security feature. Microsoft has fully integrated biometrics into the Windows 10 Mobile security components, not just tacked it on top of the platform (as was the case in previous versions of Windows). This is a big change. Earlier biometric implementations were largely front-end methods that simplified authentication. Under the hood, the system used biometrics to access a password, which it then used for authentication behind the scenes. Biometrics may have provided convenience but not necessarily enterprise-grade authentication.
-
Microsoft has been evangelizing the importance of enterprise-grade biometric sensors to the OEMs that create Windows 10 Mobile devices. These facial-recognition and iris-scanning sensors are fully supported by MFA features such as Microsoft Passport and Windows Hello.
-
In the future, Microsoft expects OEMs to produce even more advanced enterprise-grade biometric sensors and to continue to integrate them into mobile devices. As a result, biometrics will become a commonplace authentication method as part of an MFA system.
### Enterprise-grade secure Windows startup
@@ -416,15 +352,12 @@ If someone has modified a file (for example, if malware has tampered with it or
### Measured Boot
The biggest challenge with rootkits and bootkits in earlier versions of Windows was that they could frequently be undetectable to the client. Because they often started before Windows defenses and the antimalware solution—and they had system-level privileges—rootkits and bootkits could completely disguise themselves while continuing to access system resources. Although UEFI with Secure Boot and Trusted Boot could prevent most rootkits and bootkits, intruders could still potentially exploit a few attack vectors (for example, if someone compromised the signature used to sign a boot component, such as a non-Microsoft driver, and used it to sign a malicious one).
-
Windows 10 Mobile implements the Measured Boot feature, which uses the TPM hardware component to record a series of measurements for critical startup-related components, including firmware, Windows boot components, and drivers. Because Measured Boot uses the hardware-based security capabilities of TPM, which isolates and protects the measurement data against malware attacks, the log data is well protected against even sophisticated attacks.
-
Measured Boot focuses on acquiring the measurement data and protecting it against tampering. You must couple it, however, with a service that can analyze the data to determine device health and provide a more complete security service. The next section introduces just such a service.
### Device health attestation
Device health attestation is new feature in Windows 10 Mobile that helps prevent low-level malware infections. Device health attestation uses a device’s TPM and firmware to measure the critical security properties of the device’s BIOS and Windows startup processes. These measurements are made in such a way that even on a system infected with kernel-level malware or a rootkit, an attacker is unlikely to spoof the properties.
-
You can integrate Device health attestation with Microsoft Intune or non-Microsoft MDM solutions and combine these hardware-measured security properties with other device properties to gain an overall view of the device’s health and compliance state. From there, you can use this integration in a variety of scenarios, from detecting jailbroken devices to monitoring device compliance, generating compliance reports, alerting users or administrators, initiating corrective action on the device, and managing conditional access to resources such as Office 365.
### Conditional Access
@@ -432,24 +365,16 @@ You can integrate Device health attestation with Microsoft Intune or non-Microso
The example that follows shows how Windows 10 protective measures integrate and work with Intune and non-Microsoft MDM solutions. It demonstrates how the phone security architecture in Windows 10 Mobile helps you monitor and verify compliance and how the security and trust rooted in the device hardware protect corporate resources end to end.
When a user turns on a phone:
-
1. The Secure Boot feature in Windows 10 Mobile helps protect the startup sequence, allows the device to boot into a defined and trusted configuration, and loads a factory-trusted boot loader.
-
2. Windows 10 Mobile Trusted Boot takes control when the Secure Boot process is complete, verifying the digital signature of the Windows kernel and the components that are loaded and executed during the startup process.
-
3. In parallel to steps 1 and 2, the phone’s TPM runs independently in a hardware-protected security zone (isolated from the boot execution path, which monitors boot activities). It creates a protected, tamper-evident audit trail, signed with a secret that only the TPM can access.
-
4. Devices that a Device health attestation-enabled MDM solution manage send a copy of this audit trail to the Microsoft Health Attestation Service (HAS) in a protected, tamper-resistant, and tamper-evident communication channel.
-
5. HAS reviews the audit trails, issues an encrypted and signed report, and forwards it to the device.
-
6. From your Device health attestation-enabled MDM solution, you can review the report in a protected, tamper-resistant, and tamper-evident communication channel to assess whether the device is running in a compliant (healthy) state, allow access, or trigger corrective action aligned with the organization’s security needs and policies.
-
Because this solution can detect and prevent low-level malware that may be extremely difficult to detect any other way, Microsoft recommends that you consider implementing a Device health attestation-enabled MDM system like Intune that takes advantage of the Windows 10 Mobile cloud-based health attestation server feature to detect and block devices infected with advanced malware.
## App platform security
-
Applications built for Windows are designed to be secure and free of defects, but the reality is that human error can create vulnerabilities in code. When malicious users and software identify such vulnerabilities, they may attempt to manipulate data in memory in the hope that they can compromise the system and take control.
To mitigate these risks, Windows 10 Mobile includes a series of improvements to make it more difficult for malware to compromise the device. Windows 10 Mobile even enables organizations to choose which apps are allowed to run on mobile devices. In addition, it includes improvements that can dramatically reduce the likelihood that newly discovered vulnerabilities can be successful exploited. It takes detailed knowledge of operating system architecture and malware exploit techniques to fully appreciate the impact of these improvements, but the sections that follow explain them at a high level.
@@ -473,9 +398,7 @@ A set of default permissions are granted to all AppContainers, including access
The AppContainer concept is advantageous for the following reasons:
- **Attack surface reduction.** Apps can access only those capabilities that are declared in the application code and needed to perform their functions.
-
- **User consent and control.** Capabilities that apps use are automatically published to the app details page in the Windows Store. App access to capabilities that may expose sensitive information automatically prompt the user to acknowledge and provide consent.
-
- **App isolation.** Communication between Windows apps is tightly controlled. Apps are isolated from one another and can communicate only by using predefined communications channels and data types.
Apps receive the minimal privileges they need to perform their legitimate tasks. This means that even if a malicious attacker exploits an app, the potential damage is limited because the app cannot elevate its privileges and is contained within its AppContainer. Windows Store displays the permissions that the app requires along with the app’s age rating and publisher.
@@ -483,7 +406,6 @@ Apps receive the minimal privileges they need to perform their legitimate tasks.
The combination of Device Guard and AppContainer help to prevent unauthorized apps from running. In the event malware slips into the app ecosystem, the AppContainer helps to constrain the app and limit potential damage. The Windows 10 Mobile trust-nothing model doesn’t assume that any component is perfect, however, potential vulnerabilities in apps, AppContainers, and Windows 10 Mobile itself could give an attacker a chance to compromise a system. For this reason, we need redundant vulnerability mitigations. The next several topics describe some of the redundant mitigations in Windows 10 Mobile.
### Address Space Layout Randomization
-
One of the most common techniques attackers use to gain access to a system is to find a vulnerability in a privileged process that is already running, guess or find a location in memory where important system code and data reside, and then overwrite that information with a malicious payload. In the early days of operating systems, any malware that could write directly to the system memory could do such a thing; the malware would simply overwrite system memory in well-known and predictable locations.
Address Space Layout Randomization (ASLR) makes that type of attack much more difficult because it randomizes how and where important data is stored in memory. With ASLR, it is more difficult for malware to find the specific location it needs to attack. Figure 3 illustrates how ASLR works, showing how the locations of different critical Windows components can change in memory between restarts.
@@ -503,13 +425,10 @@ Extending that protection, it would be great if you could prevent malware from r
### Windows heap
The heap is a location in memory that Windows uses to store dynamic application data. Microsoft continues to improve on earlier Windows heap designs by further mitigating the risk of heap exploits that an attacker could use.
-
Windows 10 Mobile has several important improvements to the security of the heap over previous versions of Windows:
- Internal data structures that the heap uses are better protected against memory corruption.
-
- Heap memory allocations have randomized locations and sizes, making it more difficult for an attacker to predict the location of critical memory to overwrite. Specifically, Windows 10 Mobile adds a random offset to the address of a newly allocated heap, which makes the allocation much less predictable.
-
- Windows 10 Mobile uses “guard pages” before and after blocks of memory as tripwires. If an attacker attempts to write past a block of memory (a common technique known as a buffer overflow), the attacker will have to overwrite a guard page. Any attempt to modify a guard page is considered a memory corruption, and Windows 10 Mobile responds by instantly terminating the app.
### Memory reservations
@@ -519,7 +438,6 @@ Microsoft reserves the lowest 64 KB of process memory for the operating system.
### Control Flow Guard
When Windows loads applications into memory, it allocates space to those applications based on the size of the code, requested memory, and other factors. When an application begins to execute code, it calls additional code located in other memory addresses. The relationships among the code locations are well known—they are written in the code itself—but until Windows 10 Mobile, the operating system didn’t enforce the flow among these locations, giving attackers the opportunity to change the flow to meet their needs. In other words, an application exploit takes advantage of this behavior by running code that the application may not typically run.
-
Windows 10 Mobile mitigates this kind of threat through the Control Flow Guard (CFG) feature. When a trusted application that its creator compiled to use CFG calls code, CFG verifies that the code location called is trusted for execution. If CFG doesn’t trust the location, it immediately terminates the application as a potential security risk.
You cannot configure CFG; rather, an application developer can take advantage of CFG by configuring it when he or she compiles the application. Consider asking application developers and software vendors to deliver trustworthy Windows applications compiled with CFG enabled. Of course, browsers are a key entry point for attacks; thus Microsoft Edge and other Windows features take full advantage of CFG.
@@ -565,7 +483,6 @@ Store for Business allows you to find the right apps for your users, acquire the
You begin the app deployment process by preparing the private store and the apps before your users receive their new Windows 10 Mobile devices.
First, you open [Windows Store for Business](http://go.microsoft.com/fwlink/p/?LinkId=722910) and use an Azure AD account to log in. This account is linked to the company’s unique organizational identity and must have an Azure AD tenant. In addition, the account must have Azure AD Enterprise Admin permissions if this is the first time you’re using Store for Business. You can delegate later access through permissions within Store for Business.
-
Next, you locate and acquire any apps you want to deploy to the mobile devices, adding the apps and licenses to the organization’s inventory.
Along with existing Windows Store apps, you can use Store for Business to manage custom LOB apps that are developed for your organization. First, you grant permission for a trusted app developer to submit the apps. You and the developer submit these apps through the [Windows Dev Center](http://go.microsoft.com/fwlink/p/?LinkId=722911), and they must be digitally signed with a trusted certificate. These apps are not published to the retail Windows Store catalog and are not visible to anyone outside the organization.
@@ -573,11 +490,8 @@ Along with existing Windows Store apps, you can use Store for Business to manage
You can deliver the apps through a private store within Windows Store. The next step, then, is for you to mark the app to be available in the private store, which you do through the Store for Business web portal.
Alternatively, you can choose one of two other app-distribution options in Store for Business web portal:
-
- Assign the app to people in your organization by selecting one or more Azure AD identities
-
- Add the app to the organization’s private store, and allow all users to discover and install it.
-
For details about app distribution, see [Distribute apps using your private store](../manage/distribute-apps-from-your-private-store.md).
The IT process for preparing Store for Business for app deployment is shown in Figure 4.
@@ -605,11 +519,8 @@ If the user wants to make a private purchase of apps, music, movies, or TV shows
Windows 10 Mobile includes critical improvements designed to thwart attacks and malware. The environment is now more resistant to malware thanks to significant improvements to SmartScreen Filters. Internet browsing is a safer experience thanks to Microsoft Edge, a completely new browser.
Windows 10 Mobile includes Microsoft Edge, an entirely new web browser that goes beyond browsing with features like Reading View. Microsoft Edge is more secure than previous Microsoft web browsers in several ways:
-
- **Microsoft Edge does not support non-Microsoft binary extensions.** Microsoft Edge supports Flash content and PDF viewing by default through built-in extensions but includes no non-Microsoft binary extensions, such as ActiveX controls or Java.
-
- **Microsoft Edge is designed as a UWP app.** It is inherently compartmentalized and runs in an AppContainer that sandboxes the browser from the system, data, and other apps.
-
- **Microsoft Edge simplifies security configuration tasks.** Because Microsoft Edge uses a simplified application structure and a single sandbox configuration, fewer security settings are required. In addition, Microsoft established Microsoft Edge default settings that align with security best practices, making it more secure by design.
The web browser is a critical component of any security strategy, and for good reason: it is the user’s interface to the Internet, an environment teeming with malicious sites and nefarious content. Most users cannot perform at least part of their job without a browser, and many users are completely reliant on one. This reality has made the browser the number one pathway from which malicious hackers initiate their attacks.
@@ -626,12 +537,3 @@ The web browser is a critical component of any security strategy, and for good r
[Windows Store for Business](http://go.microsoft.com/fwlink/p/?LinkId=722910)
[Windows Store for Business overview](../whats-new/windows-store-for-business-overview.md)
-
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/windows-10-security-guide.md b/windows/keep-secure/windows-10-security-guide.md
index 586d509b57..2c0402513c 100644
--- a/windows/keep-secure/windows-10-security-guide.md
+++ b/windows/keep-secure/windows-10-security-guide.md
@@ -2,48 +2,38 @@
title: Windows 10 security overview (Windows 10)
description: This guide provides a detailed description of the most important security improvements in the Windows 10 operating system, with links to more detailed articles about many of its security features.
ms.assetid: 4561D80B-A914-403C-A17C-3BE6FC95B59B
-keywords: ["configure", "feature", "file encryption"]
+keywords: configure, feature, file encryption
ms.prod: W10
ms.mktglfcycl: manage
ms.sitesec: library
+ms.pagetype: security
author: challum
---
# Windows 10 security overview
-
**Applies to**
-
- Windows 10
This guide provides a detailed description of the most important security improvements in the Windows 10 operating system, with links to more detailed articles about many of its security features. Wherever possible, specific recommendations are provided to help you implement and configure Windows 10 security features.
## Introduction
-
Windows 10 is designed to protect against known and emerging security threats across the spectrum of attack vectors. Three broad categories of security work went into Windows 10:
-
- [**Identity and access control**](#identity) features have been greatly expanded to both simplify and enhance the security of user authentication. These features include Windows Hello and Microsoft Passport, which better protect user identities through easy-to-deploy and easy-to-use multifactor authentication (MFA). Another new feature is Credential Guard, which uses virtualization-based security (VBS) to help protect the Windows authentication subsystems and users’ credentials.
-
- [**Information protection**](#information) that guards information at rest, in use, and in transit. In addition to BitLocker and BitLocker To Go for protection of data at rest, Windows 10 includes file-level encryption with Enterprise Data Protection that performs data separation and containment and, when combined with Rights Management services, can keep data encrypted when it leaves the corporate network. Windows 10 can also help keep data secure by using virtual private networks (VPNs) and Internet Protocol Security.
-
- [**Malware resistance**](#malware) includes architectural changes that can isolate critical system and security components from threats. Several new features in Windows 10 help reduce the threat of malware, including VBS, Device Guard, Microsoft Edge, and an entirely new version of Windows Defender. In addition, the many antimalware features from the Windows 8.1 operating system— including AppContainers for application sandboxing and numerous boot-protection features, such as Trusted Boot—have been carried forward and improved in Windows 10.
## Identity and access control
-
Traditionally, access control is a process that has three components:
-
- **Identification** - when a user asserts a unique identity to the computer system for the purpose of gaining access to a resource, such as a file or a printer. In some definitions, the user is called the subject and the resource is the object.
-
- **Authentication** - the process of proving the asserted identity and verification that the subject is indeed *the* subject.
-
- **Authorization** - performed by the system to compare the authenticated subject’s access rights against the object’s permissions and either allow or deny the requested access.
The way these components are implemented makes the difference in stopping attackers from accessing secret data. Only a user who proves his or her identity – and is authorized to access that data – will access it. But in security, there are varying degrees of identity proof and many different requirements for authorization limits. The access control flexibility needed in most corporate environments presents a challenge for any operating system. Table 1 lists typical Windows access control challenges and the Windows 10 solutions.
Table 1. Windows 10 solutions to typical access control challenges
-
@@ -80,15 +70,12 @@ Table 1. Windows 10 solutions to typical access control challenges
-
-
The sections that follow describe these challenges and solutions in more detail.
**Microsoft Passport**
Microsoft Passport provides strong two-factor authentication (2FA), fully integrated into Windows, and replaces passwords with the combination of an enrolled device and either a PIN or Windows Hello. Microsoft Passport is conceptually similar to smart cards but more flexible. Authentication is performed by using an asymmetric key pair instead of a string comparison (for example, password), and the user’s key material can be secured by using hardware.
-
Unlike smart cards, Microsoft Passport does not require the extra infrastructure components required for smart card deployment. In particular, you do not need public key infrastructure (PKI). If you already use PKI – for example, in secure email or VPN authentication – you can use the existing infrastructure with Microsoft Passport. Microsoft Passport combines the major advantages of smart card technology – deployment flexibility for virtual smart cards and robust security for physical smart cards – without any of their drawbacks.
Microsoft Passport offers three significant advantages over the current state of Windows authentication: It’s more flexible, it’s based on industry standards, and it effectively mitigates risks. The sections that follow look at each of these advantages in more detail.
@@ -124,17 +111,16 @@ The user’s biometric data that is used for Windows Hello is considered a local
Windows Hello supports two biometric sensor options that are suitable for enterprise scenarios:
- **Facial recognition** uses special infrared cameras to reliably tell the difference between a photograph or scan and a living person. Several vendors are shipping external cameras that incorporate this technology, and major manufacturers are already shipping integrated devices with facial-recognition technology.
-
- **Fingerprint recognition** uses a fingerprint sensor to scan the user’s fingerprint. Although fingerprint readers have been available for computers running Windows for years, the detection, antispoofing, and recognition algorithms in Windows 10 are more advanced than previous Windows versions. Most existing fingerprint readers (whether external or integrated into laptops or USB keyboards) can be used with Windows Hello.
-Windows Hello offers several major benefits. First, it addresses the problems of credential theft and sharing, because an attacker must obtain the device and impersonate the user’s biometric identity, which is more difficult than stealing a password or PIN. Second, the use of biometrics gives users an authenticator that’s always with them – there’s nothing to forget, lose, or leave behind. Instead of worrying about memorizing long, complex passwords, users can take advantage of a convenient, secure method for logging in to all their Windows devices. Finally, there’s nothing additional to deploy or manage. Because Windows Hello support is built directly into the operating system, there are no additional drivers to deploy.
+Windows Hello offers several major benefits. First, it addresses the problems of credential theft and sharing, because an attacker must obtain the device and impersonate the user’s biometric identity, which is more difficult than stealing a password or PIN. Second, the use of biometrics gives users an authenticator that’s always with them – there’s nothing to forget, lose, or leave behind. Instead of worrying about memorizing long, complex passwords, users can take advantage of a convenient, secure method for logging in to all their Windows devices. Finally, there’s nothing additional to deploy or manage. Because Windows Hello support is built directly into the operating system,
+there are no additional drivers to deploy.
**Brute-force attack resistance**
A brute-force attack is the process used to break into a device simply by guessing a user’s password, PIN, or even his or her biometric identity over and over until the attacker gets it right. Over the last several versions of Windows, Microsoft has added features that dramatically reduce the chances that such an attack would succeed.
The Windows 7 operating system and previous versions defended against brute-force attacks in a straightforward way: they slowed or prevented additional guesses after multiple mistakes. When users use a full password to log on, Windows forces users to wait several seconds between attempts if they type their password incorrectly multiple times. You can even choose to have Windows lock out an account for a period of time when it detects a brute-force attack.
-
Windows 8.1 and Windows 10 support an even more powerful – but optional – form of brute-force protection when the credentials are tied to TPM. If the operating system detects a brute-force attack against the Windows sign-in and BitLocker protects the system drive, Windows can automatically restart the device and put it in BitLocker recovery mode until someone enters a recovery key password. This password is a virtually unguessable 48-character recovery code that must be used before Windows will be able to start normally.
If you’re interested in learning how to configure brute-force protection, use a test Windows 10 PC on which BitLocker protection is enabled for the system drive, and then print the BitLocker recovery key to ensure that you have it available. Then, open the Local Group Policy Editor by running **gpedit.msc**, and go to Computer Configuration\\Windows Settings\\Security Settings\\Security Options. Open the policy **Interactive Login: Machine Account Lockout Threshold**, and set the value to **5**, as shown in Figure 1.
@@ -147,7 +133,6 @@ Now, your PC is configured with brute-force protection. Restart your PC. When pr
## Information protection
-
When users travel, their organization’s confidential data goes with them. Wherever confidential data is stored, it must be protected against unauthorized access. Windows has a long history of providing at-rest data-protection solutions that guard against nefarious attackers, beginning with the Encrypting File System in the Windows 2000 operating system. More recently, BitLocker has provided encryption for full drives and portable drives; in Windows 10, BitLocker will even protect individual files, with data loss prevention capabilities. Windows consistently improves data protection by improving existing options and by providing new strategies.
Table 2 lists specific data-protection concerns and how they are addressed in Windows 10 and Windows 7.
@@ -202,33 +187,25 @@ Table 2. Data Protection in Windows 10 and Windows 7
-
-
The sections that follow describe these improvements in more detail.
**Prepare for drive and file encryption**
The best type of security measures are transparent to the user during implementation and use. Every time there is a possible delay or difficulty because of a security feature, there is strong likelihood that users will try to bypass security. This situation is especially true for data protection, and that’s a scenario that organizations need to avoid.
-
Whether you’re planning to encrypt entire volumes, removable devices, or individual files, Windows 10 meets your needs by providing streamlined, usable solutions. In fact, you can take several steps in advance to prepare for data encryption and make the deployment quick and smooth.
**TPM pre-provisioning**
In Windows 7, preparing the TPM for use offered a couple of challenges:
-
- You can turn on the TPM in the BIOS, which requires someone to either go into the BIOS settings to turn it on or to install a driver to turn it on from within Windows.
-
- When you enable the TPM, it may require one or more restarts.
-
Basically, it was a big hassle. If IT staff were provisioning new PCs, they could handle all of this, but if you wanted to add BitLocker to devices that were already in users’ hands, those users would have struggled with the technical challenges and would either call IT for support or simply leave BitLocker disabled.
-
Microsoft includes instrumentation in Windows 10 that enables the operating system to fully manage the TPM. There is no need to go into the BIOS, and all scenarios that required a restart have been eliminated.
**Deploy hard drive encryption**
BitLocker is capable of encrypting entire hard drives, including both system and data drives. BitLocker pre-provisioning can drastically reduce the time required to provision new PCs with BitLocker enabled. With Windows 10, administrators can turn on BitLocker and the TPM from within the Windows Preinstallation Environment before they install Windows or as part of an automated deployment task sequence without any user interaction. Combined with Used Disk Space Only encryption and a mostly empty drive (because Windows is not yet installed), it takes only a few seconds to enable BitLocker.
-
With earlier versions of Windows, administrators had to enable BitLocker after Windows had been installed. Although this process could be automated, BitLocker would need to encrypt the entire drive, a process that could take anywhere from several hours to more than a day depending on drive size and performance, which significantly delayed deployment. Microsoft has improved this process through multiple features in Windows 10.
**Device encryption**
@@ -236,57 +213,39 @@ With earlier versions of Windows, administrators had to enable BitLocker after W
Beginning in Windows 8.1, Windows automatically enables BitLocker device encryption on devices that support InstantGo. With Windows 10, Microsoft offers device encryption support on a much broader range of devices, including those that are InstantGo. Microsoft expects that most devices in the future will pass the testing requirements, which makes device encryption pervasive across modern Windows devices. Device encryption further protects the system by transparently implementing device-wide data encryption.
Unlike a standard BitLocker implementation, device encryption is enabled automatically so that the device is always protected. The following list outlines how this happens:
-
- When a clean installation of Windows 10 is completed and the out-of-box experience is finished, the computer is prepared for first use. As part of this preparation, device encryption is initialized on the operating system drive and fixed data drives on the computer with a clear key (this is the equivalent of standard BitLocker suspended state).
-
- If the device is not domain joined, a Microsoft account that has been granted administrative privileges on the device is required. When the administrator uses a Microsoft account to sign in, the clear key is removed, a recovery key is uploaded to the online Microsoft account, and a TPM protector is created. Should a device require the recovery key, the user will be guided to use an alternate device and navigate to a recovery key access URL to retrieve the recovery key by using his or her Microsoft account credentials.
-
- If the user uses a domain account to sign in, the clear key is not removed until the user joins the device to a domain and the recovery key is successfully backed up to Active Directory Domain Services (AD DS). You must enable the **Computer Configuration\\Administrative Templates\\Windows Components\\BitLocker Drive Encryption\\Operating System Drives** Group Policy setting, and select the **Do not enable BitLocker until recovery information is stored in AD DS for operating system drives** option. With this configuration, the recovery password is created automatically when the computer joins the domain, and then the recovery key is backed up to AD DS, the TPM protector is created, and the clear key is removed.
-
- Similar to signing in with a domain account, the clear key is removed when the user logs on to an Azure AD account on the device. As described in the bullet point above, the recovery password is created automatically when the user authenticates to Azure AD. Then, the recovery key is backed up to Azure AD, the TPM protector is created, and the clear key is removed.
-
Microsoft recommends that device encryption be enabled on any systems that support it, but the automatic device encryption process can be prevented by changing the following registry setting:
-
- **Subkey**: HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\BitLocker
-
- **Value**: PreventDeviceEncryption equal to True (1)
-
- **Type**: REG\_DWORD
-
Administrators can manage domain-joined devices that have device encryption enabled through Microsoft BitLocker Administration and Monitoring (MBAM). In this case, device encryption automatically makes additional BitLocker options available. No conversion or encryption is required, and MBAM can manage the full BitLocker policy set if any configuration changes are required.
**Used Disk Space Only encryption**
BitLocker in earlier Windows versions could take a long time to encrypt a drive, because it encrypted every byte on the volume (including parts that did not have data). That is still the most secure way to encrypt a drive, especially if a drive has previously contained confidential data that has since been moved or deleted, in which case traces of the confidential data could remain on portions of the drive marked as unused.
-
But why encrypt a new drive when you can simply encrypt the data as it is being written? To reduce encryption time, BitLocker in Windows 10 lets users choose to encrypt just their data. Depending on the amount of data on the drive, this option can reduce encryption time by more than 99 percent.
-
Exercise caution when encrypting only used space on an existing volume on which confidential data may have already been stored in an unencrypted state, however, because those sectors can be recovered through disk-recovery tools until they are overwritten by new encrypted data. In contrast, encrypting only used space on a brand-new volume can significantly decrease deployment time without the security risk because all new data will be encrypted as it is written to the disk.
**Encrypted hard drive support**
SEDs have been available for years, but Microsoft couldn’t support their use with some earlier versions of Windows because the drives lacked important key management features. Microsoft worked with storage vendors to improve the hardware capabilities, and now BitLocker supports the next generation of SEDs, which are called encrypted hard drives.
-
Encrypted hard drives provide onboard cryptographic capabilities to encrypt data on drives, which improves both drive and system performance by offloading cryptographic calculations from the PC’s processor to the drive itself and rapidly encrypting the drive by using dedicated, purpose-built hardware. If you plan to use whole-drive encryption with Windows 10, Microsoft recommends that you investigate hard drive manufacturers and models to determine whether any of their encrypted hard drives meet your security and budget requirements.
-
For more information about encrypted hard drives, see [Encrypted Hard Drive](http://go.microsoft.com/fwlink/p/?LinkId=733880).
**Preboot information protection**
An effective information protection implementation, like most security controls, considers usability as well as security. Users typically prefer a simple security experience. In fact, the more transparent a security solution becomes, the more likely users are to conform to it.
-
It is crucial that organizations protect information on their PCs regardless of the state of the computer or the intent of users. This protection should not be cumbersome to users. One undesirable and previously commonplace situation is when the user is prompted for input during preboot, and then again during Windows logon. Challenging users for input more than once should be avoided.
-
Windows 10 can enable a true SSO experience from the preboot environment on modern devices and in some cases even on older devices when robust information protection configurations are in place. The TPM in isolation is able to securely protect the BitLocker encryption key while it is at rest, and it can securely unlock the operating system drive. When the key is in use and thus in memory, a combination of hardware and Windows capabilities can secure the key and prevent unauthorized access through cold-boot attacks. Although other countermeasures like PIN-based unlock are available, they are not as user-friendly; depending on the devices’ configuration they may not offer additional security when it comes to key protection. For more information about how to configure BitLocker for SSO, see [BitLocker Countermeasures](bitlocker-countermeasures.md).
**Manage passwords and PINs**
When BitLocker is enabled on a system drive and the PC has a TPM, you can choose to require that users type a PIN before BitLocker will unlock the drive. Such a PIN requirement can prevent an attacker who has physical access to a PC from even getting to the Windows logon, which makes it virtually impossible for the attacker to access or modify user data and system files.
-
Requiring a PIN at startup is a useful security feature because it acts as a second authentication factor (a second “something you know”). This configuration comes with some costs, however. One of the most significant is the need to change the PIN regularly. In enterprises that used BitLocker with Windows 7 and the Windows Vista operating system, users had to contact systems administrators to update their BitLocker PIN or password. This requirement not only increased management costs but made users less willing to change their BitLocker PIN or password on a regular basis.
-
Windows 10 users can update their BitLocker PINs and passwords themselves, without administrator credentials. Not only will this feature reduce support costs, but it could improve security, too, because it encourages users to change their PINs and passwords more often. In addition, InstantGo devices do not require a PIN for startup: They are designed to start infrequently and have other mitigations in place that further reduce the attack surface of the system.
-
For more information about how startup security works and the countermeasures that Windows 10 provides, see [Protect BitLocker from pre-boot attacks](protect-bitlocker-from-pre-boot-attacks.md).
**Configure Network Unlock**
@@ -294,48 +253,29 @@ For more information about how startup security works and the countermeasures th
Some organizations have location-specific data security requirements. This is most common in environments where high-value data is stored on PCs. The network environment may provide crucial data protection and enforce mandatory authentication; therefore, policy states that those PCs should not leave the building or be disconnected from the corporate network. Safeguards like physical security locks and geofencing may help enforce this policy as reactive controls. Beyond these, a proactive security control that grants data access only when the PC is connected to the corporate network is necessary.
Network Unlock enables BitLocker-protected PCs to start automatically when connected to a wired corporate network on which Windows Deployment Services runs. Anytime the PC is not connected to the corporate network, a user must type a PIN to unlock the drive (if PIN-based unlock is enabled).
-
Network Unlock requires the following infrastructure:
-
- Client PCs that have Unified Extensible Firmware Interface (UEFI) firmware version 2.3.1 or later, which supports Dynamic Host Configuration Protocol (DHCP)
-
- A server running Windows Server 2012 with the Windows Deployment Services role
-
- A server with the DHCP server role installed
-
For more information about how to configure Network Unlock, see [BitLocker: How to enable Network Unlock](http://go.microsoft.com/fwlink/p/?LinkId=733905).
-
**Microsoft BitLocker Administration and Monitoring**
-
Part of the Microsoft Desktop Optimization Pack, MBAM makes it easier to manage and support BitLocker and BitLocker To Go. MBAM 2.5 with Service Pack 1, the latest version, has the following key features:
-
- Enables administrators to automate the process of encrypting volumes on client computers across the enterprise.
-
- Enables security officers to quickly determine the compliance state of individual computers or even of the enterprise itself.
-
- Provides centralized reporting and hardware management with Microsoft System Center Configuration Manager.
-
- Reduces the workload on the help desk to assist end users with BitLocker recovery requests.
-
- Enables end users to recover encrypted devices independently by using the Self-Service Portal.
-
- Enables security officers to easily audit access to recovery key information.
-
- Empowers Windows Enterprise users to continue working anywhere with the assurance that their corporate data is protected.
-
- Enforces the BitLocker encryption policy options that you set for your enterprise.
-
- Integrates with existing management tools, such as System Center Configuration Manager.
-
- Offers an IT-customizable recovery user experience.
-
- Supports Windows 10.
For more information about MBAM, including how to obtain it, see [Microsoft BitLocker Administration and Monitoring](http://go.microsoft.com/fwlink/p/?LinkId=626935) on the MDOP TechCenter.
## Malware resistance
-
In movies, security threats always seem to be initiated by a nefarious hacker sitting in front of a monitor with green text scrolling across it. In the real world, the vast majority of security threats occur without any human interaction at all. Just as software has automated so much of our lives, malware has automated attacks on our PCs. Those attacks are relentless. Malware is constantly changing, and when it infects a PC, it can in some cases be extremely difficult to detect and remove.
Prevention is the best bet, and Windows 10 provides strong malware resistance because it takes advantage of secure hardware, which secures the startup process, the core operating system architecture, and the desktop.
@@ -389,27 +329,20 @@ Table 3. Threats and Windows 10 mitigations
-
-
The sections that follow describe these improvements in more detail.
**SMB hardening improvements for SYSVOL and NETLOGON connections**
In Windows 10 and Windows Server 2016 Technical Preview, client connections to the Active Directory Domain Services default SYSVOL and NETLOGON shares on domain controllers now require Server Message Block (SMB) signing and mutual authentication (such as Kerberos).
-
- **What value does this change add?**
This change reduces the likelihood of man-in-the-middle attacks.
-
- **What works differently?**
If SMB signing and mutual authentication are unavailable, a Windows 10 or Windows Server 2016 computer won’t process domain-based Group Policy and scripts.
-
-
> **Note:** The registry values for these settings aren’t present by default, but the hardening rules still apply until overridden by Group Policy or other registry values.
For more information on these security improvements, (also referred to as UNC hardening), see [Microsoft Knowledge Base article 3000483](http://go.microsoft.com/fwlink/p/?LinkId=789216) and [MS15-011 & MS15-014: Hardening Group Policy](http://go.microsoft.com/fwlink/p/?LinkId=789215).
-
**Secure hardware**
Although Windows 10 is designed to run on almost any hardware capable of running Windows 8, Windows 7, or Windows Vista, taking full advantage of Windows 10 security requires advancements in hardware-based security, including UEFI with Secure Boot, CPU virtualization features (for example, Intel VT-x), CPU memory-protection features (for example, Intel VT-d), TPM, and biometric sensors.
@@ -419,7 +352,6 @@ Although Windows 10 is designed to run on almost any hardware capable of runnin
When a PC starts, it begins the process of loading the operating system by locating the bootloader on the PC’s hard drive. Without safeguards in place, the PC may simply hand control over to the bootloader without even determining whether it is a trusted operating system or malware.
UEFI is a standards-based solution that offers a modern-day replacement for the BIOS. In fact, it provides the same functionality as BIOS while adding security features and other advanced capabilities. Like BIOS, UEFI initializes devices, but UEFI components with the Secure Boot feature (version 2.3.1 or later) also ensure that only trusted firmware in Option ROMs, UEFI apps, and operating system bootloaders can start on the device.
-
UEFI can run internal integrity checks that verify the firmware’s digital signature before running it. Because only the PC’s hardware manufacturer has access to the digital certificate required to create a valid firmware signature, UEFI has protection from firmware bootkits. Thus, UEFI is the first link in the chain of trust.
UEFI with Secure Boot became a hardware requirement starting with Windows 8 devices. If a PC supports UEFI, it must be enabled by default. It is possible to disable the Secure Boot feature on many devices, but Microsoft strongly discourages doing so because it dramatically reduces the security of the startup process.
@@ -427,35 +359,25 @@ UEFI with Secure Boot became a hardware requirement starting with Windows 8 dev
When a PC with UEFI and Secure Boot starts, the UEFI firmware verifies the bootloader’s digital signature to verify that it has not been modified after it was digitally signed. The firmware also verifies that a trusted authority issued the bootloader’s digital signature. This check helps to ensure that the system starts only after checking that the bootloader is both trusted and unmodified since signing.
All Windows 8 certified PCs must meet several requirements related to Secure Boot:
-
- They must have Secure Boot enabled by default.
-
- They must trust Microsoft’s certification authority (CA) and thus any bootloader Microsoft has signed.
-
- They must allow the user to add signatures and hashes to the UEFI database.
-
- They must allow the user to completely disable Secure Boot (although administrators can restrict this).
This behavior doesn’t limit the choice of operating system. In fact, users typically have three options for running non-Microsoft operating systems:
-
-- **Use an operating system with a Microsoft-signed bootloader.** Microsoft offers a service to sign non-Microsoft bootloaders so that they can be used on the device. In this case, a signature from the Microsoft third-party UEFI CA is used to sign the non-Microsoft bootloader, and the signature itself is added to the UEFI database. Several non-Microsoft operating systems, including several varieties of Linux, have had their bootloaders signed by Microsoft so that they can take advantage of the Secure Boot capability. For more information about the Microsoft third-party UEFI signing policy, read [Microsoft UEFI CA Signing policy updates](http://go.microsoft.com/fwlink/p/?LinkId=626936) and [Pre-submission testing for UEFI submissions](http://go.microsoft.com/fwlink/p/?LinkId=626937).
+- **Use an operating system with a Microsoft-signed bootloader.** Microsoft offers a service to sign non-Microsoft bootloaders so that they can be used on the device. In this case, a signature from the Microsoft third-party UEFI
+CA is used to sign the non-Microsoft bootloader, and the signature itself is added to the UEFI database. Several non-Microsoft operating systems, including several varieties of Linux, have had their bootloaders signed by Microsoft so that they can take advantage of the Secure Boot capability. For more information about the Microsoft third-party UEFI signing policy, read [Microsoft UEFI CA Signing policy updates](http://go.microsoft.com/fwlink/p/?LinkId=626936) and [Pre-submission testing for UEFI submissions](http://go.microsoft.com/fwlink/p/?LinkId=626937).
**Note**
PCs configured to use Device Guard boot only a secured version of Windows and do not permit a third-party bootloader. For more information, see the [Device Guard](#device-guard) section of this document.
-
-
- **Configure UEFI to trust a non–Microsoft-signed bootloader or hashes.** Some Certified For Windows 8 or later PCs allow users to add noncertified bootloaders through a signature or hashes sent to the UEFI database, which allows them to run any operating system without Microsoft signing it.
-
- **Turn off Secure Boot.**Windows 8 certified PCs allow users to turn off Secure Boot so they can run unsigned operating systems. In this mode, the behavior is identical to PCs that have BIOS: The PC simply runs the bootloader without any verification. Microsoft strongly recommends that Secure Boot remain enabled whenever the device starts so that it can help prevent bootkit infections.
**Note**
With Windows 10, original equipment manufacturers (OEMs) have the ability to ship built-to-order PCs that lock down UEFI Secure Boot so that it cannot be disabled and allows only the operating system of the customer’s choice to start on the device.
-
-
Windows, apps, and even malware cannot change the UEFI configuration. Instead, users must be physically present to manually boot a PC into a UEFI shell, and then change UEFI firmware settings. For more information about UEFI Secure Boot, read [Protecting the pre-OS environment with UEFI](http://go.microsoft.com/fwlink/p/?LinkId=626938).
-
**Virtualization-based security**
One of the most powerful changes to Windows 10 is virtual-based security. Virtual-based security (VBS) takes advantage of advances in PC virtualization to change the game when it comes to protecting system components from compromise. VBS is able to isolate some of the most sensitive security components of Windows 10. These security components aren’t just isolated through application programming interface (API) restrictions or a middle-layer: They actually run in a different virtual environment and are isolated from the Windows 10 operating system itself.
@@ -463,11 +385,8 @@ One of the most powerful changes to Windows 10 is virtual-based security. Virtu
VBS and the isolation it provides is accomplished through the novel use of the Hyper V hypervisor. In this case, instead of running other operating systems on top of the hypervisor as virtual guests, the hypervisor supports running the VBS environment in parallel with Windows and enforces a tightly limited set of interactions and access between the environments.
Think of the VBS environment as a miniature operating system: It has its own kernel and processes. Unlike Windows, however, the VBS environment runs a micro-kernel and only two processes called trustlets:
-
- **Local Security Authority (LSA)** enforces Windows authentication and authorization policies. LSA is a well-known security component that has been part of Windows since 1993. Sensitive portions of LSA are isolated within the VBS environment and are protected by a new feature called Credential Guard.
-
- **Hypervisor-enforced code integrity** verifies the integrity of kernel-mode code prior to execution. This is a part of the [Device Guard](#device-guard) feature described later in this document.
-
VBS provides two major improvements in Windows 10 security: a new trust boundary between key Windows system components and a secure execution environment within which they run. A trust boundary between key Windows system components is enabled though the VBS environment’s use of platform virtualization to isolate the VBS environment from the Windows operating system. Running the VBS environment and Windows operating system as guests on top of Hyper-V and the processor’s virtualization extensions inherently prevents the guests from interacting with each other outside the limited and highly structured communication channels between the trustlets within the VBS environment and Windows operating system.
VBS acts as a secure execution environment because the architecture inherently prevents processes that run within the Windows environment – even those that have full system privileges – from accessing the kernel, trustlets, or any allocated memory within the VBS environment. In addition, the VBS environment uses TPM 2.0 to protect any data that is persisted to disk. Similarly, a user who has access to the physical disk is unable to access the data in an unencrypted form.
@@ -479,54 +398,36 @@ The VBS architecture is illustrated in Figure 2.
Figure 2. The VBS architecture
Note that VBS requires a system that includes:
-
- Windows 10 Enterprise Edition
-
- A-64-bit processor
-
- UEFI with Secure Boot
-
- Second-Level Address Translation (SLAT) technologies (for example, Intel Extended Page Tables \[EPT\], AMD Rapid Virtualization Indexing \[RVI\])
-
- Virtualization extensions (for example, Intel VT-x, AMD RVI)
-
- I/O memory management unit (IOMMU) chipset virtualization (Intel VT-d or AMD-Vi)
-
- TPM 2.0
**Trusted Platform Module**
A TPM is a tamper-resistant cryptographic module designed to enhance the security and privacy of computing platforms. The TPM is incorporated as a component in a trusted computing platform like a personal computer, tablet, or phone. The computing platform is specially designed to work with the TPM to support privacy and security scenarios that cannot be achieved through software alone. A proper implementation of a TPM as part of a trusted computing platform provides a hardware root of trust, meaning that the hardware behaves in a trusted way. For example, a key created in a TPM with the property that it can never be exported from the TPM really means the key cannot leave the TPM. The close integration of a TPM with a platform increases the transparency of the boot process and supports device health scenarios by enabling reliable report of the software used to start a platform.
-
The functionality a TPM provides includes:
-
- **Cryptographic key management.** Create, store, and permit the use of keys in defined ways.
-
- **Safeguarding and reporting integrity measurements.** Software used to boot the platform can be recorded in the TPM and used to establish trust in the software running on the platform.
-
- **Prove a TPM is really a TPM.** The TPM’s capabilities are so central to protecting privacy and security that a TPM needs to be able to differentiate itself from malware that masquerades as a TPM.
Microsoft combined this small list of TPM benefits with Windows 10 and other hardware security technologies to provide practical security and privacy benefits.
Among other functions, Windows 10 uses the TPM to protect the encryption keys for BitLocker volumes, virtual smart cards, certificates, and the many other keys that the TPM is used to generate. Windows 10 also uses the TPM to securely record and protect integrity-related measurements of select hardware and Windows boot components for the [Measured Boot](#measure-boot) feature described later in this document. In this scenario, Measured Boot measures each component, from firmware up through the drivers, and then stores those measurements in the PC’s TPM. From there, you can test the measurement log remotely so that a separate system verifies the boot state of the Windows 10 PC.
-
Windows 10 supports TPM implementations that comply with either the 1.2 or 2.0 standards. Several improvements have been made in the TPM 2.0 standard, the most notable of which is cryptographic agility. TPM 1.2 is restricted to a fixed set of encryption and hash algorithms. At the time the TPM 1.2 standard was created in the early 2000s, these algorithms were considered cryptographically strong. Since that time, advances in cryptographic algorithms and cryptanalysis attacks have increased expectations for stronger cryptography. TPM 2.0 supports additional algorithms that offer stronger cryptographic protection as well as the ability to plug in algorithms that may be preferred in certain geographies or industries. It also opens the possibility for inclusion of future algorithms without changing the TPM component itself.
TPM is usually assumed to be implanted in hardware on a motherboard as a discrete module, but TPM can also be effective when implemented in firmware. Windows 10 supports both discrete and firmware TPM that complies with the 2.0 standard (1.2 can only be discrete). Windows does not differentiate between discrete and firmware-based solutions because they must meet the same requirements; therefore, any Windows feature that can take advantage of TPM can use either implementation.
**Note**
Microsoft will not initially require new Windows 10 PCs to include TPM support. Microsoft will require systems to include a TPM 2.0 beginning one year from the launch of Windows 10, however, to give manufacturers enough time to incorporate this critical functionality and to give IT pros enough time to determine which benefits they will leverage.
-
-
Several Windows 10 security features require TPM:
-
- Virtual smart cards
-
- Measured Boot
-
- Health attestation (requires TPM 2.0 or later)
-
- InstantGo (requires TPM 2.0 or later)
Other Windows 10 security features like BitLocker may take advantage of TPM if it is available but do not require it to work. An example of this is Microsoft Passport.
@@ -536,11 +437,8 @@ All of these features are covered in this document.
**Biometrics**
You read in the [Windows Hello](#windows-hello) section of this document that Windows 10 has built-in support for biometric hardware. Windows has included some amount of built-in biometric support since the Windows XP operating system, so what’s different about this in Windows 10?
-
Windows 10 makes biometrics a core security feature. Biometrics is fully integrated into the Windows 10 security components, not just tacked on as an extra part of a larger scheme. This is a big change. Earlier biometric implementations were largely front-end methods to simplify authentication. Under the hood, biometrics was used to access a password, which was then used for authentication behind the scenes. Biometrics may have provided convenience but not necessarily enterprise-grade authentication.
-
Microsoft has evangelized the importance of enterprise-grade biometric sensors to the OEMs that create Windows PCs and peripherals. Many OEMs already ship systems that have integrated fingerprint sensors and are transitioning from swipe-based to touch-based sensors. Facial-recognition sensors were already available when Windows 10 launched and are becoming more commonplace as integrated system components.
-
In the future, Microsoft expects OEMs to produce even more enterprise-grade biometric sensors and to continue to integrate them into systems as well as provide separate peripherals. As a result, biometrics will become a commonplace authentication method as part of an MFA system.
**Secure Windows startup**
@@ -550,17 +448,13 @@ UEFI Secure Boot uses hardware technologies to help protect users from bootkits.
**Trusted Boot**
When UEFI Secure Boot verifies that the bootloader is trusted and starts Windows, the Windows Trusted Boot feature protects the rest of the startup process by verifying that all Windows startup components are trustworthy (for example, signed by a trusted source) and have integrity. The bootloader verifies the digital signature of the Windows kernel before loading it. The Windows kernel, in turn, verifies every other component of the Windows startup process, including the boot drivers, startup files, and ELAM component.
-
If a file has been modified (for example, if malware has tampered with it or it has been corrupted), Trusted Boot will detect the problem and automatically repair the corrupted component. When repaired, Windows will start normally after only a brief delay.
**Early Launch Antimalware**
Malware that targeted previous versions of Windows often attempted to start before the antimalware solution. To do this, some types of malware would update or replace a non-Microsoft–related driver that starts during the Windows startup process. The malicious driver would then use its system access privileges to modify critical parts of the system and disguise its presence so it could not be detected when the antimalware solution later started.
-
Early Launch Antimalware (ELAM) is part of the Trusted Boot feature set and is designed to enable the antimalware solution to start before all non-Microsoft drivers and apps. ELAM checks the integrity of non-Microsoft drivers to determine whether the drivers are trustworthy. Because Windows needs to start as fast as possible, ELAM cannot be a complicated process of checking the driver files against known malware signatures; doing so would delay startup too much. Instead, ELAM has the simple task of examining every boot driver and determining whether it is on the list of trusted drivers. If malware modifies a boot-related driver, ELAM will detect the change, and Windows will prevent the driver from starting, thus blocking driver-based rootkits. ELAM also allows the registered antimalware provider to scan drivers that are loaded after the boot process is complete.
-
The design is simple but effective. ELAM is a component of a full-featured antimalware solution, and it helps prevent malicious drivers and apps from starting before the rest of the antimalware solution starts later during the boot process. Indeed, ELAM runs only for a few seconds each time a PC starts. Windows Defender in Windows 10 supports ELAM, as does Microsoft System Center 2012 Endpoint Protection and several non-Microsoft antimalware apps.
-
If you want to learn how to configure ELAM, you can use Group Policy settings to configure how ELAM responds to potentially malicious boot drivers. In the Group Policy Management Editor, go to Computer Configuration\\Administrative Templates\\System\\Early Launch Antimalware, and enable the **Boot-Start Driver Initialization Policy** setting. Now, you can select which driver classifications ELAM loads. When you select the **Good Only** setting, it provides the highest level of security, but test it thoroughly to ensure that it does not prevent users with healthy PCs from starting.
###
@@ -568,7 +462,6 @@ If you want to learn how to configure ELAM, you can use Group Policy settings to
**Measured Boot**
The biggest challenge with rootkits and bootkits in earlier versions of Windows is that they can frequently be undetectable to the client. Because they often start before Windows defenses and the antimalware solution and they have system-level privileges, rootkits and bootkits can completely disguise themselves while continuing to access system resources. Although UEFI Secure Boot and Trusted Boot can prevent most rootkits and bootkits, intruders could still potentially exploit a few attack vectors (for example, if UEFI with Secure Boot is disabled or if the signature used to sign a boot component, such as a non-Microsoft driver, has been compromised and is used to sign a malicious one).
-
Windows 10 implements the Measured Boot feature, which uses the TPM hardware component built into newer PCs to record a series of measurements for critical startup-related components, including firmware, Windows boot components, drivers, and even the ELAM driver. Because Measured Boot leverages the hardware-based security capabilities of TPM, which isolates and protects the measurement data from malware attacks, the log data is well protected against even sophisticated attacks.
Measured Boot focuses on acquiring the measurement data and protecting it from tampering. It must be coupled with a service that can analyze the data to determine device health and provide a more complete security service. The next section introduces just such a service.
@@ -584,32 +477,21 @@ Figure 3. Health Attestation in Windows 10
Figure 3 illustrates the following process for device compliance verification and conditional access implementation:
1. The PC uses the TPM to record measurements of the bootloader, boot drivers, and ELAM driver. The TPM prevents anyone from tampering with these measurements, so even if malware is successfully loaded, it will not be able to modify the measurements. These measurements are signed with an Attestation Identity Key (AIK) that is stored in the TPM. Because the TPM hardware has signed the measurements, malware cannot modify them without being detected.
-
2. Health Attestation is not enabled by default and requires an enrollment with a mobile device management (MDM) server in order to enable it. If it is enabled, the health attestation client will contact a remote server, called a health attestation server. Microsoft provides a cloud-based Windows Health Attestation service that can help evaluate the health of a device. The health attestation client sends the signed measurements, the device’s TPM boot log, and an AIK certificate (if present), which lets the health attestation server verify that the key used to sign the measurements was issued to a trusted TPM.
-
3. The health attestation server analyzes the measurements and boot log and creates a statement of device health. This statement is encrypted to help ensure the confidentiality of the data.
-
4. A management system, such as an MDM server, can request that an enrolled device present a statement of device health. Windows 10 supports both Microsoft and non-Microsoft MDM server requests for device health. To prevent theft of device health statements and reuse from other devices, an MDM server sends the enrolled device a “number used only once” (nonce) request along with this request for the device health statement.
-
5. The enrolled device digitally signs the nonce with its AIK (which is stored in the TPM) and sends the MDM server the encrypted statement of device health, the digitally signed nonce, and a signed boot counter, which asserts that the device has not been restarted since it obtained the statement of health.
-
6. The MDM server can send the same data to the health attestation server. The server decrypts the statement of health, asserts that the boot counter in the statement matches the boot counter that was sent to the MDM server, and compiles a list of health attributes.
-
7. The health attestation server sends this list of health attributes back to the MDM server. The MDM server now enforces access and compliance policies if configured to do so.
For a list of data points that the health attestation server verifies, along with a description of the data, see the [HealthAttestation CSP article on MSDN](http://go.microsoft.com/fwlink/p/?LinkId=626940).
-
The management system’s implementation determines which attributes within the statement of device health are evaluated when assessing a device’s health. Broadly speaking, the management server receives information about how the device booted, what kind of policy is enforced on the device, and how data on the device is secured. Depending on the implementation, the management server may add checks that go beyond what the statement of device health provides—for example, Windows patch level and other device attributes.
-
Based on these data points, the management server can determine whether the client is healthy and grant it access to either a limited quarantine network or to the full network. Individual network resources, such as servers, can also grant or deny access based on whether the remote attestation client were able to retrieve a valid health certification from the remote attestation server.
-
Because this solution can detect and prevent low-level malware that may be extremely difficult to detect any other way, Microsoft recommends that you consider the implementation of a management system, like Microsoft Intune, or any management solutions that take advantage of the Windows 10 cloud-based Health Attestation Server feature to detect and block devices that have been infected with advanced malware from network resources.
## Secure the Windows core
-
Applications built for Windows are designed to be secure and free of defects, but the reality is that as long as human beings are writing code, vulnerabilities will continue to crop up. When identified, malicious users and software may attempt to exploit vulnerabilities by manipulating data in memory in the hope that they can bootstrap a successful exploit.
-
To mitigate these risks, Windows 10 includes core improvements to make it more difficult for malware to perform buffer overflow, heap spraying, and other low-level attacks and even which code is allowed to run on the PC. In addition, these improvements dramatically reduce the likelihood that newly discovered vulnerabilities result in a successful exploit. It takes detailed knowledge of operating system architecture and malware exploit techniques to fully appreciate the impact of these improvements, but the sections that follow explain them at a high level.
###
@@ -621,33 +503,24 @@ Today’s security threat landscape is more aggressive than ever before. Modern
It is estimated that more than 300,000 new malware variants are discovered daily. Unfortunately, companies currently use an ancient method to discover this infectious software and prevent its use. In fact, current PCs trust everything that runs until antimalware signatures determine whether a threat exists; then, the antimalware software attempts to clean the PC, often after the malicious software’s effect has already occurred. This signature-based system focuses on reacting to an infection and then ensuring that that particular infection does not happen again. In this model, the system that drives malware detection relies on the discovery of malicious software; only then can a signature be provided to the client to remediate it, which implies that a computer has often already been infected. The time between detection of the malware and a client being issued a signature could mean the difference between losing data and staying safe.
In addition to antimalware solutions, “app control” or “whitelisting” technologies are available, including AppLocker. These perform single-instance or blanket allow or deny rules for running applications. In Windows 10, these types of solutions are most effective when deployed alongside the Windows 10 Device Guard feature.
-
Device Guard breaks the current model of detection first-block later and allows only trusted applications to run, period. This methodology is consistent with the successful prevention strategy for mobile phone security. With Device Guard, Microsoft has changed how the Windows operating system handles untrusted applications, which makes its defenses difficult for malware to penetrate. This new prevention versus detection model will provide Windows clients with the necessary security for modern threats and, when implemented, mitigates many of today’s threats from day one.
**Device Guard overview**
Device Guard is a feature set that consists of both hardware and software system integrity hardening features. These features revolutionize the Windows operating system’s security by taking advantage of new VBS options to protect the system core and the processes and drivers running in kernel mode—the trust-nothing model you see in mobile device operating systems. A key feature used with Device Guard is *configurable code integrity*, which allows your organization to choose exactly which software from trusted software publishers is allowed to run code on your client machines—exactly what has made mobile phone security on some platforms, such as Windows Mobile, so successful. Trusted applications are those signed directly (in other words, binaries) or indirectly by using a signed file that lists the hash values for application binaries that are considered trustworthy. In addition, Device Guard offers organizations a way to sign existing LOB applications so that they can trust their own code without the requirement that the application be rebuilt or packaged. Also, this same method of signing can provide organizations a way to trust non-Microsoft applications, including those that may not have been signed directly. Device Guard with configurable code integrity, Credential Guard, and AppLocker present the most complete security defense that any Microsoft product has ever been able to offer a Windows client.
-Advanced hardware features such as CPU virtualization extensions, IOMMUs, and SLAT drive these new client security offerings. By integrating these hardware features further into the core operating system, Windows 10 can leverage them in new ways. For example, the same type 1 hypervisor technology that is used to run virtual machines in Hyper V isolates core Windows services into a virtualization-based, protected container. This is just one example of how Windows 10 integrates advanced hardware features deeper into the operating system to offer comprehensive modern security to its users.
+Advanced hardware features such as CPU virtualization extensions, IOMMUs, and SLAT drive these new client security offerings. By integrating these hardware features further into the core operating system, Windows 10 can leverage them in new ways. For example, the same type 1 hypervisor technology that is used to run virtual machines in Hyper V isolates core Windows services into a virtualization-based, protected container. This is just one example of how
+Windows 10 integrates advanced hardware features deeper into the operating system to offer comprehensive modern security to its users.
To deliver this additional security, Device Guard has the following hardware and software requirements:
-
- UEFI Secure Boot (optionally with a non-Microsoft UEFI CA removed from the UEFI database)
-
- Virtualization support enabled by default in the system firmware (BIOS):
-
- Virtualization extensions (for example, Intel VT-x, AMD RVI)
-
- SLAT (for example, Intel EPT, AMD RVI)
-
- IOMMU (for example, Intel VT-d, AMD-Vi)
-
- UEFI BIOS configured to prevent an unauthorized user from disabling Device Guard–dependent hardware security features (for example, Secure Boot)
-
- Kernel mode drivers signed and compatible with hypervisor-enforced code integrity
-
- Windows 10 Enterprise only
-
- X64 version of Windows
Along with these new features, some components of Device Guard are existing tools or technologies that have been included in this strategic security offering to provide customers with the most secure Windows operating system possible. Device Guard is intended as a set of client security features to be used in conjunction with the other threat-resistance features available in the Windows operating system, some of which are mentioned in this guide.
@@ -665,7 +538,6 @@ Historically, most malware has been unsigned. Simply by deploying code integrity
The core functionality and protection of Device Guard starts at the hardware level. Devices that have processors equipped with SLAT technologies and virtualization extensions, such as Intel VT x and AMD V, will be able to take advantage of a VBS environment that dramatically enhances Windows security by isolating critical Windows services from the operating system itself. This isolation is necessary, because you must assume that the operating system kernel will be compromised, and you need assurance that some processes will remain secure.
Device Guard leverages VBS to isolate its Hypervisor Code Integrity (HVCI) service, which enables Device Guard to protect all kernel mode processes and drivers from vulnerability exploits and zero days. HVCI uses the processor’s IOMMU functionality to force all software running in kernel mode to safely allocate memory. This means that after memory has been allocated, its state must be changed from writable to read only or execute only. By forcing memory into these states, it helps ensure that attacks are unable to inject malicious code into kernel mode processes and drivers through techniques such as buffer overruns or heap spraying. In the end, the VBS environment protects the Device Guard HVCI service from tampering even if the operating system’s kernel has been fully compromised, and HVCI protects kernel mode processes and drivers so that a compromise of this magnitude can’t happen in the first place.
-
Another Windows 10 feature that employs VBS is Credential Guard. Credential Guard protects credentials by running the Windows authentication service known as LSA, and then storing the user’s derived credentials (for example, NTLM hashes; Kerberos tickets) within the same VBS environment that Device Guard uses to protect its HVCI service. By isolating the LSA service and the user’s derived credentials from both user mode and kernel mode, an attacker that has compromised the operating system core will still be unable to tamper with authentication or access derived credential data. Credential Guard prevents pass-the-hash and ticket types of attacks, which are central to the success of nearly every major network breach you’ve read about, which makes Credential Guard one of the most impactful and important features to deploy within your environment. For more information about how Credential Guard complements Device Guard, see the [Device Guard with Credential Guard](#dgwithcg) section.
**Device Guard with AppLocker**
@@ -676,9 +548,7 @@ Although AppLocker is not considered a new Device Guard feature, you can use it
One example in which Device Guard functionality needs AppLocker supplementation is when your organization would like to limit which universal applications from the Windows Store users can install on a device. Microsoft has already validated universal applications from the Windows Store as trustworthy to run, but an organization may not want to allow specific universal applications to run in its environment. You could use an AppLocker rule to enforce such a stance.
In another example, you could enable a configurable code integrity policy to allow users to run all the apps from a specific publisher. To do so, you would add the publisher’s signature to the policy. If your organization decides that only specific apps from that publisher should be allowed to run, you would add the signature for the publisher to the configurable code integrity policy, and then use AppLocker to determine which specific apps can run.
-
-
AppLocker and Device Guard can run side-by-side in your organization, which offers the best of both security features at the same time and provides the most comprehensive security to as many devices as possible. In addition to these features, Microsoft recommends that you continue to maintain an enterprise antivirus solution for a well-rounded enterprise security portfolio.
###
@@ -692,21 +562,15 @@ Because Credential Guard uses VBS, it is decisive in its ability to prevent pass
**Unified manageability through Device Guard**
You can easily manage Device Guard features through the familiar enterprise and client-management tools that IT pros use every day. Use the following management tools to enable and manage Device Guard:
-
- **Group Policy.**Windows 10 provides an administrative template that you can use to configure and deploy the configurable code integrity policies for your organization. This template also allows you to specify which hardware-based security features you would like to enable and deploy. You can manage these settings with your existing Group Policy objects, which makes it simple to implement Device Guard features. In addition to the code integrity and hardware-based security features, Group Policy can help you manage your catalog files.
-
- **System Center Configuration Manager.** Use System Center Configuration Manager to simplify deployment and management of catalog files, code integrity policies, and hardware-based security features as well as to provide version control.
-
- **MDM systems.** Organizations will be able to use Microsoft Intune and non-Microsoft MDM systems for deployment and management of code integrity policies and catalog files.
-
- **Windows PowerShell.** You use Windows PowerShell primarily to create and service code integrity policies. These policies represent the most impactful component of Device Guard.
-
These options provide the same experience you’re used to for management of your existing enterprise management solutions.
**Address Space Layout Randomization**
One of the most common techniques used to gain access to a system is to find a vulnerability in a privileged process that is already running, guess or find a location in memory where important system code and data have been placed, and then overwrite that information with a malicious payload. In the early days of operating systems, any malware that could write directly to the system memory could do such a thing; the malware would simply overwrite system memory in well-known and predictable locations.
-
Address Space Layout Randomization (ASLR) makes that type of attack much more difficult because it randomizes how and where important data is stored in memory. With ASLR, it is more difficult for malware to find the specific location it needs to attack. Figure 4 illustrates how ASLR works by showing how the locations of different critical Windows components can change in memory between restarts.
@@ -714,7 +578,6 @@ Address Space Layout Randomization (ASLR) makes that type of attack much more di
Figure 4. ASLR at work
Although the ASLR implementation in Windows 7 was effective, it wasn’t applied holistically across the operating system, and the level of entropy (cryptographic randomization) wasn’t always at the highest possible level. To decrease the likelihood that sophisticated attacks such as heap spraying could succeed in the Windows 8 operating system, Microsoft applied ASLR holistically across the system and increased the level of entropy many times.
-
The ASLR implementation in Windows 8 and Windows 10 is greatly improved over Windows 7, especially with 64-bit system and application processes that can take advantage of a vastly increased memory space, which makes it even more difficult for malware to predict where Windows 10 stores vital data. When used on systems that have TPMs, ASLR memory randomization will be increasingly unique across devices, which makes it even more difficult for a successful exploit that works on one system to work reliably on another.
**Data Execution Prevention**
@@ -726,15 +589,10 @@ Data Execution Prevention (DEP) does exactly that, by substantially reducing the
Because of the importance of DEP, users cannot install Windows 10 on a computer that does not have DEP capability. Fortunately, most processors released since the mid-2000s support DEP.
If you want to see which apps use DEP, complete these steps:
-
1. Open Task Manager: Press Ctrl+Alt+Esc or by searching the Start screen.
-
2. Click **More Details** (if necessary), and then click the **Details** tab.
-
3. Right-click any column heading, and then click **Select Columns**.
-
4. In the **Select Columns** dialog box, select the last **Data Execution Prevention** check box.
-
5. Click **OK**.
You can now see which processes have DEP enabled. Figure 5 shows the processes running on a Windows 10 PC with a single process that does not support DEP.
@@ -748,11 +606,8 @@ Figure 5. Processes on which DEP has been enabled in Windows 10
The *heap* is a location in memory that Windows uses to store dynamic application data. Windows 10 continues to improve on earlier Windows heap designs by further mitigating the risk of heap exploits that could be used as part of an attack.
Windows 10 has several important improvements to the security of the heap over Windows 7:
-
- Internal data structures that the heap uses are now better protected against memory corruption.
-
- Heap memory allocations now have randomized locations and sizes, which makes it more difficult for an attacker to predict the location of critical memory to overwrite. Specifically, Windows 10 adds a random offset to the address of a newly allocated heap, which makes the allocation much less predictable.
-
- Windows 10 uses “guard pages” before and after blocks of memory as tripwires. If an attacker attempts to write past a block of memory (a common technique known as a buffer overflow), the attacker will have to overwrite a guard page. Any attempt to modify a guard page is considered a memory corruption, and Windows 10 responds by instantly terminating the app.
Windows 10 resolves known heap attacks that could be used to compromise a PC running previous versions of Windows.
@@ -764,9 +619,7 @@ The lowest 64 KB of process memory is reserved for the system. Apps are no longe
**Control Flow Guard**
When applications are loaded into memory, they are allocated space based on the size of the code, requested memory, and other factors. When an application begins to execute code, it calls additional code located in other memory addresses. The relationships between the code locations are well known—they are written in the code itself—but previous to Windows 10, the flow between these locations was not enforced, which gives attackers the opportunity to change the flow to meet their needs. In other words, an application exploit takes advantage of this behavior by running code that the application may not typically run.
-
This kind of threat is mitigated in Windows 10 through the Control Flow Guard (CFG) feature. When a trusted application that was compiled to use CFG calls code, CFG verifies that the code location called is trusted for execution. If the location is not trusted, the application is immediately terminated as a potential security risk.
-
An administrator cannot configure CFG; rather, an application developer can take advantage of CFG by configuring it when the application is compiled. Administrators should consider asking application developers and software vendors to deliver trustworthy Windows applications compiled with CFG enabled. Of course, browsers are a key entry point for attacks; thus Microsoft Edge, IE, and other Windows features take full advantage of CFG.
**Protected Processes**
@@ -781,25 +634,20 @@ With Protected Processes, Windows 10 prevents untrusted processes from interact
## Secure the Windows desktop
-
Windows 10 includes critical improvements to the Windows core and the desktop environment, where attacks and malware most frequently enter. The desktop environment is now more resistant to malware thanks to significant improvements to Windows Defender and SmartScreen Filters. Internet browsing is a safer experience because of Microsoft Edge, a completely new browser. The Windows Store reduces the likelihood that malware will infect devices by ensuring that all applications that enter the Windows Store ecosystem have been thoroughly reviewed before being made available. Universal Windows applications are inherently more secure than typical applications because they are sandboxed. Sandboxing restricts the application’s risk of being compromised or tampered with in a way that would put the system, data, and other applications at risk.
-
The sections that follow describe Windows 10 improvements to application security in more detail.
**Microsoft Edge and Internet Explorer 11**
Browser security is a critical component of any security strategy, and for good reason: The browser is the user’s interface to the Internet, an environment that is quite literally overwhelmed with malicious sites and content waiting to attack. Most users cannot perform at least part of their job without a browser, and many users are completely reliant on one. This reality has made the browser the number one pathway from which malicious hackers initiate their attacks.
-All browsers enable some amount of extensibility to do things beyond the original scope of the browser. Two common examples of this are Flash and Java extensions that enable their respective applications to run inside a browser. Keeping Windows 10 secure for web browsing and applications, especially for these two content types, is a priority.
+All browsers enable some amount of extensibility to do things beyond the original scope of the browser. Two common examples of this are Flash and Java extensions that enable their respective applications to run inside a browser.
+Keeping Windows 10 secure for web browsing and applications, especially for these two content types, is a priority.
Microsoft includes an entirely new browser, Microsoft Edge, in Windows 10. Microsoft Edge is more secure in several ways, especially:
-
- **Microsoft Edge does not support non-Microsoft binary extensions.** Microsoft Edge supports Flash content and PDF viewing by default through built-in extensions but no other binary extensions, including ActiveX controls and Java.
-
- **Microsoft Edge runs 64-bit processes.** A 64-bit PC running an older version of Windows often runs in 32-bit compatibility mode to support older and less secure extensions. When Microsoft Edge runs on a 64-bit PC, it runs only 64-bit processes, which are much more secure when vulnerabilities are discovered and attempts are made to exploit them.
-
- **Microsoft Edge is designed as a Universal Windows app.** It is inherently compartmentalized and runs in an AppContainer that sandboxes the browser from the system, data, and other apps. IE11 on Windows 10 can also take advantage of the same AppContainer technology through Enhanced Protect Mode. However, because it can run ActiveX and BHOs, the browser and sandbox are susceptible to a much broader range of attacks than Microsoft Edge.
-
- **Microsoft Edge simplifies security configuration tasks.** Because Microsoft Edge uses a simplified application structure and a single sandbox configuration, there are fewer required security settings. In addition, Microsoft created Microsoft Edge default settings that align with security best practices, which makes it secure by default.
In addition to Microsoft Edge, Microsoft includes IE11 in Windows 10 primarily for backwards-compatibility with websites and binary extensions that do not work with Microsoft Edge. It should not be configured as the primary browser but rather as an optional or automatic switchover, as shown in Figure 6.
@@ -813,9 +661,7 @@ Microsoft’s recommendation is to use Microsoft Edge as the primary web browser
**The SmartScreen Filter**
Recent versions of Windows have many effective techniques to prevent malware from installing itself without the user’s knowledge. To work around those restrictions, malware attacks often use social engineering techniques to trick users into running software. For example, malware known as a Trojan horse pretends to be something useful, such as a utility, but carries an additional, malicious payload.
-
Starting with Windows Internet Explorer 8, the SmartScreen Filter has helped protect users from both malicious applications and nefarious websites by using the SmartScreen Filter’s application and URL reputation services. The SmartScreen Filter in Internet Explorer would check URLs and newly downloaded apps against an online reputation service that Microsoft maintained. If the app or URL were not known to be safe, SmartScreen Filter would warn the user or even prevent the app or URL from loading, depending on how systems administrators had configured Group Policy settings.
-
For Windows 10, Microsoft further developed the SmartScreen Filter by integrating its app reputation abilities into the operating system itself, which allows the filter to protect users regardless of the web browser they are using or the path that the app uses to arrive on the device (for example, email, USB flash drive). The first time a user runs an app that originates from the Internet, even if the user copied it from another PC, the SmartScreen Filter checks the reputation of the application by using digital signatures and other factors against a service that Microsoft maintains. If the app lacks a reputation or is known to be malicious, the SmartScreen Filter warns the user or blocks execution entirely, depending on how the administrator has configured Group Policy (see Figure 7).
@@ -841,9 +687,7 @@ Now, repeat the test on a computer running Windows 10 by copying the file to a
The good news is that the download and use of Universal Windows apps or even Windows Classic applications (Win32) from the Windows Store will dramatically reduce the likelihood that you encounter malware on your PC because all apps go through a careful screening process before being made available in the store. Apps that organizations build and distribute through sideloading processes will need to be reviewed internally to ensure that they meet organizational security requirements.
Regardless of how users acquire Universal Windows apps, they can use them with increased confidence. Unlike Windows Classic applications, which can run with elevated privileges and have potentially sweeping access to the system and data, Universal Windows apps run in an AppContainer sandbox with limited privileges and capabilities. For example, Universal Windows apps have no system-level access, have tightly controlled interactions with other apps, and have no access to data unless the user explicitly grants the application permission.
-
In addition, all Universal Windows apps follow the security principle of least privilege. Apps receive only the minimum privileges they need to perform their legitimate tasks, so even if an attacker exploits an app, the damage the exploit can do is severely limited and should be contained within the sandbox. The Windows Store displays the exact capabilities the app requires (for example, access to the camera), along with the app’s age rating and publisher.
-
In the end, the Windows Store app distribution process and the app sandboxing capabilities of Windows 10 will dramatically reduce the likelihood that users encounter malicious apps on the system.
**Windows Defender**
@@ -851,7 +695,6 @@ In the end, the Windows Store app distribution process and the app sandboxing ca
Antimalware software, also generically called virus scanners, antivirus, and a host of other names, has been around for a long time. Microsoft shipped its first program in this category, Microsoft Anti-Virus, in 1993 for MS DOS 6.0. At the time, the approach of running a standalone MS DOS program to locate and remove viruses was sufficient.
Times change and technology progresses, and antimalware software has also evolved. It is crucial to have multilayered defense with interoperability when you manage modern threats. Windows Defender uses the operating system extensively to achieve interoperability across the varying layers of defense. It is important to have an effective antimalware solution in place as an important obstacle between malware and enterprise assets, and it complements features like Device Guard. For example, an antimalware solution could help detect malicious behavior in memory or even within trusted applications, an area that Device Guard is not designed to address.
-
Windows Defender has evolved to meet the growing complexity of IT and the challenges that come with this complexity. Windows included Windows Defender, a robust inbox antimalware solution, starting with Windows 8. Now, with Windows 10, Microsoft has significantly improved Windows Defender.
Windows Defender in Windows 10 uses a four-pronged approach to improve antimalware: rich local context, extensive global sensors, tamper proofing, and the empowerment of IT security professionals. This section explains each prong.
@@ -884,16 +727,12 @@ Figure 11. Windows Defender settings in Group Policy– the sample submission op
Windows Defender is designed to resist tampering; it uses several security technologies available in Windows 10, the primary of which is Protected Processes, which prevents untrusted processes from attempting to tamper with Windows Defender components, its registry keys, and so on. Tamper proofing in Windows Defender is also the indirect result of system-wide security components, including UEFI with Secure Boot and ELAM. These components help provide a more secure environment in which Windows Defender can launch in before it begins to defend itself.
-**Empowerment of IT security professionals** means that Windows Defender gives IT pros the tools and configuration options necessary to make it an enterprise-class antimalware solution. It has numerous enterprise-level features that put it on par with the top products in this category:
-
+**Empowerment of IT security professionals** means that Windows Defender gives IT pros the tools and configuration options necessary to make it an enterprise-class antimalware solution. It has numerous enterprise-level features
+that put it on par with the top products in this category:
- Integration with centralized management software, including Microsoft Intune, System Center Configuration Manager, and Microsoft System Center Operations Manager. Unlike Windows 8.1, no additional client is necessary, because Windows Defender is now integrated into Windows and only a management layer needs to be added.
-
- Windows Defender supports the Open Mobile Alliance Device Management standard for centralized management by many non-Microsoft device management solutions.
-
- It includes integrated classic command-line and Windows PowerShell cmdlet support.
-
- Support for Windows Management Instrumentation reporting and application management is built in.
-
- Full integration with Group Policy offers complete IT configuration management.
In addition, Windows Defender now integrates the Windows Defender Offline Tool, which formerly required the creation of a bootable, standalone version of Windows Defender into the Windows Recovery Environment. This simplifies the process of remediating low-level malware infections, which may prove difficult to detect and remove with the antimalware solution running on the Windows desktop. You can update signatures for this environment automatically from within the Windows Defender Offline experience.
@@ -903,19 +742,16 @@ Beyond Windows Defender, Windows 10 provides deep operating system access for a
This access presents a security challenge, however: How does Windows 10 grant antimalware software generous access while ensuring that malware doesn’t take advantage of the very same access? Microsoft has been hard at work with several non-Microsoft software vendors to meet this challenge. If a third party wants this level of access, it must meet certain criteria and vetting requirements, and then Microsoft must digitally sign its software. This allows Microsoft to verify the authenticity of the software vendors and prevent nefarious individuals from creating their own self-signed fake malware scanners.
To be clear, Microsoft is not restricting the antimalware vendors or their innovations. Nor is Microsoft changing software distribution channels. When Microsoft has signed the antimalware application, you can deploy and install it through any means. Microsoft is basically ensuring that these software developers are authentic, industry-recognized entities before signing their antimalware software and, in doing so, granting extended privileges to it.
-
Another security threat that customers face particularly in consumer and bring your own device (BYOD) scenarios is a disabled or outdated antimalware product. A BYOD computer that has an installed but ineffective antimalware product can be more dangerous than no product at all, because it gives the illusion of security. Windows Defender in Windows 10 mitigates this threat by helping ensure that either Windows Defender or the customer’s preferred non-Microsoft solution is running and in a healthy state.
Whenever non-Microsoft real-time protection is in an inoperable state (for example, disabled, expired) for 24 hours, Windows Defender automatically turns on to ensure that the device is protected. Windows attempts to help the user remediate the issue with the non-Microsoft antimalware solution by notifying him or her as early as 5 days before the software expires. If the solution expires, Windows enables Windows Defender and continues to remind the user to renew the non-Microsoft solution. When the user updates or reactivates the solution, Windows Defender is automatically disabled. In the end, the goal is to make sure that an operable antimalware solution is running at all times.
## Conclusion
-
Windows 10 is the culmination of many years of effort from Microsoft, and its impact from a security perspective will be significant. Many of us still remember the years of Windows XP, when the attacks on the Windows operating system, applications, and data increased in volume and matured into serious threats. With the existing platforms and security solutions that you’ve likely deployed, you’re better defended than ever. But as attackers have become more advanced, there is no doubt that they have exceeded your ability to defend your organization and users. Evidence of this fact can be found in the news virtually every day as yet another major organization falls victim. Microsoft specifically designed Windows 10 to address these modern threats and tactics from the most advanced adversaries. It can truly change the game for your organization, and it can restore your advantage against those would like to make you their next victim.
## Related topics
-
[Windows 10 Specifications](http://go.microsoft.com/fwlink/p/?LinkId=625077 )
[HealthAttestation CSP](http://go.microsoft.com/fwlink/p/?LinkId=626940 )
@@ -923,12 +759,3 @@ Windows 10 is the culmination of many years of effort from Microsoft, and its i
[Making Windows 10 More Personal and More Secure with Windows Hello](http://go.microsoft.com/fwlink/p/?LinkId=626945)
[Protect BitLocker from pre-boot attacks](protect-bitlocker-from-pre-boot-attacks.md)
-
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/windows-defender-advanced-threat-protection.md b/windows/keep-secure/windows-defender-advanced-threat-protection.md
index 5637c81086..9567620fcb 100644
--- a/windows/keep-secure/windows-defender-advanced-threat-protection.md
+++ b/windows/keep-secure/windows-defender-advanced-threat-protection.md
@@ -76,7 +76,7 @@ detect sophisticated cyber-attacks, providing:
Topic | Description
:---|:---
-[Minimum requirements](minimum-requirements-windows-defender-advanced-threat-protection.md) | This overview topic for IT professionals provides information on the minimum requirements to use Windows Defender ATP such as network and data storage configuration, and endpoint hardware ans software requirements, and deployment channels.
+[Minimum requirements](minimum-requirements-windows-defender-advanced-threat-protection.md) | This overview topic for IT professionals provides information on the minimum requirements to use Windows Defender ATP such as network and data storage configuration, and endpoint hardware and software requirements, and deployment channels.
[Onboard endpoints and set up access](onboard-configure-windows-defender-advanced-threat-protection.md) | You'll need to onboard and configure the Windows Defender ATP service and the endpoints in your network before you can use the service. Learn about how you can assign users to the Windows Defender ATP service in Azure Active Directory (AAD) and using a configuration package to configure endpoints.
[Data storage and privacy](data-storage-privacy-windows-defender-advanced-threat-protection.md)| Learn about how Windows Defender ATP collects and handles information and where data is stored.
[Portal overview](portal-overview-windows-defender-advanced-threat-protection.md) | Understand the main features of the service and how it leverages Microsoft technology to protect enterprise endpoints from sophisticated cyber attacks.
diff --git a/windows/keep-secure/windows-defender-in-windows-10.md b/windows/keep-secure/windows-defender-in-windows-10.md
index 585300bcd8..72d8554def 100644
--- a/windows/keep-secure/windows-defender-in-windows-10.md
+++ b/windows/keep-secure/windows-defender-in-windows-10.md
@@ -5,59 +5,49 @@ ms.assetid: 6A9EB85E-1F3A-40AC-9A47-F44C4A2B55E2
ms.prod: W10
ms.mktglfcycl: manage
ms.sitesec: library
+ms.pagetype: security
author: jasesso
---
# Windows Defender in Windows 10
-
**Applies to**
-
- Windows 10
Windows Defender in Windows 10 is a built-in antimalware solution that provides security and antimalware management for desktops, portable computers, and servers.
-
This topic provides an overview of Windows Defender, including a list of system requirements and new features.
For more important information about running Windows Defender on a server platform, see [Windows Defender Overview for Windows Server Technical Preview](https://technet.microsoft.com/library/dn765478.aspx).
Take advantage of Windows Defender by configuring the settings and definitions using the following tools:
-
- Microsoft Active Directory *Group Policy* for settings
- Windows Server Update Services (WSUS) for definitions
Windows Defender provides the most protection when cloud-based protection is enabled. Learn how to enable cloud-based protection in [Configure Windows Defender in Windows 10](configure-windows-defender-in-windows-10.md).
-
-**Note** System Center 2012 R2 Configuration Manager SP1, System Center 2012 Configuration Manager SP2, and Microsoft Intune can provide centralized management of Windows Defender, including:
+> **Note:** System Center 2012 R2 Configuration Manager SP1, System Center 2012 Configuration Manager SP2, and Microsoft Intune can provide centralized management of Windows Defender, including:
- Settings management
- Definition update management
- Alerts and alert management
- Reports and report management
When you enable endpoint protection for your clients, it will install an additional management layer on Windows Defender to manage the in-box Windows Defender agent. While the client user interface will still appear as Windows Defender, the management layer for Endpoint Protection will be listed in the **Add/Remove Programs** control panel, though it will appear as if the full product is installed.
-
-
### Minimum system requirements
Windows Defender has the same hardware requirements as Windows 10. For more information, see:
-
- [Minimum hardware requirements](https://msdn.microsoft.com/library/windows/hardware/dn915086.aspx)
- [Hardware component guidelines](https://msdn.microsoft.com/library/windows/hardware/dn915049.aspx)
### New and changed functionality
- **Improved detection for unwanted applications and emerging threats using cloud-based protection.** Use the Microsoft Active Protection Service to improve protection against unwanted applications and advanced persistent threats in your enterprise.
-
- **Windows 10 integration.** All Windows Defender in Windows 10 endpoints will show the Windows Defender user interface, even when the endpoint is managed.
-
- **Operating system, enterprise-level management, and bring your own device (BYOD) integration.** Windows 10 introduces a mobile device management (MDM) interface for devices running Windows 10. Administrators can use MDM-capable products, such as Intune, to manage Windows Defender on Windows 10 devices.
For more information about what's new in Windows Defender in Windows 10, see [Windows Defender in Windows 10: System integration](https://www.microsoft.com/security/portal/enterprise/threatreports_august_2015.aspx) on the Microsoft Active Protection Service website.
## In this section
-
@@ -89,14 +79,6 @@ For more information about what's new in Windows Defender in Windows 10, see [W
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/windows-installer-rules-in-applocker.md b/windows/keep-secure/windows-installer-rules-in-applocker.md
index 5bab8afeaf..05f9214263 100644
--- a/windows/keep-secure/windows-installer-rules-in-applocker.md
+++ b/windows/keep-secure/windows-installer-rules-in-applocker.md
@@ -2,31 +2,21 @@
title: Windows Installer rules in AppLocker (Windows 10)
description: This topic describes the file formats and available default rules for the Windows Installer rule collection.
ms.assetid: 3fecde5b-88b3-4040-81fa-a2d36d052ec9
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Windows Installer rules in AppLocker
-
-
**Applies to**
-
- Windows 10
-
This topic describes the file formats and available default rules for the Windows Installer rule collection.
-
AppLocker defines Windows Installer rules to include only the following file formats:
-
- .msi
-
- .msp
-
- .mst
-
The purpose of this collection is to allow you to control the installation of files on client computers and servers through Group Policy or the Local Security Policy snap-in. The following table lists the default rules that are available for the Windows Installer rule collection.
-
@@ -63,19 +53,8 @@ The purpose of this collection is to allow you to control the installation of fi
-
-
## Related topics
-
-
[Understanding AppLocker default rules](understanding-applocker-default-rules.md)
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/working-with-applocker-policies.md b/windows/keep-secure/working-with-applocker-policies.md
index 815ea0211f..af1edcf35e 100644
--- a/windows/keep-secure/working-with-applocker-policies.md
+++ b/windows/keep-secure/working-with-applocker-policies.md
@@ -2,24 +2,17 @@
title: Working with AppLocker policies (Windows 10)
description: This topic for IT professionals provides links to procedural topics about creating, maintaining, and testing AppLocker policies.
ms.assetid: 7062d2e0-9cbb-4cb8-aa8c-b24945c3771d
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Working with AppLocker policies
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals provides links to procedural topics about creating, maintaining, and testing AppLocker policies.
-
## In this section
-
-
@@ -86,14 +79,6 @@ This topic for IT professionals provides links to procedural topics about creati
-
-
-
-
-
-
-
-
diff --git a/windows/keep-secure/working-with-applocker-rules.md b/windows/keep-secure/working-with-applocker-rules.md
index 5fad689a53..9ee115544d 100644
--- a/windows/keep-secure/working-with-applocker-rules.md
+++ b/windows/keep-secure/working-with-applocker-rules.md
@@ -2,24 +2,17 @@
title: Working with AppLocker rules (Windows 10)
description: This topic for IT professionals describes AppLocker rule types and how to work with them for your application control policies.
ms.assetid: 3966b35b-f2da-4371-8b5f-aec031db6bc9
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: brianlic-msft
---
-
# Working with AppLocker rules
-
-
**Applies to**
-
- Windows 10
-
This topic for IT professionals describes AppLocker rule types and how to work with them for your application control policies.
-
## In this section
-
-
@@ -78,11 +71,8 @@ This topic for IT professionals describes AppLocker rule types and how to work w
-
-
The three AppLocker enforcement modes are described in the following table. The enforcement mode setting defined here can be overwritten by the setting derived from a linked Group Policy Object (GPO) with a higher precedence.
-
@@ -109,16 +99,10 @@ The three AppLocker enforcement modes are described in the following table. The
-
-
When AppLocker policies from various GPOs are merged, the rules from all the GPOs are merged and the enforcement mode setting of the winning GPO is applied.
-
## Rule collections
-
-
The AppLocker console is organized into rule collections, which are executable files, scripts, Windows Installer files, packaged apps and packaged app installers, and DLL files. These collections give you an easy way to differentiate the rules for different types of apps. The following table lists the file formats that are included in each rule collection.
-
@@ -161,60 +145,34 @@ The AppLocker console is organized into rule collections, which are executable f
-
-
**Important**
If you use DLL rules, you need to create an allow rule for each DLL that is used by all of the allowed apps.
-
When DLL rules are used, AppLocker must check each DLL that an application loads. Therefore, users may experience a reduction in performance if DLL rules are used.
-
The DLL rule collection is not enabled by default. To learn how to enable the DLL rule collection, see [DLL rule collections](#bkmk-dllrulecollections).
-
-
## Rule conditions
-
-
Rule conditions are criteria that help AppLocker identify the apps to which the rule applies. The three primary rule conditions are publisher, path, and file hash.
-
- [Publisher](#bkmk-publisher): Identifies an app based on its digital signature
-
- [Path](#bkmk-path): Identifies an app by its location in the file system of the computer or on the network
-
- [File hash](#bkmk-filehash): Represents the system computed cryptographic hash of the identified file
-
### Publisher
-
This condition identifies an app based on its digital signature and extended attributes when available. The digital signature contains info about the company that created the app (the publisher). Executable files, dlls, Windows installers, packaged apps and packaged app installers also have extended attributes, which are obtained from the binary resource. In case of executable files, dlls and Windows installers, these attributes contain the name of the product that the file is a part of, the original name of the file as supplied by the publisher, and the version number of the file. In case of packaged apps and packaged app installers, these extended attributes contain the name and the version of the app package.
-
**Note**
Rules created in the packaged apps and packaged app installers rule collection can only have publisher conditions since Windows does not support unsigned packaged apps and packaged app installers.
-
-
**Note**
Use a publisher rule condition when possible because they can survive app updates as well as a change in the location of files.
-
-
When you select a reference file for a publisher condition, the wizard creates a rule that specifies the publisher, product, file name, and version number. You can make the rule more generic by moving the slider up or by using a wildcard character (\*) in the product, file name, or version number fields.
-
**Note**
To enter custom values for any of the fields of a publisher rule condition in the Create Rules Wizard, you must select the **Use custom values** check box. When this check box is selected, you cannot use the slider.
-
-
The **File version** and **Package version** control whether a user can run a specific version, earlier versions, or later versions of the app. You can choose a version number and then configure the following options:
-
- **Exactly.** The rule applies only to this version of the app
-
- **And above.** The rule applies to this version and all later versions.
-
- **And below.** The rule applies to this version and all earlier versions.
-
The following table describes how a publisher condition is applied.
-
@@ -264,17 +222,11 @@ The following table describes how a publisher condition is applied.
-
-
### Path
-
This rule condition identifies an application by its location in the file system of the computer or on the network.
-
AppLocker uses custom path variables for well-known paths, such as Program Files and Windows.
-
The following table details these path variables.
-
@@ -322,148 +274,72 @@ The following table details these path variables.
-
-
**Important**
Because a path rule condition can be configured to include a large number of folders and files, path conditions should be carefully planned. For example, if an allow rule with a path condition includes a folder location that non-administrators are allowed to write data into, a user can copy unapproved files into that location and run the files. For this reason, it is a best practice to not create path conditions for standard user writable locations, such as a user profile.
-
-
### File hash
-
When you choose the file hash rule condition, the system computes a cryptographic hash of the identified file. The advantage of this rule condition is that because each file has a unique hash, a file hash rule condition applies to only one file. The disadvantage is that each time the file is updated (such as a security update or upgrade) the file's hash will change. As a result, you must manually update file hash rules.
-
## AppLocker default rules
-
-
AppLocker allows you to generate default rules for each rule collection.
-
Executable default rule types include:
-
- Allow members of the local **Administrators** group to run all apps.
-
- Allow members of the **Everyone** group to run apps that are located in the Windows folder.
-
- Allow members of the **Everyone** group to run apps that are located in the Program Files folder.
-
Script default rule types include:
-
- Allow members of the local **Administrators** group to run all scripts.
-
- Allow members of the **Everyone** group to run scripts that are located in the Program Files folder.
-
- Allow members of the **Everyone** group to run scripts that are located in the Windows folder.
-
Windows Installer default rule types include:
-
- Allow members of the local **Administrators** group to run all Windows Installer files.
-
- Allow members of the **Everyone** group to run all digitally signed Windows Installer files.
-
- Allow members of the **Everyone** group to run all Windows Installer files that are located in the Windows\\Installer folder.
-
DLL default rule types:
-
- Allow members of the local **Administrators** group to run all DLLs.
-
- Allow members of the **Everyone** group to run DLLs that are located in the Program Files folder.
-
- Allow members of the **Everyone** group to run DLLs that are located in the Windows folder.
-
Packaged apps default rule types:
-
- Allow members of the **Everyone** group to install and run all signed packaged apps and packaged app installers.
-
## AppLocker rule behavior
-
-
If no AppLocker rules for a specific rule collection exist, all files with that file format are allowed to run. However, when an AppLocker rule for a specific rule collection is created, only the files explicitly allowed in a rule are permitted to run. For example, if you create an executable rule that allows .exe files in *%SystemDrive%\\FilePath* to run, only executable files located in that path are allowed to run.
-
A rule can be configured to use allow or deny actions:
-
- **Allow.** You can specify which files are allowed to run in your environment, and for which users or groups of users. You can also configure exceptions to identify files that are excluded from the rule.
-
- **Deny.** You can specify which files are *not* allowed to run in your environment, and for which users or groups of users. You can also configure exceptions to identify files that are excluded from the rule.
-
**Important**
For a best practice, use allow actions with exceptions. You can use a combination of allow and deny actions but understand that deny actions override allow actions in all cases, and can be circumvented.
-
-
**Important**
If you join a computer running at least Windows Server 2012 or Windows 8 to a domain that already enforces AppLocker rules for executable files, users will not be able to run any packaged apps unless you also create rules for packaged apps. If you want to allow any packaged apps in your environment while continuing to control executable files, you should create the default rules for packaged apps and set the enforcement mode to Audit-only for the packaged apps rule collection.
-
-
## Rule exceptions
-
-
You can apply AppLocker rules to individual users or to a group of users. If you apply a rule to a group of users, all users in that group are affected by that rule. If you need to allow a subset of a user group to use an app, you can create a special rule for that subset. For example, the rule "Allow everyone to run Windows except Registry Editor" allows everyone in the organization to run the Windows operating system, but it does not allow anyone to run Registry Editor.
-
The effect of this rule would prevent users such as Help Desk personnel from running a program that is necessary for their support tasks. To resolve this problem, create a second rule that applies to the Help Desk user group: "Allow Help Desk to run Registry Editor." If you create a deny rule that does not allow any users to run Registry Editor, the deny rule will override the second rule that allows the Help Desk user group to run Registry Editor.
-
## DLL rule collection
-
-
Because the DLL rule collection is not enabled by default, you must perform the following procedure before you can create and enforce DLL rules.
-
Membership in the local **Administrators** group, or equivalent, is the minimum required to complete this procedure.
-
**To enable the DLL rule collection**
-
1. Click **Start**, type **secpol.msc**, and then press ENTER.
-
2. If the **User Account Control** dialog box appears, confirm that the action it displays is what you want, and then click **Yes**.
-
3. In the console tree, double-click **Application Control Policies**, right-click **AppLocker**, and then click **Properties**.
-
4. Click the **Advanced** tab, select the **Enable the DLL rule collection** check box, and then click **OK**.
-
**Important**
Before you enforce DLL rules, make sure that there are allow rules for each DLL that is used by any of the allowed apps.
-
-
## AppLocker wizards
-
-
You can create rules by using two AppLocker wizards:
-
1. The Create Rules Wizard enables you to create one rule at a time.
-
2. The Automatically Generate Rules Wizard allows you to create multiple rules at one time. You can either select a folder and let the wizard create rules for the relevant files within that folder or in case of packaged apps let the wizard create rules for all packaged apps installed on the computer. You can also specify the user or group to which to apply the rules. This wizard automatically generates allow rules only.
-
## Additional considerations
-
-
- By default, AppLocker rules do not allow users to open or run any files that are not specifically allowed. Administrators should maintain an up-to-date list of allowed applications.
-
- There are two types of AppLocker conditions that do not persist following an update of an app:
-
- **A file hash condition** File hash rule conditions can be used with any app because a cryptographic hash value of the app is generated at the time the rule is created. However, the hash value is specific to that exact version of the app. If there are several versions of the application in use within the organization, you need to create file hash conditions for each version in use and for any new versions that are released.
-
- **A publisher condition with a specific product version set** If you create a publisher rule condition that uses the **Exactly** version option, the rule cannot persist if a new version of the app is installed. A new publisher condition must be created, or the version must be edited in the rule to be made less specific.
-
- If an app is not digitally signed, you cannot use a publisher rule condition for that app.
-
- AppLocker rules cannot be used to manage computers running a Windows operating system earlier than Windows Server 2008 R2 or Windows 7. Software Restriction Policies must be used instead. If AppLocker rules are defined in a Group Policy Object (GPO), only those rules are applied. To ensure interoperability between Software Restriction Policies rules and AppLocker rules, define Software Restriction Policies rules and AppLocker rules in different GPOs.
-
- The packaged apps and packaged apps installer rule collection is available on devices running at least Windows Server 2012 and Windows 8.
-
- When the rules for the executable rule collection are enforced and the packaged apps and packaged app installers rule collection does not contain any rules, no packaged apps and packaged app installers are allowed to run. In order to allow any packaged apps and packaged app installers, you must create rules for the packaged apps and packaged app installers rule collection.
-
- When an AppLocker rule collection is set to **Audit only**, the rules are not enforced. When a user runs an application that is included in the rule, the app is opened and runs normally, and information about that app is added to the AppLocker event log.
-
- A custom configured URL can be included in the message that is displayed when an app is blocked.
-
- Expect an increase in the number of Help Desk calls initially because of blocked apps until users understand that they cannot run apps that are not allowed.
-
-
-
-
-
-
-
diff --git a/windows/manage/TOC.md b/windows/manage/TOC.md
index 297672a7bf..b1976dec28 100644
--- a/windows/manage/TOC.md
+++ b/windows/manage/TOC.md
@@ -6,6 +6,7 @@
### [New policies for Windows 10](new-policies-for-windows-10.md)
### [Changes to Group Policy settings for Windows 10 Start](changes-to-start-policies-in-windows-10.md)
### [Bulk provisioning for Windows 10 devices](simple-bulk-provisioning.md)
+### [Diagnostics for devices managed by MDM](diagnostics-for-mdm-devices.md)
### [Windows 10 Mobile and MDM](windows-10-mobile-and-mdm.md)
### [Introduction to configuration service providers (CSPs)](how-it-pros-can-use-configuration-service-providers.md)
## [Manage Windows 10 Start and taskbar layout](windows-10-start-layout-options-and-policies.md)
@@ -27,6 +28,7 @@
#### [Settings and quick actions that can be locked down in Windows 10 Mobile](settings-that-can-be-locked-down.md)
#### [Product IDs in Windows 10 Mobile](product-ids-in-windows-10-mobile.md)
### [Reset a Windows 10 Mobile device](reset-a-windows-10-mobile-device.md)
+### [Group Policies that apply only to Windows 10 Enterprise and Windows 10 Education](group-policies-for-enterprise-and-education-editions.md)
## [Join Windows 10 Mobile to Azure Active Directory](join-windows-10-mobile-to-azure-active-directory.md)
## [Configure devices without MDM](configure-devices-without-mdm.md)
## [Windows 10 servicing options for updates and upgrades](introduction-to-windows-10-servicing.md)
diff --git a/windows/manage/application-development-for-windows-as-a-service.md b/windows/manage/application-development-for-windows-as-a-service.md
index bc011ba032..69df22ff69 100644
--- a/windows/manage/application-development-for-windows-as-a-service.md
+++ b/windows/manage/application-development-for-windows-as-a-service.md
@@ -5,14 +5,13 @@ ms.assetid: 28E0D103-B0EE-4B14-8680-6F30BD373ACF
ms.prod: W10
ms.mktglfcycl: manage
ms.sitesec: library
+ms.pagetype: security
author: jdeckerMS
---
# Application development for Windows as a service
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
- Windows 10 IoT Core (IoT Core)
@@ -23,11 +22,9 @@ Builds distributed as flights provide the Windows engineering team with signific
## Windows 10 release types and cadences
-
Although Microsoft releases flight builds to Windows Insiders, Microsoft will publish two types of Windows 10 releases broadly to the public on an ongoing basis:
**Feature updates** install the latest new features, experiences, and capabilities on devices that are already running Windows 10. Because feature updates contain an entire copy of Windows, they are also what customers use to install Windows 10 on existing devices running Windows 7 or Windows 8.1, and on new devices where no operating system is installed. Microsoft expects to publish an average of one to two new feature updates per year.
-
**Quality updates** deliver security issue resolutions and other important bug fixes. Quality updates will be provided to improve each feature currently in support, on a cadence of one or more times per month. Microsoft will continue publishing quality updates on Update Tuesday (sometimes referred to as Patch Tuesday). Additionally, Microsoft may publish additional quality updates for Windows 10 outside the Update Tuesday process when required to address customer needs.
During Windows 10 development, Microsoft streamlined the Windows product engineering and release cycle so that we can deliver the features, experiences, and functionality customers want, more quickly than ever. We also created new ways to deliver and install feature updates and quality updates that simplify deployments and on-going management, broaden the base of employees who can be kept current with the latest Windows capabilities and experiences, and lower total cost of ownership. Hence we have implemented new servicing options – referred to as Current Branch (CB), Current Branch for Business (CBB), and Long-Term Servicing Branch (LTSB) – that provide pragmatic solutions to keep more devices more current in enterprise environments than was previously possible.
@@ -39,14 +36,11 @@ The following table shows describes the various servicing branches and their key
| Current Branch (CB) | Immediately after first published by Microsoft | Approximately 4 months | Makes new features available to users as soon as possible | Home, Pro, Education, Enterprise, Mobile, IoT Core, Windows 10 IoT Core Pro (IoT Core Pro) |
| Current Branch for Business (CBB) | Approximately 4 months after first published by Microsoft | Approximately 8 months | Provides additional time to test new feature upgrades before deployment | Pro, Education, Enterprise, Mobile Enterprise, IoT Core Pro |
| Long-Term Servicing Branch (LTSB) | Immediately after published by Microsoft | 10 Years | Enables long-term deployment of selected Windows 10 releases in low-change configurations | Enterprise LTSB |
-
-
For more information, see [Windows 10 servicing options for updates and upgrades](introduction-to-windows-10-servicing.md).
## Supporting apps in Windows as a service
-
The traditional approach for supporting apps has been to release a new app version in response to a Windows release. This assumes that there are breaking changes in the underlying OS that could potentially cause a regression with the application. This model involves a dedicated development and validation cycle that requires our ISV partners to align with the Windows release cadence.
In the Windows as a service model, Microsoft is making a commitment to maintaining the compatibility of the underlying OS. This means Microsoft will make a concerted effort to ensure that there are no breaking changes that impact the app ecosystem negatively. In this scenario, when there is a release of a Windows build, most apps (those with no kernel dependencies) will continue to work.
@@ -58,18 +52,16 @@ This approach will reduce the burden of maintaining an app schedule that aligns
| Example of an application lifecycle support statement |
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Contoso is a software development company and is the owner of the popular Mojave app which has a major share in the enterprise space. Contoso releases its next major release Mojave 14.0 and declares mainstream support for a period of three years from the release date. During mainstream support all updates and support are complimentary for the licensed product. Contoso also declares an additional two years of extended support where customers can purchase updates and support for a grace period. Beyond the extended support end date this product version is no longer supported. During the period of mainstream support Contoso will support Mojave 14.0 on all released builds of Windows. Contoso will also release updates to Mojave as necessary and independent of the Windows product releases. |
-
-
In the following sections, you will find additional information about the steps Microsoft takes to maintain the compatibility of the underlying OS. You will also find guidance on steps you can take to help maintain the compatibility of the combined OS and app ecosystem. There is a section on how to leverage Windows flighting builds to detect app regressions before a Windows build is released. Lastly, we describe how we use an instrumentation and telemetry-driven approach to increase the quality of Windows builds. We recommend ISVs adopt a similar approach with their app portfolio.
## Key changes since Windows 7 to ensure app compatibility
+We understand that compatibility matters to developers. ISVs and developers want to ensure their apps will run as expected on all supported versions of the Windows OS. Consumers and businesses have a key investment here—they want to ensure that the apps they have paid for will continue to work. We know that compatibility is the primary criteria for purchase decisions. Apps that are well written based on best practices will lead to much less code churn when
+a new Windows version is released and will reduce fragmentation—these apps have a reduced engineering investment to maintain, and a faster time to market.
-We understand that compatibility matters to developers. ISVs and developers want to ensure their apps will run as expected on all supported versions of the Windows OS. Consumers and businesses have a key investment here—they want to ensure that the apps they have paid for will continue to work. We know that compatibility is the primary criteria for purchase decisions. Apps that are well written based on best practices will lead to much less code churn when a new Windows version is released and will reduce fragmentation—these apps have a reduced engineering investment to maintain, and a faster time to market.
-
-In the Windows 7 timeframe, compatibility was very much a reactive approach. In Windows 8 we started looking at this differently, working within Windows to ensure that compatibility was by design rather than an afterthought. Windows 10 is the most compatible-by-design version of the OS to date. Here are some key ways we accomplished this:
-
+In the Windows 7 timeframe, compatibility was very much a reactive approach. In Windows 8 we started looking at this differently, working within Windows to ensure that compatibility was by design rather than an afterthought.
+Windows 10 is the most compatible-by-design version of the OS to date. Here are some key ways we accomplished this:
- **App telemetry**: This helps us understand app popularity in the Windows ecosystem to inform compatibility testing.
- **ISV partnerships**: Work directly with external partners to provide them with data and help fix issues that our users experience.
- **Design reviews, upstream detection**: Partner with feature teams to reduce the number of breaking changes in Windows. Compatibility review is a gate that our feature teams must pass.
@@ -78,7 +70,6 @@ In the Windows 7 timeframe, compatibility was very much a reactive approach. In
## Microsoft uses data to make Windows 10 better
-
Microsoft uses diagnostic and usage data to identify and troubleshoot problems, improve our products and services, and provide our users with personalized experiences. The usage data we collect also extends to the apps that PCs in the Windows ecosystem are running. Based on what our customers use, we build our list to test these apps, devices, and drivers against new versions of the Windows OS. Windows 10 has been the most compatible version of Windows to-date, with over 90% compatibility against thousands of popular apps. The Windows Compatibility team commonly reaches out to our ISV partners to provide feedback if issues are discovered, so that we can partner together on solutions. Ideally, we’d like our common customers to be able to update Windows seamlessly and without losing functionality in either their OS or the apps they depend on for their productivity or entertainment.
The following sections contain some best practices Microsoft recommends so you can ensure your apps are compatible with Windows 10.
@@ -88,13 +79,11 @@ The following sections contain some best practices Microsoft recommends so you c
The OS version has been incremented with Windows 10. This means that the internal version number has been changed to 10.0. As in the past, we go to great lengths to maintain application and device compatibility after an OS version change. For most app categories (without any kernel dependencies) the change will not negatively impact app functionality, and existing apps will continue to work fine on Windows 10.
The manifestation of this change is app-specific. This means any app that specifically checks for the OS version will get a higher version number, which can lead to one or more of the following situations:
-
- App installers might not be able to install the app, and apps might not be able to start.
- Apps might become unstable or crash.
- Apps might generate error messages, but continue to function properly.
Some apps perform a version check and simply pass a warning to users. However, there are apps that are bound very tightly to a version check (in the drivers, or in kernel mode to avoid detection). In these cases, the app will fail if an incorrect version is found. Rather than a version check, we recommend one of the following approaches:
-
- If the app is dependent on specific API functionality, ensure you target the correct API version.
- Ensure you detect the change via APISet or another public API, and do not use the version as a proxy for some feature or fix. If there are breaking changes and a proper check is not exposed, then that is a bug.
- Ensure the app does NOT check for version in odd ways, such as via the registry, file versions, offsets, kernel mode, drivers, or other means. If the app absolutely needs to check the version, use the GetVersion APIs, which should return the major, minor, and build number.
@@ -103,7 +92,6 @@ Some apps perform a version check and simply pass a warning to users. However, t
If you own apps such as antimalware or firewall apps, you should work through your usual feedback channels and via the Windows Insider program.
**Undocumented APIs**
-
Your apps should not call undocumented Windows APIs, or take dependency on specific Windows file exports or registry keys. This can lead to broken functionality, data loss, and potential security issues. If there is functionality your app requires that is not available, this is an opportunity to provide feedback through your usual feedback channels and via the Windows Insider program.
**Develop Universal Windows Platform (UWP) and Centennial apps**
@@ -113,7 +101,6 @@ We encourage all Win32 app ISVs to develop [Universal Windows Platform (UWP)](ht
If your Win32 app types do not work with the Centennial model, we highly recommend that you use the right installer and ensure this is fully tested. An installer is your user or customer’s first experience with your app, so ensure that this works well. All too often, this doesn’t work well or it hasn’t been fully tested for all scenarios. The [Windows App Certification Kit](http://go.microsoft.com/fwlink/?LinkID=780565) can help you test the install and uninstall of your Win32 app and help you identify use of undocumented APIs, as well as other basic performance-related best-practice issues, before your users do.
**Best pratcices:**
-
- Use installers that work for both 32-bit and 64-bit versions of Windows.
- Design your installers to run on multiple scenarios (user or machine level).
- Keep all Windows redistributables in the original packaging – if you repackage these, it’s possible that this will break the installer.
@@ -121,13 +108,11 @@ If your Win32 app types do not work with the Centennial model, we highly recomme
## Optimized test strategies and flighting
-
Windows OS flighting refers to the interim builds available to Windows Insiders before a final build is released to the general population. The more Insiders that flight these interim builds, the more feedback we receive on the build quality, compatibility, etc., and this helps improve quality of the final builds. You can participate in this flighting program to ensure that your apps work as expected on iterative builds of the OS. We also encourage you to provide feedback on how these flighted builds are working for you, issues you run into, and so on.
If your app is in the Store, you can flight your app via the Store, which means that your app will be available for our Windows Insider population to install. Users can install your app and you can receive preliminary feedback on your app before you release it to the general population. The follow sections outline the steps for testing your apps against Windows flighted builds.
**Step 1: Become a Windows Insider and participate in flighting**
-
As a [Windows Insider,](http://go.microsoft.com/fwlink/p/?LinkId=521639) you can help shape the future of Windows—your feedback will help us improve features and functionality in the platform. This is a vibrant community where you can connect with other enthusiasts, join forums, trade advice, and learn about upcoming Insider-only events.
Since you’ll have access to preview builds of Windows 10, Windows 10 Mobile, and the latest Windows SDK and Emulator, you’ll have all the tools at your disposal to develop great apps and explore what's new in the Universal Windows Platform and the Windows Store.
@@ -135,7 +120,6 @@ Since you’ll have access to preview builds of Windows 10, Windows 10 Mobile,
This is also a great opportunity to build great hardware, with preview builds of the hardware development kits so you can develop universal drivers for Windows. The IoT Core Insider Preview is also available on supported IoT development boards, so you can build amazing connected solutions using the Universal Windows Platform.
Before you become a Windows Insider, please note that participation is intended for users who:
-
- Want to try out software that’s still in development.
- Want to share feedback about the software and the platform.
- Don’t mind lots of updates or a UI design that might change significantly over time.
@@ -146,15 +130,14 @@ Before you become a Windows Insider, please note that participation is intended
**Step 2: Test your scenarios**
Once you have updated to a flighted build, the following are some sample test cases to help you get started on testing and gathering feedback. For most of these tests, ensure you cover both x86 and AMD64 systems.
-
-**Clean install test:** On a clean install of Windows 10, ensure your app is fully functional. If your app fails this test and the upgrade test, then it’s likely that the issue is caused by underlying OS changes or bugs in the app. If after investigation, the former is the case, be sure to use the Windows Insider program to provide feedback and partner on solutions.
+**Clean install test:** On a clean install of Windows 10, ensure your app is fully functional. If your app fails this test and the upgrade test, then it’s likely that the issue is caused by underlying OS changes or bugs in the app.
+If after investigation, the former is the case, be sure to use the Windows Insider program to provide feedback and partner on solutions.
**Upgrade Test:** Check that your app works after upgrading from a down-level version of Windows (i.e. Windows 7 or Windows 8.1) to Windows 10. Your app shouldn’t cause roll backs during upgrade, and should continue to work as expected after upgrade—this is crucial to achieve a seamless upgrade experience.
**Reinstall Test:** Ensure that app functionality can be restored by reinstalling your app after you upgrade the PC to Windows 10 from a down-level OS. If your app didn’t pass the upgrade test and you have not been able to narrow down the cause of these issues, it’s possible that a reinstall can restore lost functionality. A passing reinstall test indicates that parts of the app may not have been migrated to Windows 10.
**OS\\Device Features Test:** Ensure that your app works as expected if your app relies on specific functionality in the OS. Common areas for testing include the following, often against a selection of the commonly used PC models to ensure coverage:
-
- Audio
- USB device functionality (keyboard, mouse, memory stick, external hard disk, and so on)
- Bluetooth
@@ -171,19 +154,9 @@ Once you have updated to a flighted build, the following are some sample test ca
Let us know how your app is performing against flighted builds. As you discover issues with your app during testing, please log bugs via the partner portal if you have access, or through your Microsoft representative. We encourage this information so that we can build a quality experience for our users together.
**Step 4: Register on Windows 10**
-
The [Ready for Windows 10](http://go.microsoft.com/fwlink/?LinkID=780580) website is a directory of software that supports Windows 10. It’s intended for IT administrators at companies and organizations worldwide that are considering Windows 10 for their deployments. IT administrators can check the site to see whether software deployed in their enterprise is supported in Windows 10.
## Related topics
-
-
[Windows 10 servicing options for updates and upgrades](introduction-to-windows-10-servicing.md)
-
-
-
-
-
-
-
diff --git a/windows/manage/change-history-for-manage-and-update-windows-10.md b/windows/manage/change-history-for-manage-and-update-windows-10.md
index 6aa0112b22..df398cfd27 100644
--- a/windows/manage/change-history-for-manage-and-update-windows-10.md
+++ b/windows/manage/change-history-for-manage-and-update-windows-10.md
@@ -16,10 +16,14 @@ This topic lists new and updated topics in the [Manage and update Windows 10](in
| New or changed topic | Description |
| ---|---|
-|[Manage Wi-Fi Sense in your company](manage-wifi-sense-in-enterprise.md) |Removed info about sharing wi-fi network access with contacts, since it's been deprecated. |
-| [Set up a kiosk on Windows 10 Pro, Enterprise, or Education](set-up-a-kiosk-for-windows-10-for-desktop-editions.md) | Corrected script for setting a custom shell using Shell Launcher |
+| [Group Policies that apply only to Windows 10 Enterprise and Education Editions](group-policies-for-enterprise-and-education-editions.md) | New |
| [Configure Windows 10 devices to stop data flow to Microsoft](configure-windows-10-devices-to-stop-data-flow-to-microsoft.md) | Added section on how to turn off Live Tiles |
| [Configure Windows telemetry in your organization](configure-windows-telemetry-in-your-organization.md) | New telemetry content |
+| [Manage Wi-Fi Sense in your company](manage-wifi-sense-in-enterprise.md) |Removed info about sharing wi-fi network access with contacts, since it's been deprecated. |
+| [Set up a kiosk on Windows 10 Pro, Enterprise, or Education](set-up-a-kiosk-for-windows-10-for-desktop-editions.md) | Corrected script for setting a custom shell using Shell Launcher |
+| [Windows 10 servicing options for updates and upgrades](introduction-to-windows-10-servicing.md) | Removed Windows 10 Mobile from **Applies to** |
+
+
## April 2016
diff --git a/windows/manage/configure-windows-10-devices-to-stop-data-flow-to-microsoft.md b/windows/manage/configure-windows-10-devices-to-stop-data-flow-to-microsoft.md
index df77f2d6aa..7b24cfdfbe 100644
--- a/windows/manage/configure-windows-10-devices-to-stop-data-flow-to-microsoft.md
+++ b/windows/manage/configure-windows-10-devices-to-stop-data-flow-to-microsoft.md
@@ -285,8 +285,7 @@ When you enable the **Don't search the web or display web results in Search** Gr
- For **Remote port**, choose **All ports**.
-**Note**
-If your organization tests network traffic, you should not use Fiddler to test Windows Firewall settings. You should use a network traffic analyzer, such as WireShark or Message Analyzer.
+> **Note:** If your organization tests network traffic, you should not use Fiddler to test Windows Firewall settings. You should use a network traffic analyzer, such as WireShark or Message Analyzer.
### 1.2 Cortana MDM policies
@@ -321,8 +320,7 @@ Starting with Windows 10, fonts that are included in Windows but that are not st
To turn off font streaming, create a REG\_DWORD registry setting called **DisableFontProviders** in **HKEY\_LOCAL\_MACHINE\\System\\CurrentControlSet\\Services\\FontCache\\Parameters**, with a value of 1.
-**Note**
-This may change in future versions of Windows.
+> **Note:** This may change in future versions of Windows.
### 5. Insider Preview builds
@@ -408,8 +406,7 @@ Use either Group Policy or MDM policies to manage settings for Microsoft Edge. F
Find the Microsoft Edge Group Policy objects under **Computer Configuration** > **Administrative Templates** > **Windows Components** > **Microsoft Edge**.
-**Note**
-The Microsoft Edge Group Policy names were changed in Windows 10, version 1511. The table below reflects those changes.
+> **Note:** The Microsoft Edge Group Policy names were changed in Windows 10, version 1511. The table below reflects those changes.
| Policy | Description |
|------------------------------------------------------|-----------------------------------------------------------------------------------------------------|
@@ -447,14 +444,12 @@ You can turn off NCSI through Group Policy:
- Enable the Group Policy: **Computer Configuration** > **Administrative Templates** > **System** > **Internet Communication Management** > **Internet Communication Settings** > **Turn off Windows Network Connectivity Status Indicator active tests**
+> **Note** After you apply this policy, you must restart the device for the policy setting to take effect.
+
### 11. Offline maps
You can turn off the ability to download and update offline maps.
-- In the UI: **Settings** > **System** > **Offline maps** > **Automatically update maps**
-
- -or-
-
- Apply the Group Policy: **Computer Configuration** > **Administrative Templates** > **Windows Components** > **Maps** > **Turn off Automatic Download and Update of Map Data**
### 12. OneDrive
@@ -615,10 +610,7 @@ Use Settings > Privacy to configure some settings that may be important to yo
To turn off **Let apps use my advertising ID for experiences across apps (turning this off will reset your ID)**:
-**Note**
-When you turn this feature off in the UI, it turns off the advertising ID, not just resets it.
-
-
+> **Note:** When you turn this feature off in the UI, it turns off the advertising ID, not just resets it.
- Turn off the feature in the UI.
@@ -658,8 +650,7 @@ To turn off **Turn on SmartScreen Filter to check web content (URLs) that Window
To turn off **Send Microsoft info about how I write to help us improve typing and writing in the future**:
-**Note**
-If the telemetry level is set to either **Basic** or **Security**, this is turned off automatically.
+> **Note: ** If the telemetry level is set to either **Basic** or **Security**, this is turned off automatically.
@@ -791,8 +782,7 @@ To turn off **Choose apps that can use your microphone**:
In the **Speech, Inking, & Typing** area, you can let Windows and Cortana better understand your employee's voice and written input by sampling their voice and writing, and by comparing verbal and written input to contact names and calendar entrees.
-**Note**
-For more info on how to disable Cortana in your enterprise, see [Cortana](#bkmk-cortana) in this article.
+> **Note:** For more info on how to disable Cortana in your enterprise, see [Cortana](#bkmk-cortana) in this article.
@@ -985,8 +975,7 @@ To change the level of diagnostic and usage data sent when you **Send your devic
- To change from **Enhanced**, use the drop-down list in the UI. The other levels are **Basic** and **Full**.
- **Note**
- You can't use the UI to change the telemetry level to **Security**.
+ > **Note:** You can't use the UI to change the telemetry level to **Security**.
@@ -1105,6 +1094,10 @@ You can opt of the Microsoft Antimalware Protection Service.
-or-
- Use the registry to set the REG\_DWORD value **HKEY\_LOCAL\_MACHINE\\Software\\Policies\\Microsoft\\Windows Defender\\Spynet\\SpyNetReporting** to 0 (zero).
+
+ -and-
+
+ From an elevated Windows PowerShell prompt, run **set-mppreference -Mapsreporting 0**
You can stop sending file samples back to Microsoft.
diff --git a/windows/manage/configure-windows-10-taskbar.md b/windows/manage/configure-windows-10-taskbar.md
index cd75f09ad8..844b4c022d 100644
--- a/windows/manage/configure-windows-10-taskbar.md
+++ b/windows/manage/configure-windows-10-taskbar.md
@@ -11,7 +11,7 @@ author: jdeckerMS
Starting in Windows 10, version 1607, administrators can pin additional apps to the taskbar and remove default pinned apps from the taskbar by adding a `` section to a layout modification XML file. This method never removes user-pinned apps from the taskbar.
-> **Note:** Only the layout of the taskbar can currently be configured by the layout modification XML file.
+> **Note:** The only aspect of the taskbar that can currently be configured by the layout modification XML file is the layout.
You can specify different taskbar configurations based on device locale and region. There is no limit on the number of apps that you can pin. You specify apps using the [Application User Model ID (AUMID)](http://go.microsoft.com/fwlink/p/?LinkId=614867) or Desktop Application Link Path (the local path to the application).
@@ -21,7 +21,7 @@ The order of apps in the xml file dictates order of apps on taskbar from left to
> **Note** In operating systems configured to use a right-to-left language, the taskbar order will be reversed.
-The following example shows how apps will be pinned: Windows default apps to the left (blue), apps pinned by the user in the center (orange), and apps that you pin using XML to the right (green).
+The following example shows how apps will be pinned: Windows default apps to the left (blue circle), apps pinned by the user in the center (orange triangle), and apps that you pin using XML to the right (green square).
@@ -31,11 +31,23 @@ The following example shows how apps will be pinned: Windows default apps to the
To configure the taskbar:
1. Create the XML file.
* If you are also [customizing the Start layout](customize-and-export-start-layout.md), use `Export-StartLayout` to create the XML, and then add the `` section from the following sample to the file.
- * If you are only configuring the taskbar, use the following sample to create LayoutModification.xml.
-2. Edit and save the XML file. You can use [AUMID](http://go.microsoft.com/fwlink/p/?LinkId=614867), Desktop Application ID, or Desktop Application Link Path to identify the apps to pin to the taskbar.
+ * If you are only configuring the taskbar, use the following sample to create a layout modification XML file.
+2. Edit and save the XML file. You can use [AUMID](http://go.microsoft.com/fwlink/p/?LinkId=614867) or Desktop Application Link Path to identify the apps to pin to the taskbar.
* Use `` and [AUMID](http://go.microsoft.com/fwlink/p/?LinkId=614867) to pin Universal Windows Platform apps.
* Use `` and Desktop Application Link Path to pin desktop applications.
-3. Apply LayoutModification.xml to devices using [Group Policy](customize-windows-10-start-screens-by-using-group-policy.md) or a [provisioning package created in Windows Imaging and Configuration Designer (Windows ICD)](customize-windows-10-start-screens-by-using-provisioning-packages-and-icd.md).
+3. Apply the layout modification XML file to devices using [Group Policy](customize-windows-10-start-screens-by-using-group-policy.md) or a [provisioning package created in Windows Imaging and Configuration Designer (Windows ICD)](customize-windows-10-start-screens-by-using-provisioning-packages-and-icd.md).
+
+### Tips for finding AUMID and Desktop Application Link Path
+
+In the layout modification XML file, you will need to add entries for applications in the XML markup. In order to pin an application, you need either its AUMID or Desktop Application Link Path.
+
+The easiest way to find this data for an application is to:
+1. Pin the application to the Start menu
+2. Open Windows PowerShell and run the `Export-StartLayout` cmdlet.
+3. Open the generated XML file.
+4. Look for an entry corresponding to the app you pinned .
+5. Look for a property labeled `AppUserModelID` or `DesktopApplicationLinkPath`.
+
### Sample taskbar configuration XML
@@ -132,7 +144,7 @@ If you only want to remove some of the default pinned apps, you would use this m
-
+
@@ -182,7 +194,7 @@ The following example shows you how to configure taskbars by country or region.
```
-When the preceding example XML is applied, the resulting tasbkar for computers in the US or UK:
+When the preceding example XML is applied, the resulting taskbar for computers in the US or UK:
@@ -190,7 +202,7 @@ The resulting taskbar for computers in Germany or France:
-The resulting tasbkar for computers in any other country region:
+The resulting taskbar for computers in any other country region:
diff --git a/windows/manage/customize-windows-10-start-screens-by-using-group-policy.md b/windows/manage/customize-windows-10-start-screens-by-using-group-policy.md
index ea985992e5..8ab82b1aec 100644
--- a/windows/manage/customize-windows-10-start-screens-by-using-group-policy.md
+++ b/windows/manage/customize-windows-10-start-screens-by-using-group-policy.md
@@ -20,7 +20,7 @@ author: jdeckerMS
- [Customize the Start menu](http://go.microsoft.com/fwlink/p/?LinkId=623630)
-In Windows 10 Enterprise and Windows 10 Education, you can use a Group Policy Object (GPO) to deploy a customized Start and taskbar layout to users in a domain. No reimaging is required, and the layout can be updated simply by overwriting the .xml file that contains the layout. This enables you to customize Start and tskbar layouts for different departments or organizations, with minimal management overhead.
+In Windows 10 Enterprise and Windows 10 Education, you can use a Group Policy Object (GPO) to deploy a customized Start and taskbar layout to users in a domain. No reimaging is required, and the layout can be updated simply by overwriting the .xml file that contains the layout. This enables you to customize Start and taskbar layouts for different departments or organizations, with minimal management overhead.
This topic describes how to update Group Policy settings to display a customized Start and taskbar layout when the users sign in. By creating a domain-based GPO with these settings, you can deploy a customized Start and taskbar layout to users in a domain.
@@ -36,7 +36,7 @@ When a full Start layout is applied with this method, the users cannot pin, unpi
Start and taskbar layout control using Group Policy is supported in Windows 10 Enterprise and Windows 10 Education, Version 1607. Start and taskbar layout control is not supported in Windows 10 Pro.
-The GPO can be configured from any computer on which the necessary ADMX and ADML files (StartMenu.admx and StartMenu.adml) for Windows 10 are installed. In Group Policy, ADMX files are used to define Registry-based policy settings in the Administrative Templates category. To find out how to create a central store for Administrative Templates files, see [article 929841](http://go.microsoft.com/fwlink/p/?LinkId=691687) in the Microsoft Knowledge Base.
+The GPO can be configured from any computer on which the necessary ADMX and ADML files (StartMenu.admx and StartMenu.adml) for Windows 10 are installed. In Group Policy, ADMX files are used to define Registry-based policy settings in the Administrative Templates category. To find out how to create a central store for Administrative Templates files, see [article 929841, written for Windows Vista and still applicable](http://go.microsoft.com/fwlink/p/?LinkId=691687) in the Microsoft Knowledge Base.
## How Start layout control works
diff --git a/windows/manage/diagnostics-for-mdm-devices.md b/windows/manage/diagnostics-for-mdm-devices.md
new file mode 100644
index 0000000000..e3e725ba1f
--- /dev/null
+++ b/windows/manage/diagnostics-for-mdm-devices.md
@@ -0,0 +1,97 @@
+---
+title: Device Policy State Log (Windows 10)
+description: Device Policy State log in Windows 10, Version 1607, collects info about policies.
+keywords: ["mdm", "udiag", "device policy", "mdmdiagnostics"]
+ms.prod: W10
+ms.mktglfcycl: manage
+ms.sitesec: library
+author: jdeckerMS
+---
+
+# Device Policy State Log
+
+**Applies to**
+
+- Windows 10
+- Windows 10 Mobile
+
+[Diagnostics capability for devices managed by any MDM provider.](https://microsoft.sharepoint.com/teams/osg_core_ens/mgmt/OSMan Wiki/MDM Diagnostics - Generating and Processing Log files.aspx)
+
+[Redstone spec](https://microsoft.sharepoint.com/teams/specstore/_layouts/15/WopiFrame.aspx?sourcedoc=%7b7E8742A2-03A1-451C-BA07-F2573B044CBF%7d&file=DM%20-%20MDM%20Diagnostics-RS.docx&action=default&DefaultItemOpen=1)
+
+The Device Policy State Log, a new log in Windows 10, Version 1607, collects information on the state of policies applied to the device to help you determine which sources are applying policies or configurations to the device. This log is a tool that enables the helpdesk to be more effectively in remotely diagnosing and resolving issues with the device.
+
+Users can easily generate this log, both on PCs and mobile devices. (screenshot of UI)
+
+
+(run script on log to create report)
+
+There are two sections to the report, Configuration and Policy Information. The configuration section enumerates the GUID of the sources that are applying configurations to the device.
+
+The policy information section displays information about the specific policies that are being enforced and on the device. For each policy you will see the Area grouping, the Policy name, its default and current value, in addition to the configuration source.
+
+
+
+
+Event Trace Log (ETL) file
+
+To generate on desktop or phone:
+1. **Settings** > **Accounts** > **Work access** > **Export your management log files**
+2. File is saved:
+ - on desktop: Clicking on **Export** will generate the diagnostic log file, and save it in C:\Users\Public\Documents\MDMDiagnostics
+ - on phone: Copy the file from the phone
+ - Either connect phone to PC and copy the file from Phone\Documents\MDMDiagnostics
+ OR
+ - Mail the log file from your phone by selecting the file from This Device\Documents\MDMDiagnostics
+
+UDiag tool: Uses rule-based analysis to determine root cause based on Event Tracing for Windows (ETW) files; reduces the amount of time needed to determine what the root case of an issue is based on ETW analysis
+1. Open UDiag, and select Device Management.
+2. Select your source for the log files ("cab of logs" or "directory of logs")
+Investigating log content, identifying patterns, and adding a root cause analysis to the database (Advanced users/providers)
+
+
+1. While at the 'Root Causes List' panel, click the 'Diagnose' button at the bottom.
+
+
+2. You will then be brought to the Diagnosis panel where you can investigate and tag root causes from the content
+
+[1] Evidence Groups
+
+
+◦When a set of logs are loaded into UDiag, the contents are processed (e.g. ETW) and organized into evidence groups.
+
+
+•[2] Decision Tree View
+
+
+◦This view shows the loaded decision tree for the current topic/topic area.
+
+◦When a decision node is selected, a user can modify the regular expression and add/edit/delete an RCA for that node. Any RCA matches found in the current log set will have an 'RCA' label that is either Red or Yellow.
+
+•[3] Evidence View
+
+
+◦Selecting an evidence group from [1], loads its content into this evidence view. Use this view to investigate issues and determine root causes. Drag and drop lines from the Evidence View [3] into the Decision Tree View [2], to build your RCA pattern.
+
+
+
+
+
+ Device Policy State Log implementation: what does admin have to do on MDM side to enable "export your management log file"?[DK] Nothing. Generating the log is entirely a client side behavior. There is a new capability in the Diagnostic Log CSP that will enable a MDM ISV to trigger generation and capture of the log over the MDM channel.
+
+ Can admin pull logs without user action? [DK] Yes via the diagnostic log CSP
+
+ Is MDMDiagnostics.xml the file created by "export your management log file"? [DK] Yes
+
+ "Run PowerShell script to process the file" – is that the user doing it? How can this workflow work in an enterprise where employees aren't computer-savvy? [DK] This is intended to be done by the help desk guy.
+
+ Where did (user|admin) get mdmReportGenerator.ps1? [DK] Publishing on DLC later this summer
+
+ In Viewing the report, how does the admin make sense of the source GUIDs? [DK] Correlates the value in the table with the entries at the top of the page.
+
+ UDiag – where does admin get this? [DK] Publishing on DLC later this summer
+
+ Can admins create custom rule sets? [DK] Right now, no. but open to feedback on this.
+
+Link to [Diagnose MDM failures in Windows 10](https://msdn.microsoft.com/en-us/library/windows/hardware/mt632120%28v=vs.85%29.aspx)
+
diff --git a/windows/manage/disconnect-your-organization-from-microsoft.md b/windows/manage/disconnect-your-organization-from-microsoft.md
index 2adc6e5005..f1077326eb 100644
--- a/windows/manage/disconnect-your-organization-from-microsoft.md
+++ b/windows/manage/disconnect-your-organization-from-microsoft.md
@@ -1,4 +1,4 @@
---
title: Configure Windows 10 devices to stop data flow to Microsoft (Windows 10)
-redirect_url: http://technet.microsoft.com/en-us/itpro/windows/manage/configure-windows-10-devices-to-stop-data-flow-to-microsoft
+redirect_url: https://technet.microsoft.com/en-us/itpro/windows/manage/configure-windows-10-devices-to-stop-data-flow-to-microsoft
---
\ No newline at end of file
diff --git a/windows/manage/group-policies-for-enterprise-and-education-editions.md b/windows/manage/group-policies-for-enterprise-and-education-editions.md
new file mode 100644
index 0000000000..ee2fd20508
--- /dev/null
+++ b/windows/manage/group-policies-for-enterprise-and-education-editions.md
@@ -0,0 +1,19 @@
+---
+title: Group Policies that apply only to Windows 10 Enterprise and Education Editions (Windows 10)
+description: Use this topic to learn about Group Policy objects that apply only to Windows 10 Enterprise and Windows 10 Education.
+ms.prod: W10
+ms.mktglfcycl: manage
+ms.sitesec: library
+---
+
+# Group Policies that apply only to Windows 10 Enterprise and Education Editions
+
+**Applies to**
+
+- Windows 10
+
+In Windows 10, version 1511, the following Group Policies apply only to Windows 10 Enterprise and Windows 10 Education.
+
+| Policy name | Policy path | Comments |
+| - | - | - |
+| Turn off the Store application | Computer Configuration > Administrative Templates > Windows Components > Store > Turn off the Store application
User Configuration > Administrative Templates > Windows Components > Store > Turn off the Store | For more info, see [Knowledge Base article# 3135657](https://support.microsoft.com/en-us/kb/3135657).
\ No newline at end of file
diff --git a/windows/manage/images/taskbar-generic.png b/windows/manage/images/taskbar-generic.png
index e206bdc196..6d47a6795a 100644
Binary files a/windows/manage/images/taskbar-generic.png and b/windows/manage/images/taskbar-generic.png differ
diff --git a/windows/manage/index.md b/windows/manage/index.md
index 35e01bcb09..e6aff0c940 100644
--- a/windows/manage/index.md
+++ b/windows/manage/index.md
@@ -2,23 +2,21 @@
title: Manage and update Windows 10 (Windows 10)
description: Learn about managing and updating Windows 10.
ms.assetid: E5716355-02AB-4B75-A962-14B1A7F7BDA0
-keywords: ["Windows 10", "MDM", "WSUS", "Windows update"]
+keywords: Windows 10, MDM, WSUS, Windows update
ms.prod: W10
ms.mktglfcycl: manage
ms.sitesec: library
+ms.pagetype: security
author: jdeckerMS
---
# Manage and update Windows 10
-
Learn about managing and updating Windows 10.
## In this section
-
-
-
## Related topics
-
-
[Windows 10 and Windows 10 Mobile](../index.md)
-
-
-
-
-
-
-
diff --git a/windows/manage/introduction-to-windows-10-servicing.md b/windows/manage/introduction-to-windows-10-servicing.md
index a473efd209..23290ae499 100644
--- a/windows/manage/introduction-to-windows-10-servicing.md
+++ b/windows/manage/introduction-to-windows-10-servicing.md
@@ -2,38 +2,30 @@
title: Windows 10 servicing options for updates and upgrades (Windows 10)
description: This article describes the new servicing options available in Windows 10.
ms.assetid: D1DEB7C0-283F-4D7F-9A11-EE16CB242B42
-keywords: ["update", "LTSB", "lifecycle", "Windows update", "upgrade"]
+keywords: update, LTSB, lifecycle, Windows update, upgrade
ms.prod: W10
ms.mktglfcycl: manage
ms.sitesec: library
+ms.pagetype: security
author: jdeckerMS
---
# Windows 10 servicing options for updates and upgrades
-
**Applies to**
-
- Windows 10
-- Windows 10 Mobile
- Windows 10 IoT Core (IoT Core)
-This article describes the new servicing options available in Windows 10, Windows 10 Mobile, and IoT Core and how they enable enterprises to keep their devices current with the latest feature upgrades. It also covers related topics, such as how enterprises can make better use of Windows Update, and what the new servicing options mean for support lifecycles.
+This article describes the new servicing options available in Windows 10 and IoT Core and how they enable enterprises to keep their devices current with the latest feature upgrades. It also covers related topics, such as how enterprises can make better use of Windows Update, and what the new servicing options mean for support lifecycles.
**Note**
Several of the figures in this article show multiple feature upgrades of Windows being released by Microsoft over time. Be aware that these figures were created with dates that were chosen for illustrative clarity, not for release roadmap accuracy, and should not be used for planning purposes.
-
-
## Introduction
-
In enterprise IT environments, the desire to provide users with the latest technologies needs to be balanced with the need for manageability and cost control. In the past, many enterprises managed their Windows deployments homogeneously and performed large-scale upgrades to new releases of Windows (often in parallel with large-scale hardware upgrades) about every three to six years. Today, the rapid evolution of Windows as a platform for device-like experiences is causing businesses to rethink their upgrade strategies. Especially with the release of Windows 10, there are good business reasons to keep a significant portion of your enterprise's devices *current* with the latest release of Windows. For example, during the development of Windows 10, Microsoft:
-
- Streamlined the Windows product engineering and release cycle so that Microsoft can deliver the features, experiences, and functionality customers want, more quickly than ever.
-
- Created new ways to deliver and install feature upgrades and servicing updates that simplify deployments and on-going management, broaden the base of employees who can be kept current with the latest Windows capabilities and experiences, and lower total cost of ownership.
-
- Implemented new servicing options – referred to as Current Branch (CB), Current Branch for Business (CBB), and Long-Term Servicing Branch (LTSB) – that provide pragmatic solutions to keep more devices more current in enterprise environments than was previously possible.
The remainder of this article provides additional information about each of these areas. This article also provides an overview of the planning implications of the three Windows 10 servicing options (summarized in Table 1) so that IT administrators can be well-grounded conceptually before they start a Windows 10 deployment project.
@@ -42,15 +34,12 @@ Table 1. Windows 10 servicing options
| Servicing option | Availability of new feature upgrades for installation | Minimum length of servicing lifetime | Key benefits | Supported editions |
|-----------------------------------|-----------------------------------------------------------|--------------------------------------|-------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------|
-| Current Branch (CB) | Immediately after first published by Microsoft | Approximately 4 months | Makes new features available to users as soon as possible | Home, Pro, Education, Enterprise, Mobile, IoT Core, Windows 10 IoT Core Pro (IoT Core Pro) |
-| Current Branch for Business (CBB) | Approximately 4 months after first published by Microsoft | Approximately 8 months | Provides additional time to test new feature upgrades before deployment | Pro, Education, Enterprise, Mobile Enterprise, IoT Core Pro |
+| Current Branch (CB) | Immediately after first published by Microsoft | Approximately 4 months | Makes new features available to users as soon as possible | Home, Pro, Education, Enterprise, IoT Core, Windows 10 IoT Core Pro (IoT Core Pro) |
+| Current Branch for Business (CBB) | Approximately 4 months after first published by Microsoft | Approximately 8 months | Provides additional time to test new feature upgrades before deployment | Pro, Education, Enterprise, IoT Core Pro |
| Long-Term Servicing Branch (LTSB) | Immediately after published by Microsoft | 10 Years | Enables long-term deployment of selected Windows 10 releases in low-change configurations | Enterprise LTSB |
-
-
## Streamlined product development and release cycles
-
**Product cycles and builds**
The Windows engineering team adds new features and functionality to Windows through *product cycles* comprised of development, testing, and release phases. Each day during a product cycle, the team compiles the source code for Windows and assembles the output into a *build* that users can install on their devices. The first recipients of builds are Microsoft employees who begin what Microsoft calls *selfhost* testing.
@@ -62,28 +51,21 @@ Prior to Windows 10, Microsoft issued and extensively tested many builds intern
**A different approach for Windows 10**
In today’s environment, where user expectations frequently are set by device-centric experiences, complete product cycles need to be measured in months, not years. Additionally, new releases must be made available on a continual basis, and must be deployable with minimal impact on users. Microsoft designed Windows 10 to meet these requirements by implementing a new approach to innovation development and delivery called *Windows as a Service* (WaaS).
-
The key to enabling significantly shorter product cycles while maintaining high quality levels is an innovative community-centric approach to testing that Microsoft has implemented for Windows 10. The community, known as Windows Insiders, is comprised of millions of users around the world. When Windows Insiders opt in to the community, they test many builds over the course of a product cycle, and provide feedback to Microsoft through an iterative methodology called *flighting*.
-
Builds distributed as *flights* provide the Windows engineering team with significant data regarding how well builds are performing in actual use. Flighting with Windows Insiders also enables Microsoft to test builds in much more diverse hardware, application, and networking environments than in the past, and to identify issues far more quickly. As a result, Microsoft believes that community-focused flighting will enable both a faster pace of innovation delivery, and better public release quality than ever.
**Windows 10 release types and cadences**
Although Microsoft releases flight builds to Windows Insiders, Microsoft will publish two types of Windows 10 releases broadly to the public on an ongoing basis:
-
- **Feature upgrades** that install the latest new features, experiences, and capabilities on devices that are already running Windows 10. Because feature upgrades contain an entire copy of Windows, they are also what customers use to install Windows 10 on existing devices running Windows 7 or Windows 8.1, and on new devices where no operating system is installed.
-
- **Servicing updates** that focus on the installation of security fixes and other important updates.
-
Microsoft expects to publish an average of two to three new feature upgrades per year, and to publish servicing updates as needed for any feature upgrades that are still in support. Microsoft will continue publishing servicing updates on Update Tuesday (sometimes referred to as Patch Tuesday). Additionally, Microsoft may publish additional servicing updates for Windows 10 outside the Update Tuesday process when required to address customer needs.
**The cumulative nature of all Windows 10 releases**
-
It is important to note that, in order to improve release quality and simplify deployments, all new releases that Microsoft publishes for Windows 10 will be *cumulative*. This means new feature upgrades and servicing updates will contain the *payloads* of all previous releases (in an optimized form to reduce storage and networking requirements), and installing the release on a device will bring it completely up to date. Also, unlike earlier versions of Windows, you cannot install a subset of the contents of a Windows 10 servicing update. For example, if a servicing update contains fixes for three security vulnerabilities and one reliability issue, deploying the update will result in the installation of all four fixes.
## New Windows 10 delivery and installation alternatives
-
As with earlier releases of Windows, Windows 10 includes support for the deployment of new releases using Windows Update, Windows Server Update Services, System Center Configuration Manager, and third-party configuration management tools. Because of the importance of the Windows as a Service (WaaS) approach to delivering innovations to businesses, and the proven ability of Windows Update to deploy releases quickly and seamlessly to consumers and small businesses, several of the largest investments in Windows 10 focus on enabling broader use of Windows Update within enterprises.
**Windows Update use by consumers and small businesses**
@@ -101,7 +83,6 @@ To help address the concerns of IT administrators, Microsoft released Windows Se
**New Windows Update capabilities in Windows 10**
To enable enterprises to manage more of their devices using Windows Update directly, Windows 10 provides IT administrators with a way to configure devices so that Windows Update will defer new feature upgrade installations until approximately four months after Microsoft first publishes them. The additional time can be used to perform testing or enable releases to gain additional time in market prior to deployment.
-
At the end of each approximately four month period, Microsoft executes a set of processes that require no action from enterprise IT administrators. First, Microsoft creates new installation media for the feature upgrade by combining the original installation media with all the servicing updates published by Microsoft since the original media’s release. This reduces the time it can take to install a feature upgrade on a device. Second, Microsoft *republishes* the new media to Windows Update with *targeting* instructions that state (in effect) “install this media on devices that are configured for deferred installation of new feature upgrades.” At this point, devices configured to defer installation will begin receiving and installing the feature upgrade automatically.
**The role of Windows Update for Business**
@@ -110,27 +91,19 @@ Although Windows 10 will enable IT administrators to defer installation of new
## Windows 10 servicing options
-
Historically, because of the length of time between releases of new Windows versions, and the relatively low number of enterprise devices that were upgraded to newer versions of Windows during their deployment lifetimes, most IT administrators defined servicing as installing the updates that Microsoft published every month. Looking forward, because Microsoft will be publishing new feature upgrades on a continual basis, *servicing* will also include (on some portion of an enterprise's devices) installing new feature upgrades as they become available.
-
In fact, when planning to deploy Windows 10 on a device, one of the most important questions for IT administrators to ask is, “What should happen to this device when Microsoft publishes a new feature upgrade?” This is because Microsoft designed Windows 10 to provide businesses with multiple servicing options, centered on enabling different rates of feature upgrade adoption. In particular, IT administrators can configure Windows 10 devices to:
-
- Receive feature upgrades immediately after Microsoft makes them available publicly, so that users gain access to new features, experiences, and functionality as soon as possible. For more information, see [Immediate feature upgrade installation with Current Branch (CB) servicing](#immediate-upgrade-cb).
-
- Defer receiving feature upgrades for a period of approximately four months after Microsoft makes them available publicly, to provide IT administrators with time to perform pre-deployment testing and provide feature upgrades releases with additional time-in-market to mature. For more information, see [Deferred feature upgrade installation with Current Branch for Business (CBB) servicing](#deferred-upgrade-cbb).
-
- Receive only servicing updates for the duration of their Windows 10 deployment in order to reduce the number of non-essential changes made to the device. For more information, see [Install servicing updates only by using Long-Term Servicing Branch (LTSB) servicing](#install-updates-ltsb).
-
The breakout of a company’s devices by the categories above is likely to vary significantly by industry and other factors. What is most important is that companies can decide what works best for them and can choose different options for different devices.
## Plan for Windows 10 deployment
-
The remainder of this article focuses on the description of the three options outlined above, and their planning implications, in more detail. In practice, IT administrators have to focus on two areas when planning a Windows 10 device deployment:
-
- **When should new feature upgrades be deployed?** Should the device install new feature upgrades when they are published by Microsoft? If so, should installation occur immediately or on a deferred basis?
-
-- **How will releases be installed on devices?** Will Windows Update or Windows Server Update Services be used to install new releases, or will installation be performed using a configuration management system such as Configuration Manager?
+- **How will releases be installed on devices?** Will Windows Update or Windows Server Update Services be used to install new releases, or will installation be performed using a configuration management system such as
+Configuration Manager?
The content that follows will provide IT administrators with the context needed to understand why these areas are pivotal, and the choices available to them.
@@ -174,17 +147,13 @@ When IT administrators manage deployments of feature upgrades and servicing upda
## Servicing options and servicing branch designations
-
Servicing options have several different attributes that affect deployment planning decisions. For example, each servicing option:
-
- Is supported on a selected set of Windows 10 editions (and no Windows 10 edition supports all three servicing options).
-
- Has a policy that determines the periods of time during which Microsoft will produce servicing updates for a given feature upgrade.
-
- Has a policy that determines when devices being managed by Windows Update or Windows Server Update Services will install new feature upgrades when they become available from Microsoft.
-Because the servicing lifetime of a feature upgrade typically ends when the servicing lifetime of the subsequent feature upgrade begins, the length of servicing lifetimes will also vary. To simplify referring to these ranges, Microsoft created *servicing branch designations* for each of the three time range/servicing branch combinations. The designations are Current Branch (CB), Current Branch for Business (CBB), and Long-Term Servicing Branch (LTSB).
-
+Because the servicing lifetime of a feature upgrade typically ends when the servicing lifetime of the subsequent feature upgrade begins, the length of servicing lifetimes will also vary. To simplify referring to these ranges,
+Microsoft created *servicing branch designations* for each of the three time range/servicing branch combinations. The designations are Current Branch (CB), Current Branch for Business (CBB), and Long-Term Servicing Branch (LTSB).
Because there is a one-to-one mapping between servicing options and servicing branch designations, Microsoft occasionally refers to servicing options using servicing branch-centric terminology. The following sections describe servicing options and servicing branch designations, including terminology, servicing lifetime policies, upgrade behavior, and edition support, in more detail.
**Service lifetime and feature upgrade installation paths**
@@ -204,7 +173,6 @@ To simplify the servicing lifetime and feature upgrade behavior explanations tha
###
**Immediate feature upgrade installation with Current Branch (CB) servicing**
-
As shown in Figure 5, the Current Branch (CB) designation refers to Servicing Branch \#1 during the period that starts when Microsoft publishes a feature upgrade targeted for devices configured for *immediate* installation and ends when Microsoft publishes the *successor* feature upgrade targeted for devices configured for *immediate* installation.
@@ -212,21 +180,15 @@ As shown in Figure 5, the Current Branch (CB) designation refers to Servicing Br
Figure 5. Immediate installation with Current Branch Servicing
The role of Servicing Branch \#1 during the CB period is to produce feature upgrades and servicing updates for Windows 10 devices configured for *immediate* installation of new feature upgrades. Microsoft refers to devices configured this way as being *serviced from CBs*. The Windows 10 editions that support servicing from CBs are Home, Pro, Education, and Enterprise. The Current Branch designation is intended to reflect the fact that devices serviced using this approach will be kept as current as possible with respect to the latest Windows 10 feature upgrade release.
-
Windows 10 Home supports Windows Update for release deployment. Windows 10 editions (Pro, Education, and Enterprise) support Windows Update, Windows Server Update Services, Configuration Manager, and other configuration management systems:
-
- When IT administrators use Windows Update to manage deployments, devices will receive new feature upgrades and servicing updates as soon as they are published by Microsoft in the Windows Update service, targeted to devices configured for *immediate* feature upgrade installation.
-
- When devices are being managed by using Windows Server Update Services, the same workflows are executed as with Windows Update except IT administrators must approve releases before installations begin.
-
- When using configuration management systems such as Configuration Manager to manage deployments, IT administrators can obtain installation media from Microsoft and deploy new feature upgrades immediately by using standard change control processes. IT administrators who use configuration management systems should also make sure to obtain and deploy all servicing updates published by Microsoft as soon as possible.
-
It is important to note that devices serviced from CBs must install two to three feature upgrades per year to remain current and continue to receive servicing updates.
###
**Deferred feature upgrade installation with Current Branch for Business (CBB) servicing**
-
As shown in Figure 6, the Current Branch for Business (CBB) designation refers to Servicing Branch \#1 during the period that starts when Microsoft republishes a feature upgrade targeted for devices configured for *deferred* installation and ends when Microsoft republishes the *second successor* feature upgrade targeted for devices configured for *deferred* installation.
@@ -234,15 +196,10 @@ As shown in Figure 6, the Current Branch for Business (CBB) designation refers t
Figure 6. Deferred installation with Current Branch for Business Servicing
The role of Servicing Branch \#1 during the CBB period is to produce feature upgrades and servicing updates for Windows 10 devices configured for *deferred* installation of new feature upgrades. Microsoft refers to devices configured this way as being *serviced from CBBs*. The Windows 10 editions that support servicing from CBBs are Pro, Education, and Enterprise. The Current Branch for Business designation is intended to reflect the fact that many businesses require IT administrators to test feature upgrades prior to deployment, and servicing devices from CBBs is a pragmatic solution for businesses with testing constraints to remain as current as possible.
-
Windows 10 (Pro, Education, and Enterprise editions) support release deployment by using Windows Update, Windows Server Update Services, Configuration Manager, and other configuration management systems:
-
- When IT administrators use Windows Update to manage deployments, devices will receive new feature upgrades and servicing updates as soon as they are published by Microsoft in the Windows Update service, targeted to devices configured for *deferred* feature upgrade installation. It is important to note that, even when devices are configured to defer installations, all servicing updates that are applicable to the feature upgrade that is running on a device will be installed immediately after being published by Microsoft in the Windows Update service.
-
- When devices are being managed through Windows Server Update Services, the same workflows are executed as with Windows Update except IT administrators must approve releases before installations begin.
-
- When using configuration management systems such as Configuration Manager to manage deployments, IT administrators can obtain media published for deferred installation from Microsoft and deploy new feature upgrades by using standard change control processes. When deferring feature upgrade installations, IT administrators should still deploy all applicable servicing updates as soon as they become available from Microsoft.
-
Microsoft designed Windows 10 servicing lifetime policies so that CBBs will receive servicing updates for approximately twice as many months as CBs. This enables two CBBs to receive servicing support at the same time, which provides businesses with more flexibility when deploying new feature upgrades. That said, it is important to note that Microsoft will not produce servicing updates for a feature upgrade after its corresponding CBB reaches the end of its servicing lifetime. This means that feature upgrade deployments cannot be extended indefinitely and IT administrators should ensure that they deploy newer feature upgrades onto devices before CBBs end.
###
@@ -256,28 +213,20 @@ As shown in Figure 7, the Long-Term Servicing Branch (LTSB) designation refers t
Figure 7. Servicing updates only using LTSB Servicing
The role of LTSBs is to produce servicing updates for devices running Windows 10 configured to install servicing updates only. Devices configured this way are referred to as being *serviced from LTSBs*. The Long-Term Servicing Branch designation is intended to reflect the fact that this servicing option is intended for scenarios where changes to software running on devices must be limited to essential updates (such as those for security vulnerabilities and other important issues) for the duration of deployments.
-
Windows 10 Enterprise LTSB supports release deployment by using Windows Update, Windows Server Update Services, Configuration Manager, and other configuration management systems:
-
- When IT administrators use Windows Update to manage deployments, Windows Update will install only servicing updates, and do so as soon as they are published by Microsoft in the Windows Update service. Windows Update does not install feature upgrades on devices configured for long-term servicing.
-
- When devices are being managed using Windows Server Update Services, the same workflows are executed as with Windows Update except IT administrators must approve releases before installations begin.
-
- When using configuration management systems such as System Center Configuration Manager to manage deployments, IT administrators should make sure to obtain and deploy all servicing updates published by Microsoft as soon as possible.
**Note**
It is important to note again that not all feature upgrades will have an LTSB. The initial release of Windows 10, published in July 2015, has an LTSB and Microsoft expects to designate one additional feature upgrade in the next 12 months for long-term support. After that, Microsoft expects to publish feature upgrades with long-term servicing support approximately every two to three years. Microsoft will provide additional information in advance of publishing new feature upgrades so that IT administrators can make informed deployment planning decisions.
-
-
###
**Considerations when configuring devices for servicing updates only**
-
Before deciding to configure a device for LTSB-based servicing, IT administrators should carefully consider the implications of changing to a different servicing option later, and the effect of using Windows 10 Enterprise LTSB on the availability of *in-box* applications.
Regarding edition changes, it is possible to reconfigure a device running Windows 10 Enterprise LTSB to run Windows 10 Enterprise while preserving the data and applications already on the device. Reconfiguring a device running Windows 10 Enterprise LTSB to run other editions of Windows 10 may require IT administrators to restore data and/or reinstall applications on the device after the other edition has been installed.
-
Regarding in-box applications, Windows 10 Enterprise LTSB does not include all the universal apps that are included with other Windows 10 editions. This is because the universal apps included with Windows 10 will be continually upgraded by Microsoft, and new releases of in-box universal apps are unlikely to remain compatible with a feature upgrade of Windows 10 Enterprise LTSB for the duration of its servicing lifetime. Examples of apps that Windows 10 Enterprise LTSB does not include are Microsoft Edge, Windows Store Client, Cortana (limited search capabilities remain available), Outlook Mail, Outlook Calendar, OneNote, Weather, News, Sports, Money, Photos, Camera, Music, and Clock.
Windows 10 Enterprise LTSB does include Internet Explorer 11, and is compatible with Windows 32 versions of Microsoft Office. IT administrators can also install universal apps on devices when apps are compatible with the feature upgrades running on the device. They should do so with care, however, as servicing updates targeted for devices running Windows 10 Enterprise LTSB will not include security or non-security fixes for universal apps. Additionally, Microsoft will not provide servicing updates for specific releases of apps on any Windows 10 edition after the feature upgrade of Windows 10 with which the apps were included reaches the end of its servicing lifetime.
@@ -285,7 +234,6 @@ Windows 10 Enterprise LTSB does include Internet Explorer 11, and is compatible
**Servicing option summary**
Table 2. Servicing option summary
-
| Comparison |
@@ -304,11 +252,11 @@ Table 2. Servicing option summary
| Supported editions |
-Windows 10 Home, Windows 10 Pro, Windows 10 Education, Windows 10 Enterprise, Windows 10 Mobile,
+ | Windows 10 Home, Windows 10 Pro, Windows 10 Education, Windows 10 Enterprise,
IoT Core, IoT Core Pro |
Windows 10 Pro,
Windows 10 Education,
-Windows 10 Enterprise, Windows 10 Mobile Enterprise,
+Windows 10 Enterprise,
IoT Core Pro |
Windows 10 Enterprise LTSB |
@@ -372,21 +320,12 @@ universal apps removed
-
## Related topics
-
[Plan for Windows 10 deployment](../plan/index.md)
[Deploy Windows 10](http://go.microsoft.com/fwlink/p/?LinkId=624776)
[Manage and update Windows 10](http://go.microsoft.com/fwlink/p/?LinkId=624796)
-
-
-
-
-
-
-
diff --git a/windows/manage/lock-down-windows-10.md b/windows/manage/lock-down-windows-10.md
index 789cf15e86..f0782128f5 100644
--- a/windows/manage/lock-down-windows-10.md
+++ b/windows/manage/lock-down-windows-10.md
@@ -2,7 +2,7 @@
title: Lock down Windows 10 (Windows 10)
description: Windows 10 provides a number of features and methods to help you lock down specific parts of a Windows 10 device.
ms.assetid: 955BCD92-0A1A-4C48-98A8-30D7FAF2067D
-keywords: ["lockdown"]
+keywords: lockdown
ms.prod: W10
ms.mktglfcycl: manage
ms.sitesec: library
@@ -67,23 +67,17 @@ Enterprises often need to manage how people use corporate devices. Windows 10 p
[Reset a Windows 10 Mobile device](reset-a-windows-10-mobile-device.md) |
There are two methods for resetting a Windows 10 Mobile device: factory reset and "wipe and persist" reset. |
+
+[Group Policies that apply only to Windows 10 Enterprise and Windows 10 Education](group-policies-for-enterprise-and-education-editions.md) |
+New |
+
- ## Learn more
+## Learn more
[Customizing Your Device Experience with Assigned Access](https://channel9.msdn.com/Events/Build/2016/P508)
## Related topics
-
[Lockdown features from Windows Embedded Industry 8.1](../whats-new/lockdown-features-windows-10.md)
-
-
-
-
-
-
-
-
-
diff --git a/windows/manage/settings-that-can-be-locked-down.md b/windows/manage/settings-that-can-be-locked-down.md
index 09b88d9160..7849f03187 100644
--- a/windows/manage/settings-that-can-be-locked-down.md
+++ b/windows/manage/settings-that-can-be-locked-down.md
@@ -429,15 +429,12 @@ You can specify the quick actions as follows:
+
+
+
```
-The following quick actions buttons are not conditional and will always be displayed:
-
-- QuickActions\_Launcher\_AllSettings
-- SystemSettings\_Launcher\_QuickNote
-- QuickActions\_Launcher\_DeviceDiscovery
-
Some quick actions are dependent on related settings pages/page groups. When a dependent page/group is not available, then the corresponding quick action will also be hidden.
**Note**
diff --git a/windows/manage/windows-10-mobile-and-mdm.md b/windows/manage/windows-10-mobile-and-mdm.md
index e2155e0da8..076e220c88 100644
--- a/windows/manage/windows-10-mobile-and-mdm.md
+++ b/windows/manage/windows-10-mobile-and-mdm.md
@@ -2,85 +2,48 @@
title: Windows 10 Mobile and mobile device management (Windows 10)
description: This guide provides an overview of the mobile device and app management technologies in the Windows 10 Mobile operating system.
ms.assetid: 6CAA1004-CB65-4FEC-9B84-61AAD2125E5E
+ms.pagetype: mobile; devices
keywords: ["telemetry", "BYOD", "MDM"]
ms.prod: W10
ms.mktglfcycl: manage
ms.sitesec: library
author: AMeeus
---
-
# Windows 10 Mobile and mobile device management
-
-
**Applies to**
-
- Windows 10 Mobile
-
This guide provides an overview of the mobile device and app management technologies in the Windows 10 Mobile operating system. It describes how mobile device management (MDM) systems use the built-in device management client to deploy, configure, maintain, and support phones and small tablets running Windows 10 Mobile.
-
Bring Your Own Device (BYOD—that is, personal devices) and corporate devices are key scenarios that Windows 10 Mobile MDM capabilities support. The operating system offers a flexible approach to registering devices with directory services and MDM systems, and IT organizations can provision comprehensive device-configuration profiles based on their company’s need to control and secure mobile business data.
-
Windows 10 Mobile not only delivers more comprehensive, restrictive configuration settings than Windows Phone 8.1 did but also provides capabilities to deploy and manage apps built on the Universal Windows Platform (UWP). Companies can distribute apps directly from Windows Store or by using their MDM system. They can control and distribute custom line-of-business (LOB) apps the same way.
-
## Overview
-
-
Organizations’ users increasingly depend on their mobile devices, but phones and tablets bring new and unfamiliar challenges for IT departments. IT must be able to deploy and manage mobile devices and apps quickly to support the business while balancing the growing need to protect corporate data because of evolving laws, regulations, and cybercrime. IT must ensure that the apps and data on those mobile devices are safe, especially on personal devices. Windows 10 Mobile helps organizations address these challenges by providing a robust, flexible, built-in MDM client. IT departments can use the MDM system of their choice to manage this client.
-
### Built-in MDM client
-
The built-in MDM client is common to all editions of the Windows 10 operating system, including desktop, mobile, and Internet of Things (IoT). The client provides a single interface through which you can manage any device that runs Windows 10. The client has two important roles: device enrollment in an MDM system and device management.
-
- **Device enrollment.** Users can enroll in the MDM system. On Windows 10, a user can register a device with Microsoft Azure Active Directory (Azure AD) and enroll in an MDM system at the same time so that the system can manage the device, the apps running on it, and the confidential data it holds. Enrollment establishes the management authority for the device. Only one management authority (or MDM enrollment) is possible at a time, which helps prevent unauthorized access to devices and ensures their stability and reliability.
-
- **Device management.** The MDM client allows the MDM system to configure policy settings; deploy apps and updates; and perform other management tasks, such as remotely wiping the device. The MDM system sends configuration requests and collects inventory through the MDM client. The client uses [configuration service providers (CSPs)](http://go.microsoft.com/fwlink/p/?LinkId=734049) to configure and inventory settings. A CSP is an interface to read, set, modify, or delete configuration settings on the device. These settings map to registry keys or files. (The security architecture of Windows 10 Mobile prevents direct access to registry settings and operating system files. For more information, see the [Windows 10 Mobile security guide](../keep-secure/windows-10-mobile-security-guide.md).)
-
The MDM client is an integral part of Windows 10 Mobile. As a result, there is no need for an additional, custom MDM app to enroll the device or to allow an MDM system to manage it. All MDM systems have equal access to Windows 10 Mobile MDM application programming interfaces (APIs), so you can choose Microsoft Intune or a third-party MDM product to manage Windows 10 Mobile devices. For more information about Windows 10 Mobile device management APIs, see [Mobile device management](http://go.microsoft.com/fwlink/p/?LinkId=734050).
-
### Windows 10 Mobile editions
-
Every device that runs Windows 10 Mobile includes all the enterprise mobile device security and management capabilities the MDM client provides. Microsoft also offers an Enterprise edition of Windows 10 Mobile, which includes three additional capabilities. To enable these capabilities, you can provision a license file without reinstalling the operating system:
-
- **Ability to postpone software updates.**Windows 10 Mobile gets software updates directly from Windows Update, and you cannot curate updates prior to deployment. Windows 10 Mobile Enterprise, however, allows you to curate and validate updates prior to deploying them.
-
- **No limit on the number of self-signed LOB apps that you can deploy to a single device.** To use an MDM system to deploy LOB apps directly to devices, you must cryptographically sign the software packages with a code signing certificate that your organization’s certificate authority (CA) generates. You can deploy a maximum of 20 self-signed LOB apps to a Windows 10 Mobile device, more than 20 if your organization’s devices run Windows 10 Mobile Enterprise.
-
- **Set telemetry to security level.** The telemetry security level configures the operating system to gather only the telemetry information required to keep devices secured.
-
**Note**
Your organization can opt to purchase a code signing certificate from Verisign to sign LOB apps or use [Windows Store for Business](windows-store-for-business.md) to obtain apps. With either method, you can distribute more than 20 apps to a single device without activating Windows 10 Mobile Enterprise on that device by using your MDM system.
-
-
To activate Windows 10 Mobile Enterprise on any Windows 10 Mobile device, use your company’s MDM system or a provisioning package to inject a license onto the device. You can download a Windows 10 Mobile Enterprise license from the Business Support Portal.
-
### Lifecycle management
-
Windows 10 Mobile supports end-to-end lifecycle device management to give companies control of their devices, data, and apps. Comprehensive MDM systems use the built-in MDM client to manage devices throughout their lifecycle, as Figure 1 illustrates. The remainder of this guide describes the operating system’s mobile device and app management capabilities through each phase of the lifecycle, showing how MDM systems use specific features.
-
-
Figure 1. Device management lifecycle
-
## Device deployment
-
-
Device deployment includes the initial registration and configuration of the device, including its enrollment with an MDM system. Sometimes, companies preinstall apps. The major factors in how you deploy devices and which controls you put in place are device ownership and how the user will use the device. This guide covers two scenarios:
-
1. Companies allow users to personalize their devices because the users own the devices or because company policy doesn’t require tight controls (defined as *personal devices* in this guide).
-
2. Companies don’t allow users to personalize their devices or they limit personalization, usually because the organization owns the devices and security considerations are high (defined as *corporate devices* in this guide).
-
Often, employees can choose devices from a list of supported models, or companies provide devices that they preconfigure, or bootstrap, with a baseline configuration.
-
Microsoft recommends Azure AD Join and MDM enrollment and management for corporate devices and Azure AD Registration and MDM enrollment and management for personal devices.
-
### Deployment scenarios
-
Most organizations support both personal and corporate device scenarios. The infrastructure for these scenarios is similar, but the deployment process and configuration policies differ. Table 1 describes characteristics of the personal and corporate device scenarios. Activation of a device with an organizational identity is unique to Windows 10 Mobile.
-
Table 1. Characteristics of personal and corporate device scenarios
-
@@ -110,19 +73,12 @@ Table 1. Characteristics of personal and corporate device scenarios
-
-
### Identity management
-
People can use only one account to activate a device, so it’s imperative that your organization control which account you enable first. The account you choose will determine who controls the device and influence your management capabilities. The following list describes the impact that users’ identities have on management (Table 2 summarizes these considerations):
-
- **Personal identity.** In this scenario, employees use their Microsoft account to activate the device. Then, they use their Azure AD account (organizational identity) to register the device in Azure AD and enroll it with the company’s MDM solution. You can apply policies to help protect and contain corporate apps and data on the devices, designed to prevent intellectual property leaks, but users keep full control over personal activities, such as downloading and installing apps and games.
-
- **Organizational identity.** In this scenario, employees use their Azure AD account to register the device to Azure AD and automatically enroll it with the organization’s MDM solution. In this case, companies can block personal use of devices. Using organizational Identities to initialize devices gives organizations complete control over devices and allows them to prevent personalization.
-
Table 2. Personal vs. organizational identity
-
@@ -169,99 +125,53 @@ Table 2. Personal vs. organizational identity
-
-
### Infrastructure requirements
-
For both device scenarios, the essential infrastructure and tools required to deploy and manage Windows 10 Mobile devices include an Azure AD subscription and an MDM system.
-
Azure AD is a cloud-based directory service that provides identity and access management. You can integrate it with existing on-premises directories to create a hybrid solution. Azure AD has three editions: Free, Basic, and Premium (see [Azure Active Directory editions](http://go.microsoft.com/fwlink/p/?LinkId=723980)). All editions support Azure AD device registration, but the Premium edition is required to enable MDM auto-enrollment and conditional access based on device state. Organizations that use Microsoft Office 365 or Intune are already using Azure AD.
-
**Note**
Most industry-leading MDM vendors already support integration with Azure AD or are working on integration. You can find the MDM vendors that support Azure AD in [Azure Marketplace](http://go.microsoft.com/fwlink/p/?LinkId=723981).
-
-
Users can enroll Windows 10 Mobile devices in third-party MDM systems without using an Azure AD organizational account. (By default, Intune uses Azure AD and includes a license). If your organization doesn’t use Azure AD, you must use a personal identity to activate devices and enable common scenarios, such as downloading apps from Windows Store.
-
Multiple MDM systems that support Windows 10 Mobile are available. Most support personal and corporate device deployment scenarios. Microsoft offers [Intune](http://go.microsoft.com/fwlink/p/?LinkId=723983), which is part of the [Enterprise Mobility Suite](http://go.microsoft.com/fwlink/p/?LinkId=723984) and a cloud-based MDM system that manages devices off premises. Like Office 365, Intune uses Azure AD for identity management, so employees use the same credentials to enroll devices in Intune or sign in to Office 365. Intune supports devices that run other operating systems, as well, such as iOS and Android, to provide a complete MDM solution.
-
You can also integrate Intune with System Center Configuration Manager to gain a single console in which to manage all devices—in the cloud and on premises. For more information, see [Manage Mobile Devices with Configuration Manager and Microsoft Intune](http://go.microsoft.com/fwlink/p/?LinkId=734051). For guidance on choosing between a stand-alone Intune installation and Intune integrated with Configuration Manager, see [Choose between Intune by itself or integrating Intune with System Center Configuration Manager](http://go.microsoft.com/fwlink/p/?LinkId=723985).
-
In addition to Intune, other MDM providers support Windows 10 Mobile. Currently, the following MDM systems claim to support Windows 10 and Windows 10 Mobile: [AirWatch](http://go.microsoft.com/fwlink/p/?LinkId=723986), [Citrix](http://go.microsoft.com/fwlink/p/?LinkId=723987), [Lightspeed Systems](http://go.microsoft.com/fwlink/p/?LinkId=723988), [Matrix42](http://go.microsoft.com/fwlink/p/?LinkId=723989), [MobileIron](http://go.microsoft.com/fwlink/p/?LinkId=723990), [SAP](http://go.microsoft.com/fwlink/p/?LinkId=723991), [SOTI](http://go.microsoft.com/fwlink/p/?LinkId=723992), and [Symantec](http://go.microsoft.com/fwlink/p/?LinkId=723993).
-
All MDM vendors have equal access to the [Windows 10 MDM APIs](http://go.microsoft.com/fwlink/p/?LinkId=734050). The extent to which they implement these APIs depends on the vendor. Contact your preferred MDM vendor to determine its level of support.
-
**Note**
Although not covered in this guide, you can use Exchange ActiveSync (EAS) to manage mobile devices instead of using a full-featured MDM system. EAS is available in Microsoft Exchange Server 2010 or later and Office 365.
-
In addition, Microsoft recently added MDM capabilities powered by Intune to Office 365. MDM for Office 365 supports mobile devices only, such as those running Windows 10 Mobile, iOS, and Android. MDM for Office 365 offers a subset of the management capabilities found in Intune, including the ability to remotely wipe a device, block a device from accessing Exchange Server email, and configure device policies (for example, passcode requirements). For more information about MDM for Office 365 capabilities, see [Overview of Mobile Device Management for Office 365](http://go.microsoft.com/fwlink/p/?LinkId=734052).
-
-
### Provisioning
-
Provisioning is new to Windows 10 and uses the MDM client in Windows 10 Mobile. You can create a runtime provisioning package to apply settings, profiles, and file assets to a device running Windows 10.
-
To assist users with MDM system enrollment, use a provisioning package. To do so, use the [Windows Imaging and Configuration Designer](http://go.microsoft.com/fwlink/p/?LinkId=733911) to create a provisioning package, and then install that package on the device.
-
Users can perform self-service MDM enrollment based on the following deployment scenarios:
-
- **Corporate device.** During the out-of-the-box experience (OOBE), you can instruct the user to select **This device is owned by my organization** and join the device to Azure AD and the MDM system.
-
- **Personal device.** The user activates the device with a Microsoft account, but you can instruct him or her to register the device with Azure AD and enroll in Intune. To do so in Windows 10 Mobile, the user clicks, **Settings**, clicks **Accounts**, and then clicks **Work access**.
-
To automate MDM enrollment, use provisioning packages as follows:
-
- **Corporate device.** You can create a provisioning package and apply it to a corporate device before delivery to the user, or instruct the user to apply the package during OOBE. After application of the provisioning package, the OOBE process automatically chooses the enterprise path and requires the user to register the device with Azure AD and enroll it in the MDM system.
-
- **Personal device.** You can create a provisioning package and make it available to users who want to enroll their personal device in the enterprise. The user enrolls the device in the corporate MDM for further configuration by applying the provisioning package. To do so in Windows 10 Mobile, the user clicks **Settings**, clicks **Accounts**, and then clicks **Provisioning**).
-
Distribute provisioning packages to devices by publishing them in an easily accessible location (e.g., an email attachment or a web page). You can cryptographically sign or encrypt provisioning packages and require that the user enter a password to apply them.
-
See [Build and apply a provisioning package](http://go.microsoft.com/fwlink/p/?LinkId=734054) for more information on creating provisioning packages.
-
## Device configuration
-
-
The following sections describe the device configuration capabilities of the built-in Windows 10 Mobile MDM client. This client exposes the capabilities to any MDM system compatible with Windows 10. Configurable settings include:
-
- [Email accounts](#email)
-
- [Account restrictions](#restrictions)
-
- [Device lock restrictions](#device-lock)
-
- [Hardware restrictions](#hardware)
-
- [Certificate management](#certificate)
-
- [Wi-Fi](#wifi)
-
- [Proxy](#proxy)
-
- [Virtual private network (VPN)](#vpn)
-
- [Access point name (APN) profiles](#apn)
-
- [Data leak prevention](#data)
-
- [Storage management](#storage)
-
**Note**
Although all the MDM settings this section describes are available in Windows 10 Mobile, not all MDM systems may show them in their user interface. In addition, naming may vary among MDM systems. Consult your MDM system’s documentation for more information.
-
-
### Email accounts
-
You can use your corporate MDM system to manage corporate email accounts. Define email account profiles in the MDM system, and then deploy them to devices. You would usually deploy these settings immediately after enrollment, regardless of scenario.
-
This capability extends to email systems that use EAS. Table 3 lists settings that you can configure in EAS email profiles.
-
Table 3. Windows 10 Mobile settings for EAS email profiles
-
| Setting | Description |
|----------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Email Address | The email address associated with the EAS account |
@@ -279,13 +189,9 @@ Table 3. Windows 10 Mobile settings for EAS email profiles
| Use SSL | Establishes whether Secure Sockets Layer (SSL) is required when syncing |
| Mail Age Filter | The age of messages to be synchronized with the device (for example, synchronizing messages within the past 7 days) |
| Content Types | The content type that is synchronized (e.g., email, contacts, calendar, task items) |
-
-
Table 4 lists settings that you can configure in other email profiles.
-
Table 4. Windows 10 Mobile settings for other email profiles
-
| Setting | Description |
|-------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------|
| User logon name | The user logon name for the email account |
@@ -316,36 +222,23 @@ Table 4. Windows 10 Mobile settings for other email profiles
| Alternate SMTP account enabled | Whether the user’s alternative SMTP account is enabled |
| Alternate SMTP password | The password for the user’s alternative SMTP account |
| Incoming and outgoing servers require SSL | A group of properties that specify whether the incoming and outgoing email servers use SSL |
-
-
### Account restrictions
-
On a corporate device registered with Azure AD and enrolled in the MDM system, you can control whether users can use a Microsoft account or add other consumer email accounts. Table 5 lists the settings that you can use to manage accounts on Windows 10 Mobile devices.
-
Table 5. Windows 10 Mobile account management settings
-
| Setting | Description |
|-------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Allow Microsoft Account | Specifies whether users are allowed to add a Microsoft account to the device after MDM enrollment and use this account for connection authentication and services, such as purchasing apps in Windows Store, or cloud-based consumer services, such as Xbox or Groove. If a device was activated with a Microsoft account, the MDM system would not be able to block that account from being used. |
| Allow Adding Non Microsoft Accounts | Specifies whether users are allowed to add email accounts other than Microsoft accounts after MDM enrollment. If **Allow Microsoft Account** is applied, user can also not use a Microsoft account. |
| Allow “Your Account” | Specifies whether users are able to change account configuration in the **Your Email and Accounts** panel in Settings. |
-
-
### Device lock restrictions
-
It’s common sense to lock a device when it is not in use. Microsoft recommends that you secure Windows 10 Mobile devices and implement a device lock policy. A device password or PIN lock is a best practice for securing apps and data on devices. [Windows Hello](http://go.microsoft.com/fwlink/p/?LinkId=723994) is the name given to the new biometric sign-in option that allows users to use their face, iris, or fingerprints to unlock their compatible device, all of which Windows 10 supports.
-
**Note**
In addition to the device lock restrictions discussed in this section, Windows 10 supports Microsoft Passport for Work, which lets you access apps and services without a password.
-
-
Table 6 lists the MDM settings in Windows 10 Mobile that you can use to configure device lock restrictions.
-
Table 6. Windows 10 Mobile device lock restrictions
-
@@ -419,20 +312,13 @@ Table 6. Windows 10 Mobile device lock restrictions
-
-
### Hardware restrictions
-
Windows 10 Mobile devices use state-of-the-art technology that includes popular hardware features such as cameras, global positioning system (GPS) sensors, microphones, speakers, near-field communication (NFC) radios, storage card slots, USB interfaces, Bluetooth interfaces, cellular radios, and Wi-Fi. You can also use hardware restrictions to control the availability of these features. Table 7 lists the MDM settings that Windows 10 Mobile supports to configure hardware restrictions.
-
**Note**
Some of these hardware restrictions provide connectivity and assist in data protection. Enterprise data protection is currently being tested in select customer evaluation programs.
-
-
Table 7. Windows 10 Mobile hardware restrictions
-
| Setting | Description |
|--------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------|
| Allow NFC | Whether the NFC radio is enabled |
@@ -450,15 +336,10 @@ Table 7. Windows 10 Mobile hardware restrictions
| Allow Storage Card | Whether the storage card slot is enabled |
| Allow Voice Recording | Whether the user can use the microphone to create voice recordings |
| Allow Location | Whether the device can use the GPS sensor or other methods to determine location so applications can use location information |
-
-
### Certificate management
-
Managing certificates can be difficult for users, but certificates are pervasive for a variety of uses, including, account authentication, Wi-Fi authentication, VPN encryption, and SSL encryption of web content. Although users could manage certificates on devices manually, it’s a best practice to use your MDM system to manage those certificates for their entire life cycle, from enrollment through renewal to revocation. You can use the Simple Certificate Enrollment Protocol (SCEP) and Personal Information Exchange (PFX) certificates files to install certificates on Windows 10 Mobile. Certificate management through SCEP and MDM systems is fully transparent to users and requires no user intervention, so it helps improve user productivity and reduce support calls. Your MDM system can automatically deploy these certificates to the devices’ certificate stores after you enroll the device. Table 8 lists the SCEP settings that the MDM client in Windows 10 Mobile provides.
-
Table 8. Windows 10 Mobile SCEP certificate enrollment settings
-
| Setting | Description |
|------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Certificate enrollment server URLs | The certificate enrollment servers (to specify multiple server URLs, separate the URLs with semicolons \[;\]) |
@@ -478,13 +359,9 @@ Table 8. Windows 10 Mobile SCEP certificate enrollment settings
| Valid period units | The number of units of time that the certificate is considered valid (Use this setting with the **Valid Period** setting. For example, if this setting is **3** and **Valid Period** is **Years**, the certificate is valid for 3 years.) |
| Custom text to show in Microsoft Passport PIN prompt | The custom text to show on the Microsoft Passport PIN prompt during certificate enrollment |
| Thumbprint | The current certificate thumbprint, if certificate enrollment succeeds |
-
-
In addition to SCEP certificate management, Windows 10 Mobile supports deployment of PFX certificates. Table 9 lists the Windows 10 Mobile PFX certificate deployment settings.
-
Table 9. Windows 10 Mobile PFX certificate deployment settings
-
| Setting | Description |
|-----------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Private key storage | Where to store the private key (in other words, the TPM, a software KSP, or the Microsoft Passport KSP) |
@@ -494,36 +371,21 @@ Table 9. Windows 10 Mobile PFX certificate deployment settings
| PFX packet password encryption | Whether the MDM system encrypts the PFX certificate password with the MDM certificate |
| PFX private key export | Whether the PFX private key can be exported |
| Thumbprint | The thumbprint of the installed PFX certificate |
-
-
Use the **Allow Manual Root Certificate Installation** setting to prevent users from manually installing root and intermediate CA certificates intentionally or accidently.
-
**Note**
To diagnose certificate-related issues on Windows 10 Mobile devices, use the free [Certificates app](http://go.microsoft.com/fwlink/p/?LinkId=723996) in Windows Store. This Windows 10 Mobile app can help you:
-
- View a summary of all personal certificates.
-
- View the details of individual certificates.
-
- View the certificates used for VPN, Wi-Fi, and email authentication.
-
- Identify which certificates may have expired.
-
- Verify the certificate path and confirm that you have the correct intermediate and root CA certificates.
-
- View the certificate keys stored in the device TPM.
-
-
### Wi-Fi
-
People use Wi-Fi on their mobile devices as much as or more than cellular data. Most corporate Wi-Fi networks require certificates and other complex information to restrict and secure user access. This advanced Wi-Fi information is difficult for typical users to configure, but you can use your MDM system to fully configure Wi-Fi settings without user intervention.
-
Table 10 lists the Windows 10 Mobile Wi-Fi connection profile settings. Use the information in this table to help you create Wi-Fi connection profiles in your MDM system.
-
Table 10. Windows 10 Mobile Wi-Fi connection profile settings
-
@@ -592,35 +454,23 @@ Table 10. Windows 10 Mobile Wi-Fi connection profile settings
-
-
Table 11 lists the Windows 10 Mobile settings for managing Wi-Fi connectivity.
-
Table 11. Windows 10 Mobile Wi-Fi connectivity settings
-
| Setting | Configuration |
|--------------------------------------------|----------------------------------------------------------------------------|
| Allow Auto Connect To Wi-Fi Sense Hotspots | Whether the device will automatically detect and connect to Wi-Fi networks |
| Allow Manual Wi-Fi Configuration | Whether the user can manually configure Wi-Fi settings |
| Allow Wi-Fi | Whether the Wi-Fi hardware is enabled |
| WLAN Scan Mode | How actively the device scans for Wi-Fi networks |
-
-
### Proxy
-
Apps running on Windows 10 Mobile (for example, Microsoft Edge) can use proxy connections to access Internet content, but Wi-Fi connections on the corporate intranet most typically use proxy connections, instead. You can define multiple proxies in Windows 10 Mobile.
-
**Note**
Windows 10 Mobile also supports proxy auto-configuration (PAC) files, which can automatically configure proxy settings. The Web Proxy Auto-Discovery Protocol (WPAD) lets apps use Dynamic Host Configuration Protocol and Domain Name System (DNS) lookups to locate the PAC file.
-
-
Table 12 lists the Windows 10 Mobile settings for proxy connections.
-
Table 12. Windows 10 Mobile proxy connection settings
-
@@ -686,27 +536,16 @@ Table 12. Windows 10 Mobile proxy connection settings
-
-
### VPN
-
In addition to Wi-Fi, users often use a VPN to securely access apps and resources on their company’s intranet behind a firewall. Windows 10 Mobile supports several VPN vendors in addition to native Microsoft VPNs (such as Point to Point Tunneling Protocol \[PPTP\], Layer 2 Tunneling Protocol \[L2TP\], and Internet Key Exchange Protocol version 2 \[IKEv2\]), including:
-
- IKEv2
-
- IP security
-
- SSL VPN connections (which require a downloadable plug-in from the VPN server vendor)
-
You can configure Windows 10 Mobile to use auto-triggered VPN connections, as well. You define a VPN connection for each app that requires intranet connectivity. When users switch between apps, the operating system automatically establishes the VPN connection for that app. In the event the device drops the VPN connection, Windows 10 Mobile automatically reconnects to the VPN without user intervention.
-
With always-on VPN, Windows 10 Mobile can automatically start a VPN connection when a user signs-in, as well. The VPN stays connected until the user manually disconnects it.
-
MDM support for VPN connections in Windows 10 Mobile includes provisioning and updating VPN connection profiles and associating VPN connections with apps. You can create and provision VPN connection profiles, and then deploy them to managed devices that run Windows 10 Mobile. Table 13 lists the Windows 10 Mobile fields for VPN connection profiles.
-
Table 13. Windows 10 Mobile VPN connection profile settings
-
@@ -839,31 +678,20 @@ Table 13. Windows 10 Mobile VPN connection profile settings
-
-
Table 14 lists the Windows 10 Mobile settings for managing VPN connections. These settings help you manage VPNs over cellular data connections, which in turn help reduce costs associated with roaming or data plan charges.
-
Table 14. Windows 10 Mobile VPN management settings
-
| Setting | Description |
|--------------------------------------|---------------------------------------------------------------------------------|
| Allow VPN | Whether users can change VPN settings |
| Allow VPN Over Cellular | Whether users can establish VPN connections over cellular networks |
| Allow VPN Over Cellular when Roaming | Whether users can establish VPN connections over cellular networks when roaming |
-
-
### APN profiles
-
An APN defines network paths for cellular data connectivity. Typically, you define just one APN for a device in collaboration with a mobile operator, but you can define multiple APNs if your company uses multiple mobile operators.
-
An APN provides a private connection to the corporate network that is unavailable to other companies on the mobile operator network. Corporations in Europe and the Asia-Pacific use APNs, but they are not common in the United States.
-
You can define and deploy APN profiles in MDM systems that configure cellular data connectivity for Windows 10 Mobile. Devices running Windows 10 Mobile can have only one APN profile. Table 15 lists the MDM settings that Windows 10 Mobile supports for APN profiles.
-
Table 15. Windows 10 Mobile APN profile settings
-
@@ -923,15 +751,10 @@ Table 15. Windows 10 Mobile APN profile settings
-
-
### Data leak protection
-
Some user experiences can risk corporate data stored on corporate devices. For example, allowing users to copy and paste information out of the organization’s LOB app can put data at risk. To mitigate the risk, you can restrict the Windows 10 Mobile user experience to help protect corporate data and prevent data leaks. For example, you can prevent settings synchronization, copy-and-paste operations, and screen captures. Table 16 lists the MDM settings in Windows 10 Mobile that you can use to help prevent data leaks.
-
Table 16. Windows 10 Mobile data leak protection settings
-
| Setting | Description |
|----------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Allow copy and paste | Whether users can copy and paste content |
@@ -944,25 +767,15 @@ Table 16. Windows 10 Mobile data leak protection settings
| Allow sync my settings | Whether the user experience settings are synchronized between devices (works with Microsoft accounts only) |
| Allow toasts notifications above lock screen | Whether users are able to view toast notification on the device lock screen |
| Allow voice recording | Whether users are allowed to perform voice recordings. |
-
-
### Storage management
-
Protecting the apps and data stored on a device is critical to device security. One method for helping protect your apps and data is to encrypt internal device storage by using the device encryption in Windows 10 Mobile. This encryption helps protect corporate data against unauthorized access, even when an unauthorized user has physical possession of the device.
-
A feature in Windows 10 Mobile is the ability to install apps on a secure digital (SD) card. The operating system stores apps on a partition specifically designated for that purpose. This feature is always on, so you don’t need to set a policy explicitly to enable it.
-
The SD card is uniquely paired with a device. No other devices can see the apps or data on the encrypted partition, but they can access the data stored on the unencrypted partition of the SD card, such as music or photos.
-
You can disable the **Allow Storage Card** setting to prevent users from using SD cards altogether, but the primary advantage of the SD card app partition–encryption feature is that organizations can give users the flexibility to use an SD card while still protecting the confidential apps and data on it.
-
If you don’t encrypt storage, you can help protect your corporate apps and data by using the **Restrict app data to the system volume** and **Restrict apps to the system volume** settings. They help ensure that users cannot copy your apps and data to SD cards.
-
Table 17 lists the MDM storage-management settings that Windows 10 Mobile provides.
-
Table 17. Windows 10 Mobile storage management settings
-
@@ -1011,66 +824,35 @@ Table 17. Windows 10 Mobile storage management settings
-
-
## App management
-
-
Apps help improve user productivity on mobile devices. New to Windows 10 is the ability for organizations purchase apps from Windows Store for their employees and deploy those apps from Windows Store or an MDM system. App management is becoming a key capability of MDM systems, helping reduce the effort required to perform common app-related tasks, such as distributing apps, and protecting data through app policies. This section describes the app management features in Windows 10 Mobile and includes the following topics:
-
- [Universal Windows Platform (UWP)](#uwp)
-
- [Sourcing the right app](#sourcing)
-
- [Windows Store for Business](#store)
-
- [Mobile application management (MAM) policies](#mam)
-
- [Microsoft Edge](#edge)
-
### Universal Windows Platform
-
Windows 10 introduces UWP, converging the application platform for all devices running some edition of Windows 10. UWP apps run without modification on all editions of Windows 10, and Windows Store now has apps that you can license and purchased for all your Windows 10 devices. Windows Phone 8.1 and Windows 8.1 apps still run on Windows 10 devices, but the MAM improvements in Windows 10 work only with UWP apps. See the [Guide to Universal Windows Platform (UWP) apps](http://go.microsoft.com/fwlink/p/?LinkId=734056) for additional information.
-
### Sourcing the right app
-
The first step in app management is to obtain the apps your users need, and you can now acquire apps from Windows Store. Developers can also create apps specific to an organization, known as *line-of-business (LOB) apps* (the developers of these apps are *LOB publishers*). An LOB developer (internal or external) can now publish these apps to Windows Store at your request, or you can obtain the app packages offline and distribute them through your MDM system.
-
To install Windows Store or LOB apps, use the Windows Store cloud service or your MDM system to distribute the app packages. Your MDM system can deploy apps online by redirecting the user to a licensed app in Windows Store or offline by distributing a package that you downloaded from Windows Store (also called *sideloading*) on Windows 10 Mobile devices. You can fully automate the app deployment process so that no user intervention is required.
-
IT administrators can obtain apps through Store for Business. Most apps can be distributed online, meaning that the user must be logged in to the device with an Azure AD account and have Internet access at the time of installation. To distribute an app offline, the developer must opt in. If the app developer doesn’t allow download of the app from Windows Store, then you must obtain the files directly from the developer or use the online method. See [Windows Store for Business](windows-store-for-business.md) for additional information about apps obtained through Store for Business.
-
Windows Store apps are automatically trusted. For custom LOB apps developed internally or by a trusted software vendor, ensure that the device trusts the app signing certificate. There are two ways to establish this trust: use a signing certificate from a trusted source, or generate your own signing certificate and add your chain of trust to the trusted certificates on the device. You can install up to 20 self-signed apps on a Windows 10 Mobile device. When you purchase a signing certificate from a public CA, you can install more than 20 apps on a device, although you can install more than 20 self-signed apps per device with [Windows 10 Mobile Enterprise](#mobile-edition).
-
Users can install apps from Windows Store that the organization purchases through the Store app on their device. If you allow your users to log in with a Microsoft account, the Store app on the device provides a unified method for installing personal and corporate apps.
-
### Store for Business
-
[Windows Store for Business](http://go.microsoft.com/fwlink/p/?LinkId=722910) is a web portal that IT pros and purchasers use to find, acquire, manage, and distribute apps to Windows 10 devices. This online portal gives Azure AD authenticated managers access to Store for Business functionality and settings. Store managers can create a private section of Windows Store in which organizations can manage apps specific and private to them. Store for Business allows organizations to make apps available to their users and purchase app licenses for them. They can also integrate their Store for Business subscriptions with their MDM systems, so the MDM system can deploy apps from their free Store for Business subscription.
-
The process for using Store for Business is as follows:
-
1. Create a Store for Business subscription for your organization.
-
2. In the Store for Business portal, acquire apps from Windows Store (only free apps are available at this time).
-
3. In Store for Business, distribute apps to users, and manage the app licenses for the apps acquired in the previous step.
-
4. Integrate your MDM system with your organization’s Store for Business subscription.
-
5. Use your MDM system to deploy the apps.
-
For more information about Store for Business, see [Windows Store for Business](windows-store-for-business.md).
-
### Mobile application management (MAM) policies
-
With MDM, you can manage Device Guard on Windows 10 Mobile and create an allow (whitelist) or deny (blacklist) list of apps. This capability extends to built-in apps, as well, such as phone, text messaging, email, and calendar. The ability to allow or deny apps helps to ensure that people use their mobile devices for their intended purposes.
-
You can also control users’ access to Windows Store and whether the Store service updates apps automatically. You can manage all these capabilities through your MDM system. Table 18 lists the Windows 10 Mobile app management settings.
-
Table 18. Windows 10 Mobile app management settings
-
| Setting | Description |
|------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Allow All Trusted Apps | Whether users can sideload apps on the device |
@@ -1084,17 +866,11 @@ Table 18. Windows 10 Mobile app management settings
| Restrict App Data To System Volume | Whether app data is allowed only on the system drive |
| Restrict App To System Volume | Whether app installation is allowed only to the system drive |
| Start screen layout | An XML blob used to configure the Start screen (See [Start layout for Windows 10 Mobile editions](http://go.microsoft.com/fwlink/p/?LinkId=734057) for more information.) |
-
-
One potential security issue is that users can register as Windows 10 Mobile app developers and turn on developer features on their device, potentially installing apps from unknown sources and opening the device to malware threats. To prevent users from turning on developer features on their devices, set the **Disable development unlock (side loading)** policy, which you can configure through your MDM system.
-
### Microsoft Edge
-
MDM systems give you the ability to manage Microsoft Edge on mobile devices. Table 19 lists the Microsoft Edge settings for Windows 10 Mobile.
-
Table 19. Microsoft Edge settings for Windows 10 Mobile
-
| Setting | Description |
|-------------------------------------------------|-------------------------------------------------------------------------------------------------------|
| Allow Active Scripting | Whether active scripting is allowed |
@@ -1108,32 +884,18 @@ Table 19. Microsoft Edge settings for Windows 10 Mobile
| Allow SmartScreen | Whether SmartScreen Filter is enabled |
| First Run URL | The URL to open when a user launches Microsoft Edge for the first time |
| Prevent Smart Screen Prompt Override For Files | Whether users can override the SmartScreen Filter warnings about downloading unverified files |
-
-
## Device operations
-
-
In this section, you learn how MDM settings in Windows 10 Mobile enable the following scenarios:
-
- [Device update](#device-update)
-
- [Device compliance monitoring](#device-comp)
-
- [Device inventory](#data-inv)
-
- [Remote assistance](#remote-assist)
-
- [Cloud services](#cloud-serv)
-
### Device update
-
To help protect mobile devices and their data, you must keep those devices updated. Windows Update automatically installs updates and upgrades when they become available.
-
The device update features described in this section are available only in [Windows 10 Mobile Enterprise](#mobile-edition). You can use your MDM system to postpone system upgrades when you activate an Enterprise license on managed Windows 10 Mobile devices and control how updates and upgrades are applied. For example, you can disable updates altogether, defer updates and upgrades, and schedule the day and time to install updates, as you would with Windows Server Update Services (WSUS) on Windows 10 desktops running the [Current Branch for Business](introduction-to-windows-10-servicing.md). Table 20 lists the Windows 10 Mobile Enterprise settings that you can use to configure updates and upgrades.
-
Table 20. Windows 10 Mobile Enterprise update management settings
-
@@ -1204,13 +966,9 @@ Table 20. Windows 10 Mobile Enterprise update management settings
-
-
In addition to configuring how Windows 10 Mobile Enterprise obtains updates, you can manage individual Windows 10 Mobile updates. Table 21 provides information about approved updates to help you control the rollout of new updates to Windows 10 Mobile Enterprise devices.
-
Table 21. Windows 10 Mobile Enterprise approved update information
-
@@ -1266,47 +1024,26 @@ Table 21. Windows 10 Mobile Enterprise approved update information
-
-
### Device compliance monitoring
-
You can use your MDM system to monitor compliance. Windows 10 Mobile provides audit information to track issues or perform remedial actions. This information helps you ensure that devices are configured to comply with organizational standards.
-
You can also assess the health of devices that run Windows 10 Mobile and take enterprise policy actions. The process that the health attestation feature in Windows 10 Mobile uses is as follows:
-
1. The health attestation client collects data used to verify device health.
-
2. The client forwards the data to the Health Attestation Service (HAS).
-
3. The HAS generates a Health Attestation Certificate.
-
4. The client forwards the Health Attestation Certificate and related information to the MDM system for verification.
-
For more information about health attestation in Windows 10 Mobile, see the [Windows 10 Mobile security guide](../keep-secure/windows-10-mobile-security-guide.md).
-
Depending on the results of the health state validation, an MDM system can take one of the following actions:
-
- Allow the device to access resources.
-
- Allow the device to access resources but identify the device for further investigation.
-
- Prevent the device from accessing resources.
-
Table 21 lists data points that the HAS collects and evaluates from devices that run Windows 10 Mobile to determine the action to perform. For most of these data points, the MDM system can take one of the following actions:
-
- Disallow all access.
-
- Disallow access to high-business-impact assets.
-
- Allow conditional access based on other data points that are present at evaluation time—for example, other attributes on the health certificate or a device’s past activities and trust history.
-
- Take one of the previous actions, and also place the device on a watch list to monitor it more closely for potential risks.
-
- Take corrective action, such as informing IT administrators to contact the owner and investigate the issue.
-
Table 21. Windows 10 Mobile HAS data points
-
| Data point | Description |
|----------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Attestation Identity Key (AIK) present | Indicates that an AIK is present (in other words, the device can be trusted more than a device without an AIK). |
@@ -1323,17 +1060,11 @@ Table 21. Windows 10 Mobile HAS data points
| Code integrity version | Specifies the version of code that is performing integrity checks during the boot sequence. The HAS can check this version to determine whether the most current version of code is running, which is more secure (trusted). |
| Secure Boot Configuration Policy (SBCP) present | Whether the hash of the custom SBCP is present. A device with an SBCP hash present is more trustworthy than a device without an SBCP hash. |
| Boot cycle whitelist | The view of the host platform between boot cycles as defined by the manufacturer compared to a published whitelist. A device that complies with the whitelist is more trustworthy (secure) than a device that is noncompliant. |
-
-
### Device inventory
-
Device inventory helps organizations better manage devices because it provides in-depth information about those devices. MDM systems collect inventory information remotely, and you can use the system’s reporting capabilities to analyze device resources and information. With this information, you can determine the current hardware and software resources of the device (for example, installed updates).
-
Table 22 lists examples of the Windows 10 Mobile software and hardware information that a device inventory provides. In addition to this information, the MDM system can read any of the configuration settings described in this guide.
-
Table 22. Windows 10 Mobile software and hardware inventory examples
-
| Setting | Description |
|----------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Installed enterprise apps | List of the enterprise apps installed on the device |
@@ -1354,116 +1085,63 @@ Table 22. Windows 10 Mobile software and hardware inventory examples
| Wi-Fi DNS suffix and subnet mask | DNS suffix and IP subnet mask assigned to the Wi-Fi adapter in the device |
| Secure Boot state | Indicates whether Secure Boot is enabled |
| Enterprise encryption policy compliance | Indicates whether the device is encrypted |
-
-
### Remote assistance
-
The remote assistance features in Windows 10 Mobile help resolve issues that users might encounter even when the help desk does not have physical access to the device. These features include:
-
- **Remote lock.** Support personnel can remotely lock a device. This ability can help when a user loses his or her mobile device and can retrieve it but not immediately (for example, leaving the device at a customer site).
-
- **Remote PIN reset.** Support personnel can remotely reset the PIN, which helps when users forget their PIN and are unable to access their device. No corporate or user data is lost, and users are able to gain access to their devices quickly.
-
- **Remote ring.** Support personnel can remotely make devices ring. This ability can help users locate misplaced devices and, in conjunction with the Remote Lock feature, help ensure that unauthorized users are unable to access the device if they find it.
-
- **Remote find.** Support personnel can remotely locate a device on a map, which helps identify the geographic location of the device. To configure Windows 10 Mobile remote find, use the settings in Table 23. The remote find feature returns the most current latitude, longitude, and altitude of the device.
-
These remote management features help organizations reduce the IT effort required to manage devices. They also help users quickly regain use of their device should they misplace it or forget the device password.
-
Table 23. Windows 10 Mobile remote find settings
-
| Setting | Description |
|---------------------------|---------------------------------------------------------------------------------------------------------------------------------|
| Desired location accuracy | The desired accuracy as a radius value in meters; has a value between 1 and 1,000 meters |
| Maximum remote find | Maximum length of time in minutes that the server will accept a successful remote find; has a value between 0 and 1,000 minutes |
| Remote find timeout | The number of seconds devices should wait for a remote find to finish; has a value between 0 and 1,800 seconds |
-
-
### Cloud services
-
On mobile devices that run Windows 10 Mobile, users can easily connect to apps and data. As a result, they frequently connect to cloud services that provide user notifications and collect telemetry (usage data). Windows 10 Mobile enables organizations to manage how devices consume these cloud services.
-
**Manage push notifications**
-
The Windows Push Notification Services enable software developers to send toast, tile, badge, and raw updates from their cloud services. It provides a mechanism to deliver updates to users in a power-efficient and dependable way.
-
Push notifications can affect battery life, however, so the battery saver in Windows 10 Mobile limits background activity on the devices to extend battery life. Users can configure battery saver to turn on automatically when the battery drops below a set threshold. When battery saver is on, Windows 10 Mobile disables the receipt of push notifications to save energy.
-
There is an exception to this behavior, however. In Windows 10 Mobile, the **Always allowed** battery saver settings (found in the Settings app) allow apps to receive push notifications even when battery saver is on. Users can manually configure this list, or you can use the MDM system to configure it—that is, you can use the battery saver settings URI scheme in Windows 10 Mobile (**ms-settings:batterysaver-settings**) to configure these settings.
-
For more information about push notifications, see [Windows Push Notification Services (WNS) overview](http://go.microsoft.com/fwlink/p/?LinkId=734060).
-
**Manage telemetry**
-
As people use Windows 10 Mobile, it can collect performance and usage telemetry that helps Microsoft identify and troubleshoot problems as well as improve its products and services. Microsoft recommends that you select **Full** for this setting.
-
Microsoft employees, contractors, vendors, and partners might have access to relevant portions of the information that Windows 10 Mobile collects, but they are permitted to use the information only to repair or improve Microsoft products and services or third-party software and hardware designed for use with Microsoft products and services.
-
You can control the level of data that MDM systems collect. Table 24 lists the data levels that Windows 10 Mobile collects and provides a brief description of each. To configure devices, specify one of these levels in the **Allow Telemetry** setting.
-
Table 24. Windows 10 Mobile data collection levels
-
| Level of data | Description |
|---------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Security | Collects only the information required to keep Windows 10 Mobile enterprise-grade secure, including information about telemetry client settings, the Malicious Software Removal Tool, and Windows Defender. This level is available only on Windows 10 Enterprise, Windows 10 Education, and Windows 10 IoT Core. For Windows 10 Mobile, this setting disables Windows 10 Mobile telemetry. |
| Basic | Provides only the data vital to the operation of Windows 10 Mobile. This data level helps keep Windows 10 Mobile and apps running properly by letting Microsoft know the device’s capabilities, what’s installed, and whether Windows is operating correctly. This option also turns on basic error reporting back to Microsoft. By selecting this option, you allow Microsoft to provide updates through Windows Update, including malicious software protection through the Malicious Software Removal Tool. |
| Enhanced | Includes all Basic data plus data about how users use Windows 10 Mobile, such as how frequently or how long they use certain features or apps and which apps they use most often. This option also lets operating system collect enhanced diagnostic information, such as the memory state of a device when a system or app crash occurs, and measure reliability of devices, the operating system, and apps. |
| Full | Includes all Basic and Enhanced data and also turns on advanced diagnostic features that collect additional data from devices, such as system files or memory snapshots, which may unintentionally include parts of documents user are working on when a problem occurred. This information helps Microsoft further troubleshoot and fix problems. If an error report contains personal data, Microsoft does not use that information to identify, contact, or target advertising to users. |
-
-
## Device retirement
-
-
Device retirement (unenrollment) is the last phase of the device life cycle. Historically, mobile device retirement has been a complex and difficult process for organizations. When the organization no longer needs devices, it must remove (wipe) corporate data from them. BYOD scenarios make retirement even more complex because users expect their personal apps and data to remain untouched. Therefore, organizations must remove their data without affecting users’ data.
-
You can remotely remove all corporate data from devices that run Windows 10 Mobile without affecting existing user data (partial or enterprise wipe). The help desk or the devices’ users can initiate device retirement. When retirement is complete, Windows 10 Mobile returns the devices to a consumer state, as they were before enrollment. The following list summarizes the corporate data removed from a device when it’s retired:
-
- Email accounts
-
- Enterprise-issued certificates
-
- Network profiles
-
- Enterprise-deployed apps
-
- Any data associated with the enterprise-deployed apps
-
**Note**
All these features are in addition to the device’s software and hardware factory reset features, which users can use to restore devices to their factory configuration.
-
-
To specify whether users can delete the workplace account in Control Panel and unenroll from the MDM system, enable the **Allow Manual MDM Unenrollment** setting. Table 25 lists additional Windows 10 remote wipe settings that you can use the MDM system to configure.
-
Table 25. Windows 10 Mobile remote wipe settings
-
| Setting | Description |
|-------------------------------|----------------------------------------------------------------------------------------------------------------------|
| Wipe | Specifies that a remote wipe of the device should be performed |
| Allow manual MDM unenrollment | Whether users are allowed to delete the workplace account (in other words, unenroll the device from the MDM system) |
| Allow user to reset phone | Whether users are allowed to use Control Panel or hardware key combinations to return the device to factory defaults |
-
-
## Related topics
-
-
[Mobile device management](http://go.microsoft.com/fwlink/p/?LinkId=734050)
-
[Enterprise Mobility Suite](http://go.microsoft.com/fwlink/p/?LinkId=723984)
-
[Overview of Mobile Device Management for Office 365](http://go.microsoft.com/fwlink/p/?LinkId=734052)
-
[Windows Store for Business](http://go.microsoft.com/fwlink/p/?LinkId=722910)
-
-
-
-
-
-
-
diff --git a/windows/manage/windows-10-start-layout-options-and-policies.md b/windows/manage/windows-10-start-layout-options-and-policies.md
index 826c149308..7a55cfbd9b 100644
--- a/windows/manage/windows-10-start-layout-options-and-policies.md
+++ b/windows/manage/windows-10-start-layout-options-and-policies.md
@@ -16,7 +16,7 @@ author: jdeckerMS
- Windows 10
-> **Looking for consumer information?** See [Customize the Start menu](http://go.microsoft.com/fwlink/p/?LinkId=623630) and topic-to-be-added-for-taskbars
+> **Looking for consumer information?** See [Customize the Start menu](http://windows.microsoft.com/en-us/windows-10/getstarted-see-whats-on-the-menu) and topic-to-be-added-for-taskbars
Organizations might want to deploy a customized Start and taskbar configuration to devices running Windows 10 Enterprise or Windows 10 Education. A standard, customized Start layout can be useful on devices that are common to multiple users and devices that are locked down for specialized purposes. Configuring the taskbar allows the organization to pin useful apps for their employees and to remove apps that are pinned by default.
@@ -127,7 +127,7 @@ There are three categories of apps that might be pinned to a taskbar:
**Note**
The earlier method of using [TaskbarLinks](http://go.microsoft.com/fwlink/p/?LinkId=761230) in an unattended Windows setup file is deprecated in Windows 10, version 1607.
-The following example shows how apps will be pinned - Windows default apps to the left (blue), apps pinned by the user in the center (orange), and apps that you pin using XML to the right (green).
+The following example shows how apps will be pinned - Windows default apps to the left (blue circle), apps pinned by the user in the center (orange triangle), and apps that you pin using XML to the right (green square).
> **Note** In operating systems configured to use a right-to-left language, the taskbar order will be reversed.
diff --git a/windows/manage/working-with-line-of-business-apps.md b/windows/manage/working-with-line-of-business-apps.md
index a8a36b3268..2700a1f83a 100644
--- a/windows/manage/working-with-line-of-business-apps.md
+++ b/windows/manage/working-with-line-of-business-apps.md
@@ -78,7 +78,8 @@ After an app is published and available in the Store, ISVs publish an updated ve
5. Click **Save** to save your changes and start the app submission process.
-For more information, see [Organizational licensing options]( http://go.microsoft.com/fwlink/p/?LinkId=708615) and [Distributing LOB apps to enterprises](http://go.microsoft.com/fwlink/p/?LinkId=627543).
+For more information, see [Organizational licensing options]( http://go.microsoft.com/fwlink/p/?LinkId=708615) and [Distributing LOB apps to enterprises](http://go.microsoft.com/fwlink/p/?LinkId=627543).
+**Note** In order to get the LOB app, the organization must be located in a [supported market](https://technet.microsoft.com/en-us/itpro/windows/whats-new/windows-store-for-business-overview#supported-markets), and you must not have excluded that market when submitting your app.
### Add app to inventory (admin)
diff --git a/windows/plan/chromebook-migration-guide.md b/windows/plan/chromebook-migration-guide.md
index 50915dc54d..5f6f426691 100644
--- a/windows/plan/chromebook-migration-guide.md
+++ b/windows/plan/chromebook-migration-guide.md
@@ -2,57 +2,48 @@
title: Chromebook migration guide (Windows 10)
description: In this guide you will learn how to migrate a Google Chromebook-based learning environment to a Windows 10-based learning environment.
ms.assetid: 7A1FA48A-C44A-4F59-B895-86D4D77F8BEA
-keywords: ["migrate", "automate", "device"]
+keywords: migrate, automate, device
ms.prod: W10
ms.mktglfcycl: plan
ms.sitesec: library
+ms.pagetype: edu; devices
author: craigash
----
+---
# Chromebook migration guide
-
**Applies to**
-
- Windows 10
In this guide you will learn how to migrate a Google Chromebook-based learning environment to a Windows 10-based learning environment. You will learn how to perform the necessary planning steps, including Windows device deployment, migration of user and device settings, app migration or replacement, and cloud storage migration. You will then learn the best method to perform the migration by using automated deployment and migration tools.
## Plan Chromebook migration
-
Before you begin to migrate Chromebook devices, plan your migration. As with most projects, there can be an urge to immediately start doing before planning. When you plan your Chromebook migration before you perform the migration, you can save countless hours of frustration and mistakes during the migration process.
In the planning portion of this guide, you will identify all the decisions that you need to make and how to make each decision. At the end of the planning section, you will have a list of information you need to collect and what you need to do with the information. You will be ready to perform your Chromebook migration.
## Plan for app migration or replacement
-
App migration or replacement is an essential part of your Chromebook migration. In this section you will plan how you will migrate or replace Chromebook (Chrome OS) apps that are currently in use with the same or equivalent Windows apps. At the end of this section, you will have a list of the active Chrome OS apps and the Windows app counterparts.
**Identify the apps currently in use on Chromebook devices**
Before you can do any analysis or make decisions about which apps to migrate or replace, you need to identify which apps are currently in use on the Chromebook devices. You will create a list of apps that are currently in use (also called an app portfolio).
-**Note**
-The majority of Chromebook apps are web apps. For these apps you need to first perform Microsoft Edge compatibility testing and then publish the web app URL to the Windows users. For more information, see the [Perform app compatibility testing for web apps](#perform-testing-webapps) section.
+> **Note** The majority of Chromebook apps are web apps. For these apps you need to first perform Microsoft Edge compatibility testing and then publish the web app URL to the Windows users. For more information, see the [Perform app compatibility testing for web apps](#perform-testing-webapps) section.
You can divide the apps into the following categories:
- **Apps installed and managed by the institution.** These apps are typically managed in the Apps section in the Google Admin Console. You can record the list of these apps in your app portfolio.
-
- **Apps installed by faculty or students.** Faculty or students might have installed these apps as a part of a classroom curriculum. Obtain the list of these apps from faculty or students. Ensure you only record apps that are legitimately used as a part of classroom curriculum (and not for personal entertainment or use).
Record the following information about each app in your app portfolio:
- App name
-
- App type (such as offline app, online app, web app, and so on)
-
- App publisher or developer
-
- App version currently in use
-
- App priority (how necessary is the app to the day-to-day process of the institution or a classroom? Rank as high, medium, or low)
Throughout the entire app migration or replacement process, focus on the higher priority apps. Focus on lower priority apps only after you have determined what you will do with the higher priority apps.
@@ -74,9 +65,7 @@ Table 1. Google App replacements
| Google Hangouts | Microsoft Skype for Business |
| Chrome | Microsoft Edge |
| Google Drive | Microsoft OneDrive for Business |
-
-
It may be that you will decide to replace Google Apps after you deploy Windows devices. For more information on making this decision, see the [Select cloud services migration strategy](#select-cs-migrationstrat) section of this guide.
**Find the same or similar apps in the Windows Store**
@@ -97,14 +86,13 @@ Ensure that you test these web apps in Microsoft Edge. Record the level of compa
## Plan for migration of user and device settings
-
Some institutions have configured the Chromebook devices to make the devices easier to use by using the Google Chrome Admin Console. You have also probably configured the Chromebook devices to help ensure the user data access and ensure that the devices themselves are secure by using the Google Chrome Admin Console.
However, in addition to your centralized configuration in the Google Admin Console, Chromebook users have probably customized their device. In some instances, users may have changed the web content that is displayed when the Chrome browser starts. Or they may have bookmarked websites for future reference. Or users may have installed apps for use in the classroom.
In this section, you will identify the user and device configuration settings for your Chromebook users and devices. Then you will prioritize these settings to focus on the configuration settings that are essential to your educational institution.
-
-At the end of this section, you should have a list of Chromebook user and device settings that you want to migrate to Windows, as well as a level of priority for each setting. You may discover at the end of this section that you have few or no higher priority settings to be migrated. If this is the case, you can skip the [Perform migration of user and device settings](#migrate-user-device-settings) section of this guide.
+At the end of this section, you should have a list of Chromebook user and device settings that you want to migrate to Windows, as well as a level of priority for each setting. You may discover at the end of this section that you have few or no higher priority settings to be migrated. If this is the
+case, you can skip the [Perform migration of user and device settings](#migrate-user-device-settings) section of this guide.
**Identify Google Admin Console settings to migrate**
@@ -164,9 +152,7 @@ Table 2. Settings in the Device Management node in the Google Admin Console
-
-
Table 3 lists the settings in the Security node in the Google Admin Console. Review the settings and determine which settings you will migrate to Windows.
Table 3. Settings in the Security node in the Google Admin Console
@@ -206,9 +192,7 @@ Table 3. Settings in the Security node in the Google Admin Console
-
-
**Identify locally-configured settings to migrate**
In addition to the settings configured in the Google Admin Console, users may have locally configured their devices based on their own personal preferences (as shown in Figure 2). Table 4 lists the Chromebook user and device settings that you can locally configure. Review the settings and determine which settings you will migrate to Windows. Some of the settings listed in Table 4 can only be seen when you click the **Show advanced settings** link (as shown in Figure 2).
@@ -219,8 +203,8 @@ Figure 2. Locally-configured settings on Chromebook
Table 4. Locally-configured settings
-| Section | Settings |
-|------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Section | Settings |
+| - | - |
| Internet connections | These settings configure the Internet connection for the devices, such as Wi-Fi and VPN connections. Record the network connection currently in use and configure the Windows device to use the same network connection settings. |
| Appearances | These settings affect the appearance of the desktop. Record the wallpaper image file that is used. Migrate the image file to the Windows device and configure as the user’s wallpaper to maintain similar user experience. |
| Search | These settings configure which search engine is used to search for content. Record this setting so that you can use as the search engine on the Windows device. |
@@ -239,24 +223,18 @@ Table 4. Locally-configured settings
| Accessibility | These settings configure the Chromebook ease of use (such as display of large mouse cursor, use of high contrast mode, enablement of the screen magnifier, and so on). Record these settings and configure the Windows device with similar settings. |
| Powerwash | This action removes all user accounts and resets the Chromebook device back to factory settings. You don’t have to migrate any settings in this section. |
| Reset settings | This action retains all user accounts, but restores all settings back to their default values. You don’t have to migrate any settings in this section. |
-
-
Determine how many users have similar settings and then consider managing those settings centrally. For example, a large number of users may have many of the same Chrome web browser settings. You can centrally manage these settings in Windows after migration.
-
Also, as a part of this planning process, consider settings that may not be currently managed centrally, but should be managed centrally. Record the settings that are currently being locally managed, but you want to manage centrally after the migration.
**Prioritize settings to migrate**
After you have collected all the Chromebook user, app, and device settings that you want to migrate, you need to prioritize each setting. Evaluate each setting and assign a priority to the setting based on the levels of high, medium, and low.
-
Assign the setting-migration priority based on how critical the setting is to the faculty performing their day-to-day tasks and how the setting affects the curriculum in the classrooms. Focus on the migration of higher priority settings and put less effort into the migration of lower priority settings. There may be some settings that are not necessary at all and can be dropped from your list of settings entirely. Record the setting priority in the list of settings you plan to migrate.
## Plan for email migration
-
Many of your users may be using Google Apps Gmail to manage their email, calendars, and contacts. You need to create the list of users you will migrate and the best time to perform the migration.
-
Office 365 supports automated migration from Google Apps Gmail to Office 365. For more information, see [Migrate Google Apps mailboxes to Office 365](http://go.microsoft.com/fwlink/p/?LinkId=690252).
**Identify the list of user mailboxes to migrate**
@@ -274,7 +252,6 @@ In addition to Chromebook devices, users may have companion devices (smartphones
After you have identified each companion device, verify the settings for the device that are used to access Office 365. You only need to test one type of each companion device. For example, if users use Android phones to access Google Apps Gmail mailboxes, configure the device to access Office 365 and then record those settings. You can publish those settings on a website or to your helpdesk staff so that users will know how to access their Office 365 mailbox.
In most instances, users will only need to provide in their Office 365 email account and password. However, you should verify this on each type of companion device. For more information about how to configure a companion device to work with Office 365, see [Compare how different mobile devices work with Office 365](http://go.microsoft.com/fwlink/p/?LinkId=690254).
-
**Identify the optimal timing for the migration**
Typically, the best time to perform the migration is between academic years or during semester breaks. Select the time of least activity for your institution. And during that time, the optimal time to perform the migration might be during an evening or over a weekend.
@@ -283,7 +260,6 @@ Ensure that you communicate the time the migration will occur to your users well
## Plan for cloud storage migration
-
Chromebook devices have limited local storage. So, most of your users will store data in cloud storage, such as Google Drive. You will need to plan how to migrate your cloud storage as a part of the Chromebook migration process.
In this section, you will create a list of the existing cloud services, select the Microsoft cloud services that best meet your needs, and then optimize your cloud storage services migration plan.
@@ -291,13 +267,9 @@ In this section, you will create a list of the existing cloud services, select t
**Identify cloud storage services currently in use**
Typically, most Chromebook users use Google Drive for cloud storage services because your educational institution purchased other Google cloud services and Google Drive is a part of those services. However, some users may use cloud storage services from other vendors. For each member of your faculty and staff and for each student, create a list of cloud storage services that includes the following:
-
- Name of the cloud storage service
-
- Cloud storage service vendor
-
- Associated licensing costs or fees
-
- Approximate storage currently in use per user
Use this information as the requirements for your cloud storage services after you migrate to Windows devices. If at the end of this discovery you determine there is no essential data being stored in cloud storage services that requires migration, then you can skip to the [Plan for cloud services migration](#plan-cloud-services) section.
@@ -309,16 +281,13 @@ Now that you know the current cloud storage services configuration, you need to
Consider the following to help optimize your cloud storage services migration plan:
- **Eliminate inactive user storage.** Before you perform the cloud storage services migration, identify cloud storage that is currently allocated to inactive users. Remove this storage from your list of cloud storage to migrate.
-
- **Eliminate or archive inactive files.** Review cloud storage to identify files that are inactive (have not been accessed for some period of time). Eliminate or archive these files so that they do not consume cloud storage.
-
- **Consolidate cloud storage services.** If multiple cloud storage services are in use, reduce the number of cloud storage services and standardize on one cloud storage service. This will help reduce management complexity, support time, and typically will reduce cloud storage costs.
Record your optimization changes in your cloud storage services migration plan.
## Plan for cloud services migration
-
Many of your users may use cloud services on their Chromebook device, such as Google Apps, Google Drive, or Google Apps Gmail. You have planned for these individual cloud services in the [Plan for app migration or replacement](#plan-app-migrate-replace), [Plan for Google Apps Gmail to Office 365 migration](#plan-email-migrate), and [Plan for cloud storage migration](#plan-cloud-storage-migration) sections.
In this section, you will create a combined list of these cloud services and then select the appropriate strategy to migrate these cloud services.
@@ -328,11 +297,8 @@ In this section, you will create a combined list of these cloud services and the
**Identify cloud services currently in use**
You have already identified the individual cloud services that are currently in use in your educational institution in the [Plan for app migration or replacement](#plan-app-migrate-replace), [Plan for Google Apps Gmail to Office 365 migration](#plan-email-migrate), and [Plan for cloud storage migration](#plan-cloud-storage-migration) sections. Create a unified list of these cloud services and record the following about each service:
-
- Cloud service name
-
- Cloud service provider
-
- Number of users that use the cloud service
**Select cloud services to migrate**
@@ -340,21 +306,15 @@ You have already identified the individual cloud services that are currently in
One of the first questions you should ask after you identify the cloud services currently in use is, “Why do we need to migrate from these cloud services?” The answer to this question largely comes down to finances and features.
Here is a list of reasons that describe why you might want to migrate from an existing cloud service to Microsoft cloud services:
-
- **Better integration with Office 365.** If your long-term strategy is to migrate to Office 365 apps (such as Word 2016 or Excel 2016) then a migration to Microsoft cloud services will provide better integration with these apps. The use of existing cloud services may not be as intuitive for users. For example, Office 365 apps will integrate better with OneDrive for Business compared to Google Drive.
-
- **Online apps offer better document compatibility.** Microsoft Office online apps (such as Word Online and Excel Online) provide the highest level of compatibility with Microsoft Office documents. The Office online apps allow you to open and edit documents directly from SharePoint or OneDrive for Business. Users can access the Office online app from any device with Internet connectivity.
-
- **Reduce licensing costs.** If you pay for Office 365 licenses, then Office 365 apps and cloud storage are included in those licenses. Although you could keep existing cloud services, you probably would pay more to keep those services.
-
- **Improve storage capacity and cross-platform features.** Microsoft cloud services provide competitive storage capacity and provide more Windows-centric features than other cloud services providers. While the Microsoft cloud services user experience is highly optimized for Windows devices, Microsoft cloud services are also highly optimized for companion devices (such as iOS or Android devices).
-
Review the list of existing cloud services that you created in the [Identify cloud services currently in use](#identify-cloud-services-inuse) section and identify the cloud services that you want to migrate to Microsoft cloud services. If you determine at the end of this task that there are no cloud services to be migrated, then skip to the [Plan for Windows device deployment](#plan-windevice-deploy) section. Also, skip the [Perform cloud services migration](#perform-cloud-services-migration) section later in this guide.
**Prioritize cloud services**
After you have created your aggregated list of cloud services currently in use by Chromebook users, prioritize each cloud service. Evaluate each cloud service and assign a priority based on the levels of high, medium, and low.
-
Assign the priority based on how critical the cloud service is to the faculty and staff performing their day-to-day tasks and how the cloud service affects the curriculum in the classrooms. Also, make cloud services that are causing pain for the users a higher priority. For example, if users experience outages with a specific cloud service, then make migration of that cloud service a higher priority.
Focus on the migration of higher priority cloud services first and put less effort into the migration of lower priority cloud services. There may be some cloud services that are unnecessary and you can remove them from your list of cloud services to migrate entirely. Record the cloud service migration priority in the list of cloud services you plan to migrate.
@@ -368,20 +328,14 @@ When you deploy the Windows devices, should you migrate the faculty, staff, and
Consider the following when you create your cloud services migration strategy:
- **Introduce small changes.** The move from Chrome OS to Windows will be simple for most users as most will have exposure to Windows from home, friends, or family. However, users may not be as familiar with the apps or cloud services. Consider the move to Windows first, and then make other changes as time progresses.
-
- **Start off by using existing apps and cloud services.** Immediately after the migration to Windows devices, you may want to consider running the existing apps and cloud services (such Google Apps, Google Apps Gmail, and Google Drive). This gives users a familiar method to perform their day-to-day tasks.
-
- **Resolve pain points.** If some existing apps or cloud services cause problems, you may want to migrate them sooner rather than later. In most instances, users will be happy to go through the learning curve of a new app or cloud service if it is more reliable or intuitive for them to use.
-
- **Migrate classrooms or users with common curriculum.** Migrate to Windows devices for an entire classroom or for multiple classrooms that share common curriculum. You must ensure that the necessary apps and cloud services are available for the curriculum prior to the migration of one or more classrooms.
-
- **Migrate when the fewest number of active users are affected.** Migrate your cloud services at the end of an academic year or end of a semester. This will ensure you have minimal impact on faculty, staff, and students. Also, a migration during this time will minimize the learning curve for users as they are probably dealing with new curriculum for the next semester. Also, you may not need to migrate student apps and data because many educational institutions do not preserve data between semesters or academic years.
-
- **Overlap existing and new cloud services.** For faculty and staff, consider overlapping the existing and new cloud services (having both services available) for one business cycle (end of semester or academic year) after migration. This allows you to easily recover any data that might not have migrated successfully from the existing cloud services. At a minimum, overlap the user of existing and new cloud services until the user can verify the migration. Of course, the tradeoff for using this strategy is the cost of the existing cloud services. However, depending on when license renewal occurs, the cost may be minimal.
## Plan for Windows device deployment
-
You need to plan for Windows device deployment to help ensure that the devices are successfully installed and configured to replace the Chromebook devices. Even if the vendor that provides the devices pre-loads Windows 10 on them, you still will need to perform other tasks.
In this section you will select a Windows device deployment strategy; plan for Active Directory Domain Services (AD DS) and Azure AD services; plan for device, user, and app management; and plan for any necessary network infrastructure remediation.
@@ -395,13 +349,9 @@ What decisions need to be made about Windows device deployment? You just put the
For each classroom that has Chromebook devices, select a combination of the following device deployment strategies:
- **Deploy one classroom at a time.** In most cases you will want to perform your deployment in batches of devices and a classroom is an excellent way to batch devices. You can treat each classroom as a unit and check each classroom off your list after you have deployed the devices.
-
- **Deploy based on curriculum.** Deploy the Windows devices after you have confirmed that the curriculum is ready for the Windows devices. If you deploy Windows devices without the curriculum installed and tested, you could significantly reduce the ability for students and teachers to perform effectively in the classroom. Also, deployment based on curriculum has the advantage of letting you move from classroom to classroom quickly if multiple classrooms use the same curriculum.
-
- **Deploy side-by-side.** In some instances you may need to have both the Chromebook and Windows devices in one or more classrooms. You can use this strategy if some of the curriculum only works on Chromebook and other parts of the curriculum works on Windows devices. This is a good method to help prevent delays in Windows device deployment, while ensuring that students and teachers can make optimal use of technology in their curriculum.
-
- **Deploy after apps and cloud services migration.** If you deploy a Windows device without the necessary apps and cloud services to support the curriculum, this provides only a portion of your complete solution. Ensure that the apps and cloud services are tested, provisioned, and ready for use prior to the deployment of Windows devices.
-
- **Deploy after the migration of user and device settings.** Ensure that you have identified the user and device settings that you plan to migrate and that those settings are ready to be applied to the new Windows devices. For example, you would want to create Group Policy Objects (GPOs) to apply the user and device settings to Windows devices.
If you ensure that Windows devices closely mirror the Chromebook device configuration, you will ease user learning curve and create a sense of familiarity. Also, when you have the settings ready to be applied to the devices, it helps ensure you will deploy your new Windows devices in a secure configuration.
@@ -415,7 +365,6 @@ Record the combination of Windows device deployment strategies that you selected
The next decision you will need to make concerns AD DS and Azure AD services. You can run AD DS on-premises, in the cloud by using Azure AD, or a combination of both (hybrid). The decision about which of these options is best is closely tied to how you will manage your users, apps, and devices and if you will use Office 365 and other Azure-based cloud services.
In the hybrid configuration, your on-premises AD DS user and group objects are synchronized with Azure AD (including passwords). The synchronization happens both directions so that changes are made in both your on-premises AD DS and Azure AD.
-
Table 5 is a decision matrix that helps you decide if you can use only on-premises AD DS, only Azure AD, or a combination of both (hybrid). If the requirements you select from the table require on-premises AD DS and Azure AD, then you should select hybrid. For example, if you plan to use Office 365 and use Group Policy for management, then you would select hybrid. However, if you plan to use Office 365 and use Intune for management, then you would select only Azure AD.
Table 5. Select on-premises AD DS, Azure AD, or hybrid
@@ -474,17 +423,13 @@ Table 5. Select on-premises AD DS, Azure AD, or hybrid
-
-
###
**Plan device, user, and app management**
You may ask the question, “Why plan for device, user, and app management before you deploy the device?” The answer is that you will only deploy the device once, but you will manage the device throughout the remainder of the device's lifecycle.
-
Also, planning management before deployment is essential to being ready to support the devices as you deploy them. You want to have your management processes and technology in place when the first teachers, facility, or students start using their new Windows device.
-
Table 6 is a decision matrix that lists the device, user, and app management products and technologies and the features supported by each product or technology. The primary device, user, and app management products and technologies include Group Policy, System Center Configuration Manager, Intune, and the Microsoft Deployment Toolkit (MDT). Use this decision matrix to help you select the right combination of products and technologies for your plan.
Table 6. Device, user, and app management products and technologies
@@ -594,9 +539,7 @@ Table 6. Device, user, and app management products and technologies
-
-
You can use Configuration Manager and Intune in conjunction with each other to provide features from both products and technologies. In some instances you may need only one of these products or technologies. In other instances, you may need two or more to meet the device, user, and app management needs for your institution.
Record the device, user, and app management products and technologies that you selected.
@@ -628,9 +571,7 @@ Examine each of the following network infrastructure technologies and services a
For more information that compares Internet bandwidth consumption for Chromebook and Windows devices, see the following resources:
- [Chromebook vs. Windows Notebook Network Traffic Analysis](http://go.microsoft.com/fwlink/p/?LinkId=690255)
-
- [Hidden Cost of Chromebook Deployments](http://go.microsoft.com/fwlink/p/?LinkId=690256)
-
- [Microsoft Windows 8.1 Notebook vs. Chromebooks for Education](http://go.microsoft.com/fwlink/p/?LinkId=690257)
- **Power.** Although not specifically a network infrastructure, you need to ensure your classrooms have adequate power. Chromebook and Windows devices should consume similar amounts of power. This means that your existing power outlets should support the same number of Windows devices.
@@ -641,7 +582,6 @@ At the end of this process, you may determine that no network infrastructure rem
## Perform Chromebook migration
-
Thus far, planning has been the primary focus. Believe it or not most of the work is now done. The rest of the Chromebook migration is just the implementation of the plan you have created.
In this section you will perform the necessary steps for the Chromebook device migration. You will perform the migration based on the planning decision that you made in the [Plan Chromebook migration](#plan-migration) section earlier in this guide.
@@ -650,7 +590,6 @@ You must perform some of the steps in this section in a specific sequence. Each
## Perform network infrastructure remediation
-
The first migration task is to perform any network infrastructure remediation. In the [Plan network infrastructure remediation](#plan-network-infra-remediation) section, you determined the network infrastructure remediation (if any) that you needed to perform.
It is important that you perform any network infrastructure remediation first because the remaining migration steps are dependent on the network infrastructure. Table 7 lists the Microsoft network infrastructure products and technologies and deployment resources for each.
@@ -685,16 +624,12 @@ Table 7. Network infrastructure products and technologies and deployment resourc
-
-
If you use network infrastructure products and technologies from other vendors, refer to the vendor documentation on how to perform the necessary remediation. If you determined that no remediation is necessary, you can skip this section.
## Perform AD DS and Azure AD services deployment or remediation
-
It is important that you perform AD DS and Azure AD services deployment or remediation right after you finish network infrastructure remediation. Many of the remaining migration steps are dependent on you having your identity system (AD DS or Azure AD) in place and up to necessary expectations.
-
In the [Plan for Active Directory services](#plan-adservices) section, you determined the AD DS and/or Azure AD deployment or remediation (if any) that needed to be performed. Table 8 list AD DS, Azure AD, and the deployment resources for both. Use the resources in this table to deploy or remediate on-premises AD DS, Azure AD, or both.
Table 8. AD DS, Azure AD and deployment resources
@@ -728,14 +663,10 @@ Table 8. AD DS, Azure AD and deployment resources
-
-
If you decided not to migrate to AD DS or Azure AD as a part of the migration, or if you determined that no remediation is necessary, you can skip this section. If you use identity products and technologies from another vendor, refer to the vendor documentation on how to perform the necessary steps.
-
## Prepare device, user, and app management systems
-
In the [Plan device, user, and app management](#plan-userdevapp-manage) section of this guide, you selected the products and technologies that you will use to manage devices, users, and apps on Windows devices. You need to prepare your management systems prior to Windows 10 device deployment. You will use these management systems to manage the user and device settings that you selected to migrate in the [Plan for migration of user and device settings](#plan-migrate-user-device-settings) section. You need to prepare these systems prior to the migration of user and device settings.
Table 9 lists the Microsoft management systems and the deployment resources for each. Use the resources in this table to prepare (deploy or remediate) these management systems.
@@ -793,14 +724,11 @@ Table 9. Management systems and deployment resources
-
-
If you determined that no new management system or no remediation of existing systems is necessary, you can skip this section. If you use a management system from another vendor, refer to the vendor documentation on how to perform the necessary steps.
## Perform app migration or replacement
-
In the [Plan for app migration or replacement](#plan-app-migrate-replace) section, you identified the apps currently in use on Chromebook devices and selected the Windows apps that will replace the Chromebook apps. You also performed app compatibility testing for web apps to ensure that web apps on the Chromebook devices would run on Microsoft Edge and Internet Explorer.
In this step, you need to configure your management system to deploy the apps to the appropriate Windows users and devices. Table 10 lists the Microsoft management systems and the app deployment resources for each. Use the resources in this table to configure these management systems to deploy the apps that you selected in the [Plan for app migration or replacement](#plan-app-migrate-replace) section of this guide.
@@ -843,70 +771,52 @@ Table 10. Management systems and app deployment resources
-
-
If you determined that no deployment of apps is necessary, you can skip this section. If you use a management system from another vendor, refer to the vendor documentation on how to perform the necessary steps.
## Perform migration of user and device settings
-
In the [Plan for migration of user and device settings](#plan-migrate-user-device-settings) section, you determined the user and device settings that you want to migrate. You selected settings that are configured in the Google Admin Console and locally on the Chromebook device.
Perform the user and device setting migration by using the following steps:
1. From the list of institution-wide settings that you created in the [Plan for migration of user and device settings](#plan-migrate-user-device-settings) section, configure as many as possible in your management system (such as Group Policy, Configuration Manager, or Intune).
-
2. From the list of device-specific settings that you created in the [Plan for migration of user and device settings](#plan-migrate-user-device-settings) section, configure device-specific setting for higher priority settings.
-
3. From the list of user-specific settings that you created in the [Plan for migration of user and device settings](#plan-migrate-user-device-settings) section, configure user-specific setting for higher priority settings.
-
4. Verify that all higher-priority user and device settings have been configured in your management system.
If you do no want to migrate any user or device settings from the Chromebook devices to the Windows devices, you can skip this section.
## Perform email migration
-
In the [Plan for email migration](#plan-email-migrate) section, you identified the user mailboxes to migrate, identified the companion devices that access Google Apps Gmail, and identified the optimal timing for migration. You can perform this migration before or after you deploy the Windows devices.
Office 365 supports automated migration from Google Apps Gmail to Office 365. For more information on how to automate the migration from Google Apps Gmail to Office 365, see [Migrate Google Apps mailboxes to Office 365](http://go.microsoft.com/fwlink/p/?LinkId=690252).
Alternatively, if you want to migrate to Office 365 from:
-
- **On-premises Microsoft Exchange Server.** Use the following resources to migrate to Office 365 from an on-premises Microsoft Exchange Server:
-
- [Cutover Exchange Migration and Single Sign-On](http://go.microsoft.com/fwlink/p/?LinkId=690266)
-
- [Step-By-Step: Migration of Exchange 2003 Server to Office 365](http://go.microsoft.com/fwlink/p/?LinkId=690267)
-
- [Step-By-Step: Migrating from Exchange 2007 to Office 365](http://go.microsoft.com/fwlink/p/?LinkId=690268)
-
- **Another on-premises or cloud-based email service.** Follow the guidance from that vendor.
## Perform cloud storage migration
-
In the [Plan for cloud storage migration](#plan-cloud-storage-migration) section, you identified the cloud storage services currently in use, selected the Microsoft cloud storage services that you will use, and optimized your cloud storage services migration plan. You can perform the cloud storage migration before or after you deploy the Windows devices.
Manually migrate the cloud storage migration by using the following steps:
1. Install both Google Drive app and OneDrive for Business or OneDrive app on a device.
-
2. Sign in as the user in the Google Drive app.
-
3. Sign in as the user in the OneDrive for Business or OneDrive app.
-
4. Copy the data from the Google Drive storage to the OneDrive for Business or OneDrive storage.
-
5. Optionally uninstall the Google Drive app.
There are also a number of software vendors who provide software that helps automate the migration from Google Drive to OneDrive for Business, Office 365 SharePoint, or OneDrive. For more information about these automated migration tools, contact the vendors.
## Perform cloud services migration
-
-In the [Plan for cloud services migration](#plan-cloud-services) section, you identified the cloud services currently in use, selected the cloud services that you want to migrate, prioritized the cloud services to migrate, and then selected the cloud services migration strategy. You can perform the cloud services migration before or after you deploy the Windows devices.
+In the [Plan for cloud services migration](#plan-cloud-services)section, you identified the cloud services currently in use, selected the cloud services that you want to migrate, prioritized the cloud services to migrate, and then selected the cloud services migration strategy. You can perform the cloud services migration before or after you deploy the Windows devices.
Migrate the cloud services that you currently use to the Microsoft cloud services that you selected. For example, you could migrate from a collaboration website to Office 365 SharePoint. Perform the cloud services migration based on the existing cloud services and the Microsoft cloud services that you selected.
@@ -914,47 +824,30 @@ There are also a number of software vendors who provide software that helps auto
## Perform Windows device deployment
-
In the [Select a Windows device deployment strategy](#select-windows-device-deploy) section, you selected how you wanted to deploy Windows 10 devices. The other migration task that you designed in the [Plan for Windows device deployment](#plan-windevice-deploy) section have already been performed. Now it's time to deploy the actual devices.
For example, if you selected to deploy Windows devices by each classroom, start with the first classroom and then proceed through all of the classrooms until you’ve deployed all Windows devices.
-In some instances, you may receive the devices with Windows 10 already deployed, and want to use provisioning packages. In other cases, you may have a custom Windows 10 image that you want to deploy to the devices by using Configuration Manager and/or MDT. For information on how to deploy Windows 10 images to the devices, see the following resources:
+In some instances, you may receive the devices with Windows 10 already deployed, and want to use provisioning packages. In other cases, you may have a custom Windows 10 image that you want to deploy to the devices by using Configuration Manager and/or MDT. For information on how to deploy
+Windows 10 images to the devices, see the following resources:
- [Windows Imaging and Configuration Designer](http://go.microsoft.com/fwlink/p/?LinkId=733911)
-
- [Build and apply a provisioning package](http://go.microsoft.com/fwlink/p/?LinkId=733918)
-
- [MDT documentation in the Microsoft Deployment Toolkit (MDT) 2013](http://go.microsoft.com/fwlink/p/?LinkId=690324)
-
- [Step-By-Step: Installing Windows 8.1 From A USB Key](http://go.microsoft.com/fwlink/p/?LinkId=690265)
-
- [Operating System Deployment in Configuration Manager](http://go.microsoft.com/fwlink/p/?LinkId=733916)
In addition to the Windows 10 image deployment, you may need to perform the following tasks as a part of device deployment:
- Enroll the device with your management system.
-
- Ensure that Windows Defender is enabled and configured to receive updates.
-
- Ensure that Windows Update is enabled and configured to receive updates.
-
- Deploy any apps that you want the user to immediately be able to access when they start the device (such as Word 2016 or Excel 2016).
After you complete these steps, your management system should take over the day-to-day maintenance tasks for the Windows 10 devices. Verify that the user and device settings migrated correctly as you deploy each batch of Windows 10 devices. Continue this process until you deploy all Windows 10 devices.
## Related topics
-
-
-[Try it out: Windows 10 deployment (for education)](http://go.microsoft.com/fwlink/p/?LinkId=623254)
-
-[Try it out: Windows 10 in the classroom](http://go.microsoft.com/fwlink/p/?LinkId=623255)
-
+- [Try it out: Windows 10 deployment (for education)](http://go.microsoft.com/fwlink/p/?LinkId=623254)
+- [Try it out: Windows 10 in the classroom](http://go.microsoft.com/fwlink/p/?LinkId=623255)
-
-
-
-
-
-
diff --git a/windows/plan/deploy-windows-10-in-a-school.md b/windows/plan/deploy-windows-10-in-a-school.md
index 53a866f3b8..f1ba01d1a5 100644
--- a/windows/plan/deploy-windows-10-in-a-school.md
+++ b/windows/plan/deploy-windows-10-in-a-school.md
@@ -49,8 +49,7 @@ This school configuration has the following characteristics:
- You install the Windows Assessment and Deployment Kit (Windows ADK) on the admin device.
- You install the Windows Assessment and Deployment Kit (Windows ADK) on the admin device.
- You install the 64-bit version of the Microsoft Deployment Toolkit (MDT) 2013 Update 2 on the admin device.
-
- **Note** In this guide, all references to MDT refer to the 64-bit version of MDT 2013 Update 2.
+>**Note:** In this guide, all references to MDT refer to the 64-bit version of MDT 2013 Update 2.
- The devices use Azure AD in Office 365 Education for identity management.
- If you have on-premises AD DS, you can [integrate Azure AD with on-premises AD DS](http://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect/).
- Use [Intune](http://technet.microsoft.com/library/jj676587.aspx), [compliance settings in Office 365](https://support.office.com/en-us/article/Manage-mobile-devices-in-Office-365-dd892318-bc44-4eb1-af00-9db5430be3cd?ui=en-US&rs=en-US&ad=US), or [Group Policy](http://technet.microsoft.com/en-us/library/cc725828%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396) in AD DS to manage devices.
@@ -140,7 +139,7 @@ Next, install MDT. MDT uses the Windows ADK to help you manage and perform Windo
You can use MDT to deploy 32-bit or 64-bit versions of Windows 10. Install the 64-bit version of MDT to support deployment of 32-bit and 64-bit operating systems.
-**Note** If you install the 32-bit version of MDT, you can install only 32-bit versions of Windows 10. Ensure that you download and install the 64-bit version of MDT so that you can install 64-bit and 32 bit versions of the operating system.
+>**Note:** If you install the 32-bit version of MDT, you can install only 32-bit versions of Windows 10. Ensure that you download and install the 64-bit version of MDT so that you can install 64-bit and 32 bit versions of the operating system.
For more information about installing MDT on the admin device, see [Installing a New Instance of MDT](https://technet.microsoft.com/en-us/library/dn759415.aspx#InstallingaNewInstanceofMDT).
@@ -225,13 +224,13 @@ You will use the Office 365 Education license plan information you record in Tab
To create a new Office 365 Education subscription for use in the classroom, use your educational institution’s email account. There are no costs to you or to students for signing up for Office 365 Education subscriptions.
-**Note** If you already have an Office 365 Education subscription, you can use that subscription and continue to the next section, [Add domains and subdomains](#add-domains-and-subdomains).
+>**Note:** If you already have an Office 365 Education subscription, you can use that subscription and continue to the next section, [Add domains and subdomains](#add-domains-and-subdomains).
#### To create a new Office 365 subscription
1. In Microsoft Edge or Internet Explorer, type `https://portal.office.com/start?sku=faculty` in the address bar.
- **Note** If you have already used your current sign-in account to create a new Office 365 subscription, you will be prompted to sign in. If you want to create a new Office 365 subscription, start an In-Private Window in one of the following:
+ >**Note** If you have already used your current sign-in account to create a new Office 365 subscription, you will be prompted to sign in. If you want to create a new Office 365 subscription, start an In-Private Window in one of the following:
- Microsoft Edge by opening the Microsoft Edge app, either pressing Ctrl+Shift+P or clicking or tapping **More actions**, and then clicking or tapping **New InPrivate window**.
- Internet Explorer 11 by opening Internet Explorer 11, either pressing Ctrl+Shift+P or clicking or tapping **Settings**, clicking or tapping **Safety**, and then clicking or tapping **InPrivate Browsing**.
@@ -256,7 +255,7 @@ Now that you have created your new Office 365 Education subscription, add the do
To make it easier for faculty and students to join your Office 365 Education subscription (or *tenant*), allow them to automatically sign up to your tenant (*automatic tenant join*). In automatic tenant join, when a faculty member or student signs up for Office 365, Office 365 automatically adds (joins) the user to your Office 365 tenant.
-**Note** By default, automatic tenant join is enabled in Office 365 Education, with the exception of certain areas in Europe, the Middle East, and Africa. These countries require opt-in steps to add new users to existing Office 365 tenants. Check your country requirements to determine the automatic tenant join default configuration. Also, if you use Azure AD Connect, then automatic tenant join is disabled.
+>**Note:** By default, automatic tenant join is enabled in Office 365 Education, with the exception of certain areas in Europe, the Middle East, and Africa. These countries require opt-in steps to add new users to existing Office 365 tenants. Check your country requirements to determine the automatic tenant join default configuration. Also, if you use Azure AD Connect, then automatic tenant join is disabled.
Office 365 uses the domain portion of the user’s email address to know which Office 365 tenant to join. For example, if a faculty member or student provides an email address of user@contoso.edu, then Office 365 automatically performs one of the following tasks:
@@ -265,7 +264,7 @@ Office 365 uses the domain portion of the user’s email address to know which O
You will always want faculty and students to join the Office 365 tenant that you created. Ensure that you perform the steps in the [Create a new Office 365 Education subscription](#create-a-new-office-365-education-subscription) and [Add domains and subdomains](#add-domains-and-subdomains) sections before allowing other faculty and students to join Office 365.
-**Note** You cannot merge multiple tenants, so any faculty or students who create their own tenant will need to abandon their existing tenant and join yours.
+>**Note:** You cannot merge multiple tenants, so any faculty or students who create their own tenant will need to abandon their existing tenant and join yours.
All new Office 365 Education subscriptions have automatic tenant join enabled by default, but you can enable or disable automatic tenant join by using the Windows PowerShell commands in Table 3. For more information about how to run these commands, see [How can I prevent students from joining my existing Office 365 tenant](https://support.office.com/en-us/article/Office-365-Education-Self-Sign-up-Technical-FAQ-7fb1b2f9-94c2-4cbb-b01e-a6eca34261d6?ui=en-US&rs=en-US&ad=US#BKMK_PreventJoins).
@@ -277,13 +276,13 @@ All new Office 365 Education subscriptions have automatic tenant join enabled by
| Enable |`Set-MsolCompanySettings -AllowEmailVerifiedUsers $true`|
| Disable |`Set-MsolCompanySettings -AllowEmailVerifiedUsers $false`|
-**Note** If your institution has AD DS, then disable automatic tenant join. Instead, use Azure AD integration with AD DS to add users to your Office 365 tenant.
+>**Note:** If your institution has AD DS, then disable automatic tenant join. Instead, use Azure AD integration with AD DS to add users to your Office 365 tenant.
### Disable automatic licensing
To reduce your administrative effort, automatically assign Office 365 Education or Office 365 Education Plus licenses to faculty and students when they sign up (automatic licensing). Automatic licensing also enables Office 365 Education or Office 365 Education Plus features that do not require administrative approval.
-**Note** By default, automatic licensing is enabled in Office 365 Education. If you want to use automatic licensing, then skip this section and go to the next section.
+>**Note:** By default, automatic licensing is enabled in Office 365 Education. If you want to use automatic licensing, then skip this section and go to the next section.
Although all new Office 365 Education subscriptions have automatic licensing enabled by default, you can enable or disable it for your Office 365 tenant by using the Windows PowerShell commands in Table 4. For more information about how to run these commands, see [How can I prevent students from joining my existing Office 365 tenant](https://support.office.com/en-us/article/Office-365-Education-Self-Sign-up-Technical-FAQ-7fb1b2f9-94c2-4cbb-b01e-a6eca34261d6?ui=en-US&rs=en-US&ad=US#BKMK_PreventJoins).
@@ -336,7 +335,7 @@ Now that you have an Office 365 subscription, you need to determine how you will
In this method, you have an on-premises AD DS domain. As shown in Figure 4, the Azure AD Connector tool automatically synchronizes AD DS with Azure AD. When you add or change any user accounts in AD DS, the Azure AD Connector tool automatically updates Azure AD.
-**Note** Azure AD Connect also supports synchronization from any Lightweight Directory Access Protocol version 3 (LDAPv3)–compliant directory by using the information provided in [Generic LDAP Connector for FIM 2010 R2 Technical Reference](https://technet.microsoft.com/en-us/library/dn510997.aspx?f=255&MSPPError=-2147217396).
+>**Note:** Azure AD Connect also supports synchronization from any Lightweight Directory Access Protocol version 3 (LDAPv3)–compliant directory by using the information provided in [Generic LDAP Connector for FIM 2010 R2 Technical Reference](https://technet.microsoft.com/en-us/library/dn510997.aspx?f=255&MSPPError=-2147217396).
@@ -365,7 +364,7 @@ In this section, you selected the method for creating user accounts in your Offi
You can integrate your on-premises AD DS domain with Azure AD to provide identity management for your Office 365 tenant. With this integration, you can synchronize the users, security groups, and distribution lists in your AD DS domain with Azure AD with the Azure AD Connect tool. Users will be able to sign in to Office 365 automatically by using their email account and the same password they use to sign in to AD DS.
-**Note** If your institution does not have an on-premises AD DS domain, you can skip this section.
+>**Note:** If your institution does not have an on-premises AD DS domain, you can skip this section.
### Select synchronization model
@@ -426,7 +425,7 @@ In this section, you selected your synchronization model, deployed Azure AD Conn
You can bulk-import user and group accounts into your on-premises AD DS domain. Bulk-importing accounts helps reduce the time and effort needed to create users compared to creating the accounts manually in the Office 365 Admin portal. First, you select the appropriate method for bulk-importing user accounts into AD DS. Next, you create the .csv file that contains the user accounts. Finally, you use the selected method to import the .csv file into AD DS.
-**Note** If your institution doesn’t have an on-premises AD DS domain, you can skip this section.
+>**Note:** If your institution doesn’t have an on-premises AD DS domain, you can skip this section.
### Select the bulk import method
@@ -456,7 +455,7 @@ After you have selected your user and group account bulk import method, you’re
With the bulk-import source file finished, you’re ready to import the user and group accounts into AD DS. The steps for importing the file are slightly different for each method.
-**Note** Bulk-import your group accounts first, and then import your user accounts. Importing in this order allows you to specify group membership when you import your user accounts.
+>**Note:** Bulk-import your group accounts first, and then import your user accounts. Importing in this order allows you to specify group membership when you import your user accounts.
For more information about how to import user accounts into AD DS by using:
@@ -482,7 +481,7 @@ The bulk-add process assigns the same Office 365 Education license plan to all u
For more information about how to bulk-add users to Office 365, see [Add several users at the same time to Office 365](https://support.office.com/en-us/article/Add-several-users-at-the-same-time-to-Office-365-Admin-Help-1f5767ed-e717-4f24-969c-6ea9d412ca88?ui=en-US&rs=en-US&ad=US).
-**Note** If you encountered errors during bulk add, resolve them before you continue the bulk-add process. You can view the log file to see which users caused the errors, and then modify the .csv file to correct the problems. Click **Back** to retry the verification process.
+>**Note:** If you encountered errors during bulk add, resolve them before you continue the bulk-add process. You can view the log file to see which users caused the errors, and then modify the .csv file to correct the problems. Click **Back** to retry the verification process.
The email accounts are assigned temporary passwords upon creation. You must communicate these temporary passwords to your users before they can sign in to Office 365.
@@ -490,13 +489,13 @@ The email accounts are assigned temporary passwords upon creation. You must comm
Assign SharePoint Online resource permissions to Office 365 security groups, not individual user accounts. For example, create one security group for faculty members and another for students. Then, you can assign unique SharePoint Online resource permissions to faculty members and a different set of permissions to students. Add or remove users from the security groups to grant or revoke access to SharePoint Online resources.
-**Note** If your institution has AD DS, don’t create security accounts in Office 365. Instead, create the security groups in AD DS, and then use Azure AD integration to synchronize the security groups with your Office 365 tenant.
+>**Note:** If your institution has AD DS, don’t create security accounts in Office 365. Instead, create the security groups in AD DS, and then use Azure AD integration to synchronize the security groups with your Office 365 tenant.
For information about creating security groups, see [Create and manage Office 365 groups in Admin Center Preview](https://support.office.com/en-us/article/Create-and-manage-Office-365-groups-in-Admin-Center-Preview-93df5bd4-74c4-45e8-9625-56db92865a6e?ui=en-US&rs=en-US&ad=US).
You can add and remove users from security groups at any time.
-**Note** Office 365 evaluates group membership when users sign in. If you change group membership for a user, that user may need to sign out, and then sign in again for the change to take effect.
+>**Note:** Office 365 evaluates group membership when users sign in. If you change group membership for a user, that user may need to sign out, and then sign in again for the change to take effect.
### Create email distribution groups
@@ -504,7 +503,7 @@ Microsoft Exchange Online uses an email distribution group as a single email rec
You can create email distribution groups based on job role (such as teachers, administration, or students) or specific interests (such as robotics, drama club, or soccer team). You can create any number of distribution groups, and users can be members of more than one group.
-**Note** Office 365 can take some time to complete the Exchange Online creation process. You will have to wait until Office 365 completes the Exchange Online creation process before you can perform the following steps.
+>**Note:** Office 365 can take some time to complete the Exchange Online creation process. You will have to wait until Office 365 completes the Exchange Online creation process before you can perform the following steps.
For information about how to create security groups, see [Create and manage Office 365 groups in Admin Center Preview](https://support.office.com/en-us/article/Create-and-manage-Office-365-groups-in-Admin-Center-Preview-93df5bd4-74c4-45e8-9625-56db92865a6e?ui=en-US&rs=en-US&ad=US).
@@ -542,7 +541,8 @@ To create and configure your Windows Store for Business portal, simply use the a
#### To create and configure a Windows Store for Business portal
1. In Microsoft Edge or Internet Explorer, type `http://microsoft.com/business-store` in the address bar.
-2. On the **Windows Store for Business** page, click **Sign in with an organizational account**.
**Note** If your institution has AD DS, then don’t create security accounts in Office 365. Instead, create the security groups in AD DS, and then use Azure AD integration to synchronize the security groups with your Office 365 tenant.
+2. On the **Windows Store for Business** page, click **Sign in with an organizational account**.
+>**Note:** If your institution has AD DS, then don’t create security accounts in Office 365. Instead, create the security groups in AD DS, and then use Azure AD integration to synchronize the security groups with your Office 365 tenant.
3. On the Windows Store for Business sign-in page, use the administrative account for the Office 365 subscription you created in the [Create a new Office 365 Education subscription](#create-a-new-office-365-education-subscription) section to sign in.
4. On the **Windows Store for Business Services Agreement** page, review the agreement, select the **I accept this agreement and certify that I have the authority to bind my organization to its terms** check box, and then click **Accept**
5. In the **Welcome to the Windows Store for Business** dialog box, click **OK**.
@@ -565,7 +565,7 @@ After you create the Windows Store for Business portal, configure it by using th
Now that you have created your Windows Store for Business portal, you’re ready to find, acquire, and distribute apps that you will add to your portal. You do this by using the Inventory page in Windows Store for Business.
-**Note** Your educational institution can now use a credit card or purchase order to pay for apps in Windows Store for Business.
+>**Note:** Your educational institution can now use a credit card or purchase order to pay for apps in Windows Store for Business.
You can deploy apps to individual users or make apps available to users through your private store. Deploying apps to individual users restricts the app to those specified users. Making apps available through your private store allows all your users.
@@ -596,11 +596,11 @@ Depending on your school’s requirements, you may need any combination of the f
- Upgrade institution-owned devices to Windows 10 Education.
- Deploy new instances of Windows 10 Education so that new devices have a known configuration.
-**Note** Although you can use Windows 10 Home on institution-owned devices, Microsoft recommends that you use Windows 10 Pro or Windows 10 Education, instead. Windows 10 Pro and Windows 10 Education provide support for MDM, policy-based management, and Windows Store for Business. These features are not available in Windows 10 Home.
+>**Note:** Although you can use Windows 10 Home on institution-owned devices, Microsoft recommends that you use Windows 10 Pro or Windows 10 Education, instead. Windows 10 Pro and Windows 10 Education provide support for MDM, policy-based management, and Windows Store for Business. These features are not available in Windows 10 Home.
One other consideration is the mix of processor architectures you will support. If you can, support only 64-bit versions of Windows 10. If you have devices that can run only 32 bit versions of Windows 10, you will need to import both 64-bit and 32-bit versions of the Windows 10 editions listed above.
-**Note** On devices that have minimal system resources (such as devices with only 2 GB of memory or 32 GB of storage), use 32-bit versions of Windows 10 because 64-bit versions of Windows 10 place more stress on device system resources.
+>**Note:** On devices that have minimal system resources (such as devices with only 2 GB of memory or 32 GB of storage), use 32-bit versions of Windows 10 because 64-bit versions of Windows 10 place more stress on device system resources.
Finally, as a best practice, minimize the number of operating systems that you deploy and manage. If possible, standardize institution-owned devices on one Windows 10 edition (such as a 64-bit version of Windows 10 Education or Windows 10 Pro). Of course, you cannot standardize personal devices on a specific operating system version or processor architecture.
@@ -738,9 +738,7 @@ In addition, you must prepare your environment for sideloading (deploying) Windo
To help reduce the effort needed to deploy Microsoft Office 2016 desktop apps, use the Office Deployment Tool, as described in [Deploy Click-to-Run for Office 365 products by using the Office Deployment Tool](https://technet.microsoft.com/en-us/library/jj219423.aspx?f=255&MSPPError=-2147217396).
-If you have Intune, you can deploy Windows desktop apps after you deploy Windows 10, as described in the [Deploy apps by using Intune](#deploy-apps-by-using-intune) section. This method provides granular deployment of Windows desktop apps, and you can use it for ongoing management of the apps. This is the preferred method for deploying and managing Windows desktop apps.
-
-**Note** You can also deploy Windows desktop apps after you deploy Windows 10, as described in the [Deploy apps by using Intune](#deploy-apps-by-using-intune) section.
+If you have Intune, you can deploy Windows desktop apps after you deploy Windows 10, as described in the [Deploy apps by using Intune](#deploy-apps-by-using-intune) section. This method provides granular deployment of Windows desktop apps, and you can use it for ongoing management of the apps. This is the preferred method for deploying and managing Windows desktop apps.
**Note:** You can also deploy Windows desktop apps after you deploy Windows 10, as described in the [Deploy apps by using Intune](#deploy-apps-by-using-intune) section.
For more information about how to create an MDT application for Window desktop apps, see [Create a New Application in the Deployment Workbench](https://technet.microsoft.com/en-us/library/dn759415.aspx#CreateaNewApplicationintheDeploymentWorkbench).
@@ -897,7 +895,7 @@ Microsoft has several recommended settings for educational institutions. Table 1
| Use of Microsoft accounts |
You want faculty and students to use only Azure AD accounts for institution-owned devices. For these devices, do not use Microsoft accounts or associate a Microsoft account with the Azure AD accounts.
-**Note** Personal devices typically use Microsoft accounts. Faculty and students can associate their Microsoft account with their Azure AD account on these devices.
+**Note:** Personal devices typically use Microsoft accounts. Faculty and students can associate their Microsoft account with their Azure AD account on these devices.
**Group Policy.** Configure the [Accounts: Block Microsoft accounts](https://technet.microsoft.com/en-us/library/jj966262.aspx?f=255&MSPPError=-2147217396) Group Policy setting to use the Users can’t add Microsoft accounts setting option.
**Intune.** Enable or disable the camera by using the **Allow Microsoft account**, **Allow adding non-Microsoft accounts manually**, and **Allow settings synchronization for Microsoft accounts** policy settings under the **Accounts and Synchronization** section of a **Windows 10 General Configuration** policy.
|
@@ -1042,7 +1040,7 @@ Prior to deployment of Windows 10, ensure that you complete the tasks listed in
Use the Deployment Wizard to deploy Windows 10. The LTI deployment process is almost fully automated: You provide only minimal information to the Deployment Wizard at the beginning of the process. After the wizard collects the necessary information, the remainder of the process is fully automated.
-**Note** To fully automate the LTI deployment process, complete the steps in the “Fully Automated LTI Deployment Scenario” section in the [Microsoft Deployment Toolkit Samples Guide](https://technet.microsoft.com/en-us/library/dn781089.aspx).
+>**Note:** To fully automate the LTI deployment process, complete the steps in the “Fully Automated LTI Deployment Scenario” section in the [Microsoft Deployment Toolkit Samples Guide](https://technet.microsoft.com/en-us/library/dn781089.aspx).
In most instances, deployments occur without incident. Only in rare occasions do deployments experience problems.
@@ -1055,7 +1053,7 @@ In most instances, deployments occur without incident. Only in rare occasions do
After you have deployed Windows 10, the devices are almost ready for use. First, you must set up the printers that each classroom will use. Typically, you connect the printers to the same network as the devices in the same classroom. If you don’t have printers in your classrooms, skip this section and proceed to the [Verify deployment](#verify-deployment) section.
-**Note** If you’re performing an upgrade instead of a new deployment, the printers remain configured as they were in the previous version of Windows. As a result, you can skip this section and proceed to the [Verify deployment](#verify-deployment) section.
+>**Note:** If you’re performing an upgrade instead of a new deployment, the printers remain configured as they were in the previous version of Windows. As a result, you can skip this section and proceed to the [Verify deployment](#verify-deployment) section.
#### To set up printers
diff --git a/windows/plan/integration-with-management-solutions-.md b/windows/plan/integration-with-management-solutions-.md
index 195b8d4828..788d1ad4e8 100644
--- a/windows/plan/integration-with-management-solutions-.md
+++ b/windows/plan/integration-with-management-solutions-.md
@@ -2,39 +2,34 @@
title: Integration with management solutions (Windows 10)
description: You can integrate Windows Update for Business deployments with existing management tools such as Windows Server Update Services (WSUS), System Center Configuration Manager, and Microsoft Intune.
ms.assetid: E0CB0CD3-4FE1-46BF-BA6F-5A5A8BD14CC9
-keywords: ["update", "upgrade", "deployment", "manage", "tools"]
+keywords: update, upgrade, deployment, manage, tools
ms.prod: w10
ms.mktglfcycl: plan
ms.sitesec: library
+ms.pagetype: servicing; devices
author: TrudyHa
---
# Integration with management solutions
-
**Applies to**
-
- Windows 10
You can integrate Windows Update for Business deployments with existing management tools such as Windows Server Update Services (WSUS), System Center Configuration Manager, and Microsoft Intune.
## System Center Configuration Manager
-
For Windows 10, version 1511, organizations that already manage their systems with Configuration Manager can also have their devices configured for Windows Update for Business (in other words, set deferral policies on those machines). For Windows 10, version 1511, such devices will be visible in the Configuration Manager console, however they will appear with a detection state of “Unknown”.
## WSUS standalone
-
For Windows 10, version 1511, you cannot configure devices for both Windows Update for Business *and* to receive updates from WSUS. If both group policies are set (for both deferrals as well as WSUS scanning), Windows Update for Business settings will NOT be respected and devices will continue to scan against WSUS.
## Enterprise Mobility Suite: Intune
-
You can configure Windows Update for Business by using MDM policy. To configure Windows Update for Business with Intune:
-
1. Create a new Windows 10 custom policy. (Add a policy, and choose **Custom Configuration for Windows 10 Desktop and phone…**).
@@ -43,9 +38,7 @@ You can configure Windows Update for Business by using MDM policy. To configure
**Note**
As noted, because WSUS and Windows Update for Business are mutually exclusive policies, do not set **UpdateServiceUrl** if you want to configure to defer upgrades.
-
-
3. Establish deferral windows for updates and upgrades.
@@ -54,16 +47,6 @@ You can configure Windows Update for Business by using MDM policy. To configure
## Related topics
-
[Windows Update for Business](windows-update-for-business.md)
[Setup and deployment](setup-and-deployment.md)
-
-
-
-
-
-
-
-
-
diff --git a/windows/plan/setup-and-deployment.md b/windows/plan/setup-and-deployment.md
index a023b39573..590be310dd 100644
--- a/windows/plan/setup-and-deployment.md
+++ b/windows/plan/setup-and-deployment.md
@@ -2,25 +2,23 @@
title: Setup and deployment (Windows 10)
description: This article describes the basic features of a Windows Update for Business deployment.
ms.assetid: E176BB36-3B1B-4707-9665-968D80050DD1
-keywords: ["update", "upgrade", "deployment"]
+keywords: update, upgrade, deployment
ms.prod: w10
ms.mktglfcycl: plan
ms.sitesec: library
+ms.pagetype: servicing; devices
author: TrudyHa
---
# Setup and deployment
-
**Applies to**
-
- Windows 10
This article describes the basic features of a Windows Update for Business deployment. Use this information to familiarize yourself with a simple deployment with a single group of machines connected to Windows Update, in addition to more complex scenarios such as the creation of Windows Update for Business validation groups that receive updates from Windows Update at different time intervals, as well as Windows Update for Business deployments integrated with existing management tools such as Windows Server Update Services (WSUS), System Center Configuration Manager, or Microsoft Intune.
## Configure your systems to receive updates on CBB
-
To use Windows Update for Business, Windows 10-based devices must first be configured for the Current Branch for Business (CBB). You can configure devices manually, by using Group Policy, or by using mobile device management (MDM).
@@ -31,7 +29,6 @@ To use Windows Update for Business, Windows 10-based devices must first be conf
## Defer OS upgrade and update deployments
-
Windows Update for Business allows administrators to control when upgrades and updates are deployed to their Windows 10 clients by specifying deferral windows from when they are initially made available on the Windows Update service. As mentioned, there are restrictions as to how long you can delay upgrades and updates. The following table details these restrictions, per deployment category type:
@@ -44,7 +41,6 @@ Windows Update for Business allows administrators to control when upgrades and u
@@ -90,32 +86,19 @@ Windows Update for Business allows administrators to control when upgrades and u
-
-
Administrators can control deferral periods with Group Policy Objects by using the [Local Group Policy Editor (GPEdit)](http://go.microsoft.com/fwlink/p/?LinkId=734030) or, for domain joined systems, [Group Policy Management Console (GPMC)](http://go.microsoft.com/fwlink/p/?LinkId=699325). For additional details on Group Policy management see [Group Policy management for IT pros](http://go.microsoft.com/fwlink/p/?LinkId=699282).
-
**Set different deferrals based on update classification in GPedit.msc**
-
-
-
## Pause upgrades and updates
-
-
Although administrators can use deferral periods to stagger the rate at which deployments go out to their organization (which provides time to verify quality and address any issues), there may be cases where additional time is needed before an update is set to deploy to a machine, or group of machines. Windows Update for Business provides a means for administrators to *pause* updates and upgrades on a per-machine basis. This pause functionality ensures that no updates or upgrades will be made available for the specified machine; the machine will remain in this state until the machine is specifically “unpaused”, or when a period of five weeks (35 days) has passed, at which point updates are auto-resumed.
-
**Note**
The five-week period ensures that pause functionality overlaps a possible subsequent Update Tuesday release.
-
-
**Note**
Group Policy does not allow you to set a future "unpause” — administrators must actively select to unpause a deployment if they wish to do so before the time expiration.
-
-
@@ -136,33 +119,24 @@ Group Policy does not allow you to set a future "unpause” — administrators m
-
-
## Create validation groups for deployments
-
By grouping machines into similar deferral periods, administrators are able to cluster devices into deployment or validation groups which can be used as a quality control measure as updates are deployed in Windows 10. With deferral windows and the ability to pause, administrators can effectively control and measure update deployments by rolling out to a small pool of devices first to verify quality, prior to a broader roll-out to their organization.
Administrators can establish validation groups to maintain a level of control over update/driver deployments which allows them to:
-
- Control the date, time, and frequency updates will be applied and devices rebooted
-
- Deploy a small set of machines to verify quality prior to broad roll-out
-
- Stage broad roll-out in waves to continue quality verification and minimize disruptions
-
- Manage membership of waves based on criteria defined by IT
-
- Halt and roll-back deployment of updates/drivers that may be causing trouble
## Peer-to-peer networking for deployments
-
Windows Update Delivery Optimization enables Windows Update for Business enrolled devices to download Windows updates and Windows Store apps from sources other than Microsoft. With multiple devices, Delivery Optimization can reduce the amount of Internet bandwidth that is required to keep all of your Windows Update for Business enrolled systems up to date. It can also help ensure that devices get updates and apps more quickly if they have a limited or unreliable Internet connection.
In addition to downloading updates and apps from Microsoft, Windows will get updates and apps from other PCs that already have them. You can choose which PCs you get these updates from.
@@ -170,36 +144,26 @@ In addition to downloading updates and apps from Microsoft, Windows will get upd
### How Delivery Optimization works
- **PCs on your local network.** When Windows downloads an update or app, it will look for other PCs on your local network that have already downloaded the update or app using Delivery Optimization. Windows then downloads parts of the file from those PCs and parts of the file from Microsoft. Windows doesn’t download the entire file from one place. Instead, the download is broken down into smaller parts. Windows uses the fastest, most reliable download source for each part of the file.
-
- **PCs on your local network and PCs on the Internet.** Windows uses the same process as when getting updates and apps from PCs on your local network, and also looks for PCs on the Internet that can be used as a source to download parts of updates and apps.
### Delivery Optimization settings
Delivery Optimization is turned on by default for the Enterprise and Education editions of Windows 10, where the default option is that updates will only be pulled and shared from PCs on your LAN and not the Internet.
-
Delivery Optimization configuration settings can be viewed by going to: Settings > Update and Security > Advanced Options > Choose how your updates are delivered
## Use Group Policy to configure Windows Update Delivery Optimization
-
You can use Group Policy to configure Windows Update Delivery Optimization. To do this, use the following steps:
1. Download the [Administrative Templates (.admx) file for Windows 10](http://go.microsoft.com/fwlink/p/?LinkId=699283) from the Microsoft Download Center.
-
2. Copy the following files to the SYSVOL central store:
-
- DeliveryOptimization.admx from C:\\Program Files (x86)\\Microsoft Group Policy\\Windows 10\\PolicyDefinitions
-
- DeliveryOptimization.adml from C:\\Program Files (x86)\\Microsoft Group Policy\\Windows 10\\PolicyDefinitions\\en-US
-
3. Start the Gpeditor tool.
-
4. Browse to the following location:
-
- Computer Configuration\\Administrative Templates\\Windows Components\\Delivery Optimization
-
5. Make the following Windows Update Delivery Optimization settings, as appropriate.
@@ -214,16 +178,6 @@ For additional resources, see [How to use Group Policy to configure Windows Upda
## Related topics
-
[Windows Update for Business](windows-update-for-business.md)
[Integration with management solutions](integration-with-management-solutions-.md)
-
-
-
-
-
-
-
-
-
diff --git a/windows/plan/windows-10-guidance-for-education-environments.md b/windows/plan/windows-10-guidance-for-education-environments.md
index 716217d420..c40e7da07e 100644
--- a/windows/plan/windows-10-guidance-for-education-environments.md
+++ b/windows/plan/windows-10-guidance-for-education-environments.md
@@ -5,17 +5,16 @@ ms.assetid: 225C9D6F-9329-4DDF-B447-6CE7804E314E
ms.prod: W10
ms.mktglfcycl: plan
ms.sitesec: library
+ms.pagetype: security
author: craigash
---
# Guidance for education environments
-
Find resources to help you plan your deployment of Windows 10 to desktops, laptops, tablets, and other devices in educational institutions.
## In this section
-
@@ -34,14 +33,6 @@ Find resources to help you plan your deployment of Windows 10 to desktops, lapt
-
-
-
-
-
-
-
-
diff --git a/windows/plan/windows-update-for-business.md b/windows/plan/windows-update-for-business.md
index b936f37735..7371c01825 100644
--- a/windows/plan/windows-update-for-business.md
+++ b/windows/plan/windows-update-for-business.md
@@ -2,67 +2,50 @@
title: Windows Update for Business (Windows 10)
description: Get an overview of how you can implement and deploy a Windows Update for Business solution and how to maintain enrolled systems.
ms.assetid: DF61F8C9-A8A6-4E83-973C-8ABE090DB8C6
-keywords: ["update", "upgrade", "deployment", "WSUS"]
+keywords: [update, upgrade, deployment, WSUS
ms.prod: w10
ms.mktglfcycl: plan
ms.sitesec: library
+ms.pagetype: servicing; devices
author: TrudyHa
---
# Windows Update for Business
-
**Applies to**
-
- Windows 10
Get an overview of how you can implement and deploy a Windows Update for Business solution and how to maintain enrolled systems.
## Introduction
-
Windows Update for Business enables information technology administrators to keep the Windows 10-based devices in their organization always up to date with the latest security defenses and Windows features by directly connecting these systems to Microsoft’s Windows Update service. By using [Group Policy Objects](http://go.microsoft.com/fwlink/p/?LinkId=699279), Windows Update for Business is an easily established and implemented system which enables organizations and administrators to exercise control on how their Windows 10-based devices are updated, by allowing:
-
- **Deployment and validation groups**; where administrators can specify which devices go first in an update wave, and which devices will come later (to ensure any quality bars are met).
-
- **Peer-to-peer delivery**, which administrators can enable to make delivery of updates to branch offices and remote sites with limited bandwidth very efficient.
-
- **Use with existing tools** such as System Center Configuration Manager and the [Enterprise Mobility Suite](http://go.microsoft.com/fwlink/p/?LinkId=699281).
Together, these Windows Update for Business features help reduce device management costs, provide controls over update deployment, offer quicker access to security updates, as well as provide access to the latest innovations from Microsoft on an ongoing basis. Windows Update for Business is a free service for all Windows 10 Pro, Enterprise, and Education editions, and can be used independent of, or in conjunction with, existing device management solutions such as [Windows Server Update Services (WSUS)](http://go.microsoft.com/fwlink/p/?LinkId=734043) and [System Center Configuration Manager](http://go.microsoft.com/fwlink/p/?LinkId=734044).
## Deploy Windows Update for Business in your organization
-
For Windows 10, version 1511, Windows Update for Business is enabled using a set of client-side configurations, allowing you to manage how and when Windows-based devices receive updates and upgrades. These capabilities use the Windows Update service like any other Windows 10 clients, but provides controls to help businesses validate update quality as well as time their update deployments to machines through the use of Group Policy Objects. Windows Update for Business also incorporates smart peer-to-peer networking for distribution of Windows updates, which will help maintain bandwidth efficiency in the absence of a WSUS solution.
## Eligible devices
-
All devices running Windows 10 Pro, Enterprise, and Education on the Current Branch for Business (CBB) are Windows Update for Business eligible.
## OS upgrades and updates
-
In Windows 10, Windows Update for Business recognizes three deployment categories that clients receive from Windows Update:
-
- **Upgrades**
-
- Examples: Windows 10 (Build 10240) to Windows 10, version 1511; CBB 1 to CBB 2
-
**Note**
In the Windows 10 servicing model, new CBBs will be declared 2-3 times per year.
-
-
- **Updates**
-
- General OS updates, typically released the second Tuesday of each month. These include Security, Critical, and Driver updates.
-
- **Other/non-deferrable**
-
- Definition updates (these cannot be deferred)
-
Both upgrades and updates can be deferred from deployment to client machines by a Windows Update for Business administrator within a bounded rage of time from when those updates are first made available on the Windows Update service. This deferral capability allows administrators to validate deployments as they are pushed to all their Windows Update for Business enrolled clients. The following table defines maximum deferral periods allowed by deployment type:
@@ -106,18 +89,8 @@ Both upgrades and updates can be deferred from deployment to client machines by
## Related topics
-
[Setup and deployment](setup-and-deployment.md)
[Integration with management solutions](integration-with-management-solutions-.md)
[Windows 10 servicing options for updates and upgrades](../manage/introduction-to-windows-10-servicing.md)
-
-
-
-
-
-
-
-
-
diff --git a/windows/whats-new/applocker.md b/windows/whats-new/applocker.md
index 1921961c20..cd25de1dee 100644
--- a/windows/whats-new/applocker.md
+++ b/windows/whats-new/applocker.md
@@ -2,6 +2,7 @@
title: What's new in AppLocker (Windows 10)
description: AppLocker helps you control which apps and files users can run. These include executable files, scripts, Windows Installer files, dynamic-link libraries (DLLs), packaged apps, and packaged app installers.
ms.assetid: 6F836FF6-7794-4E7B-89AA-1EABA1BF183F
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: explore
ms.sitesec: library
@@ -10,32 +11,19 @@ author: brianlic-msft
# What's new in AppLocker?
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
AppLocker helps you control which apps and files users can run. These include executable files, scripts, Windows Installer files, dynamic-link libraries (DLLs), packaged apps, and packaged app installers.
-
In Windows 10, AppLocker has added some improvements.
## New features in Windows 10
-
- A new parameter was added to the [New-AppLockerPolicy](http://technet.microsoft.com/library/hh847211.aspx) Windows PowerShell cmdlet that lets you choose whether executable and DLL rule collections apply to non-interactive processes. To enable this, set the **ServiceEnforcement** to **Enabled**.
-
- A new [AppLocker](http://msdn.microsoft.com/library/windows/hardware/dn920019.aspx) configuration service provider was add to allow you to enable AppLocker rules by using an MDM server.
-
- You can manage Windows 10 Mobile devices by using the new [AppLocker CSP](http://msdn.microsoft.com/library/windows/hardware/dn920019.aspx).
[Learn how to manage AppLocker within your organization](../keep-secure/applocker-overview.md).
-
-
-
-
-
-
-
diff --git a/windows/whats-new/bitlocker.md b/windows/whats-new/bitlocker.md
index 2d2adc6cff..d0b31ecfc5 100644
--- a/windows/whats-new/bitlocker.md
+++ b/windows/whats-new/bitlocker.md
@@ -5,14 +5,13 @@ ms.assetid: 3F2DE365-68A1-4CDB-AB5F-C65574684C7B
ms.prod: W10
ms.mktglfcycl: explore
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# What's new in BitLocker?
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
@@ -20,41 +19,22 @@ BitLocker Drive Encryption is a data protection feature that integrates with the
## New features in Windows 10, version 1511
-
- **XTS-AES encryption algorithm**. BitLocker now supports the XTS-AES encryption algorithm. XTS-AES provides additional protection from a class of attacks on encryption that rely on manipulating cipher text to cause predictable changes in plain text. BitLocker supports both 128-bit and 256-bit XTS-AES keys.
-
It provides the following benefits:
-
- The algorithm is FIPS-compliant.
-
- Easy to administer. You can use the BitLocker Wizard, manage-bde, Group Policy, MDM policy, Windows PowerShell, or WMI to manage it on devices in your organization.
-
**Note**
Drives encrypted with XTS-AES will not be accessible on older version of Windows. This is only recommended for fixed and operating system drives. Removable drives should continue to use the AES-CBC 128-bit or AES-CBC 256-bit algorithms.
-
-
## New features in Windows 10
-
- **Encrypt and recover your device with Azure Active Directory**. In addition to using a Microsoft Account, automatic [Device Encryption](http://technet.microsoft.com/library/dn306081.aspx#bkmk-encryption) can now encrypt your devices that are joined to an Azure Active Directory domain. When the device is encrypted, the BitLocker recovery key is automatically escrowed to Azure Active Directory. This will make it easier to recover your BitLocker key online.
-
- **DMA port protection**. You can use the [DataProtection/AllowDirectMemoryAccess](http://msdn.microsoft.com/library/windows/hardware/dn904962.aspx) MDM policy to block DMA ports when the device is starting up. Also, when a device is locked, all unused DMA ports are turned off, but any devices that are already plugged into a DMA port will continue to work. When the device is unlocked, all DMA ports are turned back on.
-
- **New Group Policy for configuring pre-boot recovery**. You can now configure the pre-boot recovery message and recover URL that is shown on the pre-boot recovery screen. For more info, see the "Configure pre-boot recovery message and URL" section in [BitLocker Group Policy settings](../keep-secure/bitlocker-group-policy-settings.md).
[Learn how to deploy and manage BitLocker within your organization](../keep-secure/bitlocker-overview.md).
## Related topics
-
[Trusted Platform Module](../keep-secure/trusted-platform-module-overview.md)
-
-
-
-
-
-
-
-
-
+
\ No newline at end of file
diff --git a/windows/whats-new/credential-guard.md b/windows/whats-new/credential-guard.md
index 27c035b5ad..148a76ff4e 100644
--- a/windows/whats-new/credential-guard.md
+++ b/windows/whats-new/credential-guard.md
@@ -2,6 +2,7 @@
title: What's new in Credential Guard (Windows 10)
description: Credential Guard uses virtualization-based security to isolate secrets so that only privileged system software can access them.
ms.assetid: 59C206F7-2832-4555-97B4-3070D93CC3C5
+ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: explore
ms.sitesec: library
@@ -10,35 +11,20 @@ author: brianlic-msft
# What's new in Credential Guard?
-
**Applies to**
-
- Windows 10
Credential Guard uses virtualization-based security to isolate secrets so that only privileged system software can access them.
## New features in Windows 10, version 1511
-
- **Credential Manager support**. Credentials that are stored with Credential Manager, including domain credentials, are protected with Credential Guard with the following considerations:
-
- Credentials that are saved by the Remote Desktop Protocol cannot be used. Employees in your organization can manually store credentials in Credential Manager as generic credentials.
-
- Applications that extract derived domain credentials using undocumented APIs from Credential Manager will no longer be able to use those saved derived credentials.
-
- You cannot restore credentials using the Credential Manager control panel if the credentials were backed up from a PC that has Credential Guard turned on. If you need to back up your credentials, you must do this before you enable Credential Guard. Otherwise, you won't be able to restore those credentials.
-
- **Enable Credential Guard without UEFI lock**. You can enable Credential Guard by using the registry. This allows you to disable Credential Guard remotely. However, we recommend that Credential Guard is enabled with UEFI lock. You can configure this by using Group Policy.
-
- **CredSSP/TsPkg credential delegation**. CredSSP/TsPkg cannot delegate default credentials when Credential Guard is enabled.
[Learn how to deploy and manage Credential Guard within your organization](../keep-secure/credential-guard.md).
-
-
-
-
-
-
-
diff --git a/windows/whats-new/device-guard-overview.md b/windows/whats-new/device-guard-overview.md
index e9bb342203..bdb9a878db 100644
--- a/windows/whats-new/device-guard-overview.md
+++ b/windows/whats-new/device-guard-overview.md
@@ -2,7 +2,8 @@
title: Device Guard overview (Windows 10)
description: Device Guard is a combination of enterprise-related hardware and software security features that, when configured together, will lock a device down so that it can only run trusted applications.
ms.assetid: FFE244EE-5804-4CE8-A2A9-48F49DC3AEF2
-keywords: ["Device Guard"]
+ms.pagetype: security
+keywords: Device Guard
ms.prod: W10
ms.mktglfcycl: explore
ms.sitesec: library
@@ -11,63 +12,35 @@ author: brianlic-msft
# Device Guard overview
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
Device Guard is a combination of enterprise-related hardware and software security features that, when configured together, will lock a device down so that it can only run trusted applications. If the app isn’t trusted it can’t run, period. It also means that even if an attacker manages to get control of the Windows kernel, he or she will be much less likely to be able to run malicious executable code after the computer restarts because of how decisions are made about what can run and when.
-
Device Guard uses the new virtualization-based security in Windows 10 Enterprise to isolate the Code Integrity service from the Microsoft Windows kernel itself, letting the service use signatures defined by your enterprise-controlled policy to help determine what is trustworthy. In effect, the Code Integrity service runs alongside the kernel in a Windows hypervisor-protected container.
-
For details on how to implement Device Guard, see [Device Guard deployment guide](../keep-secure/device-guard-deployment-guide.md).
-
## Why use Device Guard
-
-
With thousands of new malicious files created every day, using traditional methods like signature-based detection to fight against malware provides an inadequate defense against new attacks. Device Guard on Windows 10 Enterprise changes from a mode where apps are trusted unless blocked by an antivirus or other security solutions, to a mode where the operating system trusts only apps authorized by your enterprise.
-
Device Guard also helps protect against [zero day attacks](http://go.microsoft.com/fwlink/p/?linkid=534209) and works to combat the challenges of [polymorphic viruses](http://go.microsoft.com/fwlink/p/?LinkId=534210).
-
### Advantages to using Device Guard
-
You can take advantage of the benefits of Device Guard, based on what you turn on and use:
-
- Helps provide strong malware protection with enterprise manageability
- Helps provide the most advanced malware protection ever offered on the Windows platform
- Offers improved tamper resistance
-
## How Device Guard works
-
-
Device Guard restricts the Windows 10 Enterprise operating system to only running code that’s signed by trusted signers, as defined by your Code Integrity policy through specific hardware and security configurations, including:
-
- User Mode Code Integrity (UMCI)
-
- New kernel code integrity rules (including the new Windows Hardware Quality Labs (WHQL) signing constraints)
-
- Secure Boot with database (db/dbx) restrictions
-
- Virtualization-based security to help protect system memory and kernel mode apps and drivers from possible tampering.
-
- **Optional:** Trusted Platform Module (TPM) 1.2 or 2.0
-
Device Guard works with your image-building process, so you can turn the virtualization-based security feature on for capable devices, configure your Code Integrity policy, and set any other operating system settings you require for Windows 10 Enterprise. After that, Device Guard works to help protect your devices:
-
1. Your device starts up using Universal Extensible Firmware Interface (UEFI) Secure Boot, so that boot kits can’t run and so that Windows 10 Enterprise starts before anything else.
-
2. After securely starting up the Windows boot components, Windows 10 Enterprise can start the Hyper-V virtualization-based security services, including Kernel Mode Code Integrity. These services help protect the system core (kernel), privileged drivers, and system defenses, like anti-malware solutions, by preventing malware from running early in the boot process, or in kernel after startup.
-
3. Device Guard uses UMCI to make sure that anything that runs in User mode, such as a service, a Universal Windows Platform (UWP) app, or a Classic Windows application is trusted, allowing only trusted binaries to run.
-
4. At the same time that Windows 10 Enterprise starts up, so too does the trusted platform module (TPM). TPM provides an isolated hardware component that helps protect sensitive information, such as user credentials and certificates.
-
## Required hardware and software
-
-
The following table shows the hardware and software you need to install and configure to implement Device Guard.
-
@@ -110,55 +83,28 @@ The following table shows the hardware and software you need to install and conf
Secure firmware update process |
-To verify that the firmware complies with the secure firmware update process, you can validate it against the [System.Fundamentals.Firmware.UEFISecureBoot](http://msdn.microsoft.com/library/windows/hardware/dn932805.aspx#system-fundamentals-firmware-uefisecureboot) Windows Hardware Compatibility Program requirement. |
+To verify that the firmware complies with the secure firmware update process, you can validate it against the [System.Fundamentals.Firmware.UEFISecureBoot](http://msdn.microsoft.com/library/windows/hardware/dn932805.aspx#system-fundamentals-firmware-uefisecureboot) Windows Hardware Compatibility Program requirement. Device Guard relies on the security of the underlying hardware and firmware. It is critical to keep the firmware updated with the latest security fixes. |
-
-
## Before using Device Guard in your company
-
-
Before you can successfully use Device Guard, you must set up your environment and your policies.
-
### Signing your apps
-
Device Guard mode supports both UWP apps and Classic Windows applications. Trust between Device Guard and your apps happen when your apps are signed using a signature that you determine to be trustworthy. Not just any signature will work.
-
This signing can happen by:
-
- **Using the Windows Store publishing process.** All apps that come out of the Microsoft Store are automatically signed with special signatures that can roll-up to our certificate authority (CA) or to your own.
-
- **Using your own digital certificate or public key infrastructure (PKI).** ISV's and enterprises can sign their own Classic Windows applications themselves, adding themselves to the trusted list of signers.
-
- **Using a non-Microsoft signing authority.** ISV's and enterprises can use a trusted non-Microsoft signing authority to sign all of their own Classic Windows applications.
-
- **Use the Device Guard signing portal**. Available in the Windows Store for Business, you can use a Microsoft web service to sign your Classic Windows applications. For more info, see [Device Guard signing](../manage/device-guard-signing-portal.md).
-
### Code Integrity policy
-
Before you can use the app protection included in Device Guard, you must create a Code Integrity policy using tools provided by Microsoft, but deployed using your current management tools, like Group Policy. The Code Integrity policy is a binary-encoded XML document that includes configuration settings for both the User and Kernel-modes of Windows 10 Enterprise, along with restrictions on Windows 10 script hosts. This policy restricts what code can run on a device.
-
For the Device Guard feature, devices should only have Code Integrity pre-configured if the settings are provided by a customer for a customer-provided image.
-
**Note** This XML document can be signed in Windows 10 Enterprise, helping to add additional protection against administrative users changing or removing this policy.
-
-
### Virtualization-based security using Windows 10 Enterprise Hypervisor
-
Windows 10 Enterprise Hypervisor introduces new capabilities around virtual trust levels, which helps Windows 10 Enterprise services to run in a protected environment, in isolation from the running operating system. Windows 10 Enterprise virtualization-based security helps protect kernel code integrity and helps to provide credential isolation for the local security authority (LSA). Letting the Kernel Code Integrity service run as a hypervisor-hosted service increases the level of protection around the root operating system, adding additional protections against any malware that compromises the kernel layer.
-
**Important** Device Guard devices that run Kernel Code Integrity with virtualization-based security must have compatible drivers - legacy drivers can be updated - and have all virtualization capabilities turned on. This includes virtualization extensions and input/output memory management unit (IOMMU) support.
-
-
-
-
-
-
-
-
diff --git a/windows/whats-new/edp-whats-new-overview.md b/windows/whats-new/edp-whats-new-overview.md
index 11e9b2a883..26e5b09d9b 100644
--- a/windows/whats-new/edp-whats-new-overview.md
+++ b/windows/whats-new/edp-whats-new-overview.md
@@ -2,16 +2,17 @@
title: Enterprise data protection (EDP) overview (Windows 10)
description: With the increase of employee-owned devices in the enterprise, there’s also an increasing risk of accidental data disclosure through apps and services that are outside of the enterprise’s control like email, social media, and the public cloud.
ms.assetid: 428A3135-CB5E-478B-B1FF-B6EB76F0DF14
-keywords: ["EDP Overview", "EDP"]
+keywords: EDP Overview, EDP
ms.prod: W10
ms.mktglfcycl: explore
ms.sitesec: library
+ms.pagetype: security
author: eross-msft
---
# Enterprise data protection (EDP) overview
-**Applies to:**
+**Applies to:**
- Windows 10 Insider Preview
- Windows 10 Mobile Preview
@@ -22,83 +23,74 @@ With the increase of employee-owned devices in the enterprise, there’s also an
Many of the existing solutions try to address this issue by requiring employees to switch between personal and work containers and apps, which can lead to a less than optimal user experience. The feature code-named enterprise data protection (EDP) offers a better user experience, while helping to better separate and protect enterprise apps and data against disclosure risks across both company and personal devices, without requiring changes in environments or apps. Additionally, EDP when used with Rights Management Services (RMS), can help to protect your enterprise data locally, persisting the protection even when your data roams or is shared.
## Benefits of EDP
+
EDP provides:
- Additional protection against enterprise data leakage, with minimal impact on employees’ regular work practices.
-
- Obvious separation between personal and corporate data, without requiring employees to switch environments or apps.
-
- Additional data protection for existing line-of-business apps without a need to update the apps.
-
- Ability to wipe corporate data from devices while leaving personal data alone.
-
- Use of audit reports for tracking issues and remedial actions.
-
- Integration with your existing management system (Microsoft Intune, System Center Configuration Manager (version 1511 or later)’, or your current mobile device management (MDM) system) to configure, deploy, and manage EDP for your company.
-
- Additional protection for your data (through RMS integration) while roaming and sharing, like when you share encrypted content through Outlook or move encrypted files to USB keys.
-
- Ability to manage Office universal apps on Windows 10 devices using an MDM solution to help protect corporate data. To manage Office mobile apps for Android and iOS devices, see technical resources [here]( http://go.microsoft.com/fwlink/p/?LinkId=526490).
## Enterprise scenarios
EDP currently addresses these enterprise scenarios:
-
- You can encrypt enterprise data on employee-owned and corporate-owned devices.
-
- You can remotely wipe enterprise data off managed computers, including employee-owned computers, without affecting the personal data.
-
- You can select specific apps that can access enterprise data, called "protected apps" that are clearly recognizable to employees. You can also block non-protected apps from accessing enterprise data.
-
- Your employees won't have their work otherwise interrupted while switching between personal and enterprise apps while the enterprise policies are in place. Switching environments or signing in multiple times isn’t required.
### Enterprise data security
+
As an enterprise admin, you need to maintain the security and confidentiality of your corporate data. Using EDP you can help ensure that your corporate data is protected on your employee-owned computers, even when the employee isn’t actively using it. In this case, when the employee initially creates the content on a managed device he’s asked whether it’s a work document. If it's a work document, it becomes locally-protected as enterprise data.
### Persistent data encryption
+
EDP helps keep your enterprise data protected, even when it roams. Apps like Office and OneNote work with EDP to persist your data encryption across locations and services. For example, if an employee opens EDP-encrypted content from Outlook, edits it, and then tries to save the edited version with a different name to remove the encryption, it won’t work. Outlook automatically applies EDP to the new document, keeping the data encryption in place.
### Remotely wiping devices of enterprise data
EDP also offers the ability to remotely wipe your corporate data from all devices managed by you and used by an employee, while leaving personal data alone. This is a benefit when an employee leaves your company, or in the case of a stolen computer.
-
In this case, documents are stored locally, and encrypted with an enterprise identity. When you verify that you have to wipe the device, you can send a remote wipe command through your mobile device management system so when the device connects to the network, the encryption keys are revoked and the enterprise data is removed. This action only affects devices that have been targeted by the command. All other devices will continue to work normally.
### Protected apps and restrictions
-Using EDP you can control the set of apps that are made "protected apps", or apps that can access and use your enterprise data. After you add an app to your **Protected App** list, it’s trusted to use enterprise data. All apps not on this list are treated as personal and are potentially blocked from accessing your corporate data, depending on your EDP protection-mode.
+Using EDP you can control the set of apps that are made "protected apps", or apps that can access and use your enterprise data. After you add an app to your **Protected App** list, it’s trusted to use enterprise data. All apps not on this list are treated as personal and are potentially blocked from accessing your corporate data, depending on your EDP protection-mode.
As a note, your existing line-of-business apps don’t have to change to be included as protected apps. You simply have to include them in your list.
### Great employee experiences
+
EDP can offer a great user experience by not requiring employees to switch between apps to protect corporate data. For example, while checking work emails in Microsoft Outlook, an employee gets a personal message. Instead of having to leave Outlook, both the work and personal messages appear on the screen, side-by-side.
#### Using protected apps
+
Protected apps are allowed to access your enterprise data and will react differently with other non-protected or personal apps. For example, if your EDP-protection mode is set to block, your protected apps will let the employee copy and paste information between other protected apps, but not with personal apps. Imagine an HR person wants to copy a job description from a protected app to an internal career website, an enterprise-protected location, but goofs and tries to paste into a personal app instead. The paste action fails and a notification pops up, saying that it couldn’t paste because of a policy restriction. The HR person then correctly pastes to the career website and it works without a problem.
#### Copying or downloading enterprise data
+
Downloading content from a location like SharePoint or a network file share, or an enterprise web location, such as Office365.com automatically determines that the content is enterprise data and is encrypted as such, while it’s stored locally. The same applies to copying enterprise data to something like a USB drive. Because the content is already marked as enterprise data locally, the encryption is persisted on the new device.
#### Changing the EDP protection
+
Employees can change enterprise data protected documents back to personal if the document is wrongly marked as enterprise. However, this requires the employee to take an action and is audited and logged for you to review
### Deciding your level of data access
+
EDP lets you decide to block, allow overrides, or silently audit your employee's data sharing actions. Blocking the action stops it immediately, while allowing overrides let the employee know there's a problem, but lets the employee continue to share the info, and silent just logs the action without stopping it, letting you start to see patterns of inappropriate sharing so you can take educative action.
### Helping prevent accidental data disclosure to public spaces
+
EDP helps protect your enterprise data from being shared to public spaces, like the public cloud, accidentally. For example, if an employee stores content in the **Documents** folder, which is automatically synched with OneDrive (an app on your Protected Apps list), then the document is encrypted locally and not synched it to the user’s personal cloud. Likewise, if other synching apps, like Dropbox™, aren’t on the Protected Apps list, they also won’t be able to sync encrypted files to the user’s personal cloud.
### Helping prevent accidental data disclosure to other devices
+
EDP helps protect your enterprise data from leaking to other devices while transferring or moving between them. For example, if an employee puts corporate data on a USB key that also includes personal data, the corporate data remains encrypted even though the personal information remains open. Additionally, the encryption continues when the employee copies the encrypted content back to another corporate-managed device.
## Turn off EDP
+
You can turn off all enterprise data protection and restrictions, reverting to where you were pre-EDP, with no data loss. However, turning off EDP isn't recommended. If you choose to turn it off, you can always turn it back on, but EDP won't retain your decryption and policies info.
## Related topics
- [Protect your enterprise data using enterprise data protection (EDP)](../keep-secure/protect-enterprise-data-using-edp.md)
-
-
-
-
-
-
-
-
-
+
\ No newline at end of file
diff --git a/windows/whats-new/lockdown-features-windows-10.md b/windows/whats-new/lockdown-features-windows-10.md
index ad706275ab..265ddba22a 100644
--- a/windows/whats-new/lockdown-features-windows-10.md
+++ b/windows/whats-new/lockdown-features-windows-10.md
@@ -2,18 +2,17 @@
title: Lockdown features from Windows Embedded 8.1 Industry (Windows 10)
description: Many of the lockdown features available in Windows Embedded 8.1 Industry have been modified in some form for Windows 10.
ms.assetid: 3C006B00-535C-4BA4-9421-B8F952D47A14
-keywords: ["lockdown", "embedded"]
+keywords: lockdown, embedded
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
+ms.pagetype: security
author: jdeckerMS
---
# Lockdown features from Windows Embedded 8.1 Industry
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
@@ -111,14 +110,6 @@ Many of the lockdown features available in Windows Embedded 8.1 Industry have be
-
-
-
-
-
-
-
-
diff --git a/windows/whats-new/microsoft-passport.md b/windows/whats-new/microsoft-passport.md
index f50638ea29..6ee13afe28 100644
--- a/windows/whats-new/microsoft-passport.md
+++ b/windows/whats-new/microsoft-passport.md
@@ -2,55 +2,39 @@
title: Microsoft Passport overview (Windows 10)
description: In Windows 10, Microsoft Passport replaces passwords with strong two-factor authentication.
ms.assetid: 292F3BE9-3651-4B20-B83F-85560631EF5B
-keywords: ["password", "hello", "fingerprint", "iris", "biometric"]
+keywords: password, hello, fingerprint, iris, biometric
ms.prod: W10
ms.mktglfcycl: explore
ms.sitesec: library
+ms.pagetype: security
author: jdeckerMS
---
# Microsoft Passport overview
-
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
In Windows 10, Microsoft Passport replaces passwords with strong two-factor authentication that consists of an enrolled device and a Windows Hello (biometric) or PIN.
Microsoft Passport lets users authenticate to a Microsoft account, an Active Directory account, a Microsoft Azure Active Directory (AD) account, or non-Microsoft service that supports [Fast ID Online (FIDO)](http://go.microsoft.com/fwlink/p/?LinkId=533889) authentication. After an initial two-step verification during Microsoft Passport enrollment, a Microsoft Passport is set up on the user's device and the user sets a gesture, which can be Windows Hello or a PIN. The user provides the gesture to verify identity; Windows then uses Microsoft Passport to authenticate users and help them to access protected resources and services.
-
Microsoft Passport also enables Windows 10 Mobile devices to be used as a remote credential when signing into Windows 10 PCs. During the sign-in process, the Windows 10 PC can connect using Bluetooth to access Microsoft Passport on the user’s Windows 10 Mobile device. Because users carry their phone with them, Microsoft Passport makes implementing two-factor authentication across the enterprise less costly and complex than other solutions
## Benefits of Microsoft Passport
-
- **User convenience**. The employee provides credentials (such as account and password, or other credentials), and is then guided to set up Microsoft Passport and Hello. From that point on, the employee can access enterprise resources by providing a gesture.
+- **Security**. Microsoft Passport helps protect user identities and user credentials. Because no passwords are used, it helps circumvent phishing and brute force attacks. It also helps prevent server breaches because Microsoft
-- **Security**. Microsoft Passport helps protect user identities and user credentials. Because no passwords are used, it helps circumvent phishing and brute force attacks. It also helps prevent server breaches because Microsoft Passport credentials are an asymmetric key pair, which helps prevent replay attacks when these keys are generated within isolated environments of Trusted Platform Modules (TPMs).
-
+Passport credentials are an asymmetric key pair, which helps prevent replay attacks when these keys are generated within isolated environments of Trusted Platform Modules (TPMs).
[Learn how to implement and manage Microsoft Passport in your organization.](../keep-secure/implement-microsoft-passport-in-your-organization.md)
## Learn more
-
[Why a PIN is better than a password](../keep-secure/why-a-pin-is-better-than-a-password.md)
-
[Windows 10: Disrupting the Revolution of Cyber-Threats with Revolutionary Security!](http://go.microsoft.com/fwlink/p/?LinkId=533890)
-
[Windows 10: The End Game for Passwords and Credential Theft?](http://go.microsoft.com/fwlink/p/?LinkId=533891)
## Related topics
-
-
[Device management](device-management.md)
-
-
-
-
-
-
-
diff --git a/windows/whats-new/security-auditing.md b/windows/whats-new/security-auditing.md
index 9d88b459f9..92e3548a8c 100644
--- a/windows/whats-new/security-auditing.md
+++ b/windows/whats-new/security-auditing.md
@@ -6,13 +6,11 @@ ms.prod: W10
ms.mktglfcycl: explore
ms.sitesec: library
author: brianlic-msft
+ms.pagetype: security
---
# What's new in security auditing?
-
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
@@ -20,47 +18,32 @@ Security auditing is one of the most powerful tools that you can use to maintain
## New features in Windows 10, version 1511
-
- The [WindowsSecurityAuditing](http://go.microsoft.com/fwlink/p/?LinkId=690517) and [Reporting](http://go.microsoft.com/fwlink/p/?LinkId=690525) configuration service providers allow you to add security audit policies to mobile devices.
## New features in Windows 10
-
In Windows 10, security auditing has added some improvements:
-
- [New audit subcategories](#bkmk-auditsubcat)
- [More info added to existing audit events](#bkmk-moreinfo)
### New audit subcategories
In Windows 10, two new audit subcategories were added to the Advanced Audit Policy Configuration to provide greater granularity in audit events:
-
- [Audit Group Membership](../keep-secure/audit-group-membership.md) Found in the Logon/Logoff audit category, the Audit Group Membership subcategory allows you to audit the group membership information in a user's logon token. Events in this subcategory are generated when group memberships are enumerated or queried on the PC where the logon session was created. For an interactive logon, the security audit event is generated on the PC that the user logged on to. For a network logon, such as accessing a shared folder on the network, the security audit event is generated on the PC hosting the resource.
-
When this setting is configured, one or more security audit events are generated for each successful logon. You must also enable the **Audit Logon** setting under **Advanced Audit Policy Configuration\\System Audit Policies\\Logon/Logoff**. Multiple events are generated if the group membership information cannot fit in a single security audit event.
-
- [Audit PNP Activity](../keep-secure/audit-pnp-activity.md) Found in the Detailed Tracking category, the Audit PNP Activity subcategory allows you to audit when plug and play detects an external device.
-
Only Success audits are recorded for this category. If you do not configure this policy setting, no audit event is generated when an external device is detected by plug and play.
-
A PnP audit event can be used to track down changes in system hardware and will be logged on the PC where the change took place. A list of hardware vendor IDs are included in the event.
### More info added to existing audit events
With Windows 10, we've added more info to existing audit events to make it easier for you to put together a full audit trail and come away with the information you need to protect your enterprise. Improvements were made to the following audit events:
-
- [Changed the kernel default audit policy](#bkmk-kdal)
-
- [Added a default process SACL to LSASS.exe](#bkmk-lsass)
-
- [Added new fields in the logon event](#bkmk-logon)
-
- [Added new fields in the process creation event](#bkmk-logon)
-
- [Added new Security Account Manager events](#bkmk-sam)
-
- [Added new BCD events](#bkmk-bcd)
-
- [Added new PNP events](#bkmk-pnp)
### Changed the kernel default audit policy
@@ -70,73 +53,45 @@ In previous releases, the kernel depended on the Local Security Authority (LSA)
### Added a default process SACL to LSASS.exe
In Windows 10, a default process SACL was added to LSASS.exe to log processes attempting to access LSASS.exe. The SACL is L"S:(AU;SAFA;0x0010;;;WD)". You can enable this under **Advanced Audit Policy Configuration\\Object Access\\Audit Kernel Object**.
-
This can help identify attacks that steal credentials from the memory of a process.
### New fields in the logon event
The logon event ID 4624 has been updated to include more verbose information to make them easier to analyze. The following fields have been added to event 4624:
-
1. **MachineLogon** String: yes or no
-
If the account that logged into the PC is a computer account, this field will be yes. Otherwise, the field is no.
-
2. **ElevatedToken** String: yes or no
-
If the account that logged into the PC is an administrative logon, this field will be yes. Otherwise, the field is no. Additionally, if this is part of a split token, the linked login ID (LSAP\_LOGON\_SESSION) will also be shown.
-
3. **TargetOutboundUserName** String
-
**TargetOutboundUserDomain** String
-
The username and domain of the identity that was created by the LogonUser method for outbound traffic.
-
4. **VirtualAccount** String: yes or no
-
If the account that logged into the PC is a virtual account, this field will be yes. Otherwise, the field is no.
-
5. **GroupMembership** String
-
A list of all of the groups in the user's token.
-
6. **RestrictedAdminMode** String: yes or no
-
If the user logs into the PC in restricted admin mode with Remote Desktop, this field will be yes.
-
For more info on restricted admin mode, see [Restricted Admin mode for RDP](http://blogs.technet.com/b/kfalde/archive/2013/08/14/restricted-admin-mode-for-rdp-in-windows-8-1-2012-r2.aspx).
### New fields in the process creation event
The logon event ID 4688 has been updated to include more verbose information to make them easier to analyze. The following fields have been added to event 4688:
-
1. **TargetUserSid** String
-
The SID of the target principal.
-
2. **TargetUserName** String
-
The account name of the target user.
-
3. **TargetDomainName** String
-
The domain of the target user..
-
4. **TargetLogonId** String
-
The logon ID of the target user.
-
5. **ParentProcessName** String
-
The name of the creator process.
-
6. **ParentProcessId** String
-
A pointer to the actual parent process if it's different from the creator process.
### New Security Account Manager events
In Windows 10, new SAM events were added to cover SAM APIs that perform read/query operations. In previous versions of Windows, only write operations were audited. The new events are event ID 4798 and event ID 4799. The following APIs are now audited:
-
- SamrEnumerateGroupsInDomain
- SamrEnumerateUsersInDomain
- SamrEnumerateAliasesInDomain
@@ -153,7 +108,6 @@ In Windows 10, new SAM events were added to cover SAM APIs that perform read/qu
### New BCD events
Event ID 4826 has been added to track the following changes to the Boot Configuration Database (BCD):
-
- DEP/NEX settings
- Test signing
- PCAT SB simulation
@@ -165,14 +119,4 @@ Event ID 4826 has been added to track the following changes to the Boot Configur
### New PNP events
Event ID 6416 has been added to track when an external device is detected through Plug and Play. One important scenario is if an external device that contains malware is inserted into a high-value machine that doesn’t expect this type of action, such as a domain controller.
-
[Learn how to manage your security audit policies within your organization](../keep-secure/security-auditing-overview.md).
-
-
-
-
-
-
-
-
-
diff --git a/windows/whats-new/security.md b/windows/whats-new/security.md
index 49711ce074..d8784f6c41 100644
--- a/windows/whats-new/security.md
+++ b/windows/whats-new/security.md
@@ -2,16 +2,16 @@
title: What's new in Windows 10 security (Windows 10)
description: There are several key client security improvements Microsoft has made in Windows 10.
ms.assetid: 6B8A5F7A-ABD3-416C-87B0-85F68B214C81
-keywords: ["secure", "data loss prevention", "multifactor authentication"]
+keywords: secure, data loss prevention, multifactor authentication
ms.prod: W10
ms.mktglfcycl: explore
ms.sitesec: library
+ms.pagetype: security
author: TrudyHa
---
+
# What's new in Windows 10 security
-
-
There are several key client security improvements Microsoft has made in Windows 10. These improvements focus on three key areas — threat resistance, information protection, and identity protection and access control. In addition to an overview of the features themselves, this article discusses the hardware requirements for each new feature and offers configuration recommendations and links to more detailed resources.
Microsoft designed the Windows 10 operating system to be the most secure version of the Windows operating system to date. To achieve this goal, Windows 10 employs advanced and now widely available hardware features to help protect users and devices against modern cyber threats. With thousands of new malware variants discovered daily and malicious hacking techniques evolving rapidly, never before has Windows client security been more important. In Windows 10, organizations can deploy new threat-resistant security features that harden the operating system in ways that can benefit Bring Your Own Device (BYOD) and corporate-owned device scenarios, as well as devices for special use cases, such as kiosks, ATMs, and point-of-sale (PoS) systems. These new threat-resistant features are modular—that is, they’re designed to be deployed together, although you can also implement them individually. With all these new features enabled together, organizations can protect themselves immediately against a majority of today’s most sophisticated threats and malware.
@@ -22,7 +22,6 @@ Finally, new identity-protection and access control features make it easier to i
## Threat resistance
-
Today’s security threat landscape is one of aggressive and tenacious threats. In previous years, malicious attackers mostly focused on gaining community recognition through their attacks and the personal enjoyment of temporarily taking a system offline. Since then, attacker’s motives have shifted toward monetizing their attacks, which includes holding machines and data hostage until the owners pay the demanded ransom and exploiting the valuable information the attackers discover for monetary gain. Unlike these examples, modern attacks increasingly focus on large-scale intellectual property theft; targeted system degradation that results in financial loss; and now even cyberterrorism that threatens the security of individuals, businesses, and national interests all over the world. These attackers are typically highly trained individuals and security experts, some of whom are in the employ of nation states that have large budgets, seemingly unlimited human resources, and unknown motives. Threats like these require a different approach and mitigations that can meet the challenge.
Windows 10 introduces several new security features that help mitigate modern threats and protect organizations against cyber attackers, regardless of their motive. Microsoft has made significant investments in Windows 10 to make it the most malware-resistant Windows operating system to date. Rather than simply adding defenses to the operating system, as was the case in previous Windows releases, Microsoft introduces architectural changes in Windows 10 that address entire classes of threats. By fundamentally changing the way the operating system works, Microsoft seeks to make Windows 10 much more difficult for modern attackers to exploit. New features in Windows 10 include Device Guard, configurable code integrity, virtualization-based security (VBS), and improvements to Windows Defender, to name just a few. By enabling all these new features together, organizations can immediately protect themselves against the types of malware responsible for approximately 95 percent of modern attacks.
@@ -32,16 +31,12 @@ Windows 10 introduces several new security features that help mitigate modern t
In the server world, virtualization technologies like Microsoft Hyper-V have proven extremely effective in isolating and protecting virtual machines (VMs) in the data center. Now, with those virtualization capabilities becoming more pervasive in modern client devices, there is an incredible opportunity for new Windows client security scenarios. Windows 10 can use virtualization technology to isolate core operating system services in a segregated, virtualized environment, similar to a VM. This additional level of protection, called virtualization-based security, ensures that no one can manipulate those services, even if the kernel mode of the host operating system is compromised.
Just like with client Hyper-V, Windows itself can now take advantage of processors equipped with second-level address translation (SLAT) technology and virtualization extensions, such as Intel Virtualization Technology (VT) x and AMD V, to create a secure execution environment for sensitive Windows functions and data. This VBS environment protects the following services:
-
- **Hypervisor Code Integrity (HVCI).** The HVCI service in Windows 10 determines whether code executing in kernel mode is securely designed and trustworthy. It offers Zero Day and vulnerability exploit protection capabilities by ensuring that all software running in kernel mode, including drivers, securely allocate memory and operate as they are intended. In Windows 10, kernel mode code integrity is configurable, which allows organizations to scope preboot code execution to their desired configuration. For more information about configurable code integrity in Windows 10, see the [Configurable code integrity](#config-code) section.
-
- **Local Security Authority (LSA).** The LSA service in Windows manages authentication operations, including NT LAN Manager (NTLM) and Kerberos mechanisms. In Windows 10, the Credential Guard feature isolates a portion of this service and helps mitigate the pass-the-hash and pass-the-ticket techniques by protecting domain credentials. In addition to logon credentials, this protection is extended to credentials stored within Credential Manager. For more information about Credential Guard, see the [Credential Guard](#credential-guard) section.
-
**Note**
+
To determine whether virtualization is supported for a client machine model, simply run **systeminfo** from a command prompt window.
-
-
VBS provides the core framework for some of the most impactful mitigations Windows 10 offers. Having client machines within your organization that can employ this functionality is crucial to modern threat resistance. For more information about the specific hardware features that each Windows 10 feature requires, including VBS, see the [Windows 10 hardware considerations](#hardware) section.
### Device Guard
@@ -52,12 +47,11 @@ Although Microsoft intends the Device Guard feature set to run alongside new Win
For most organizations, implementing specific Device Guard functionality will depend on the role of the device and its primary user, employing more features on single-workload devices, such as kiosks, and fewer features on administrative machines over which users are allowed full control. By using this model, IT organizations can categorize users into groups that align with Device Guard security policies relating to device security and code integrity restrictions. For more information about configurable code integrity, see the [Configurable code integrity](#config-code) section.
-New desktops and laptops will be available to expedite your Device Guard implementation efforts. Device Guard-ready devices will require the least amount of physical interaction with the actual device before it’s ready for use. Going forward, all devices will fall into one of the following three categories:
+New desktops and laptops will be available to expedite your Device Guard implementation efforts. Device Guard-ready devices will require the least amount of physical interaction with the actual device before it’s ready for use.
+Going forward, all devices will fall into one of the following three categories:
- **Device Guard capable**. These devices will meet all the hardware requirements for Device Guard. You will still need to properly prepare devices with components that require enablement or configuration for Device Guard deployment. Device drivers on the device must be compatible with HVCI and may require updates from the original equipment manufacturer (OEM).
-
- **Device Guard ready**. Device Guard-ready devices will come directly from the OEM with all necessary hardware components and drivers to run Device Guard. In addition, all of these components will be pre-configured and enabled, which minimizes the effort needed to deploy Device Guard. No interaction with the BIOS is necessary to deploy these devices, and you can use Group Policy, System Center Configuration Manager, or Microsoft Intune to manage them.
-
- **Not supported for Device Guard**. Many current devices cannot take advantage of all Device Guard features because they don’t have the required hardware components or HVCI-compatible drivers. However, most of these devices can enable some Device Guard features, such as configurable code integrity.
For more information about how to prepare for, manage, and deploy Device Guard, see the [Device Guard deployment guide](../keep-secure/device-guard-deployment-guide.md).
@@ -67,38 +61,26 @@ For more information about how to prepare for, manage, and deploy Device Guard,
*Code integrity* is the Windows component that verifies that the code Windows is running is trusted and safe. Like the operating modes found in Windows itself, Windows code integrity contains two primary components: kernel mode code integrity (KMCI) and user mode code integrity (UMCI). Microsoft has used KMCI in recent versions of Windows to prevent the Windows kernel from executing unsigned drivers. Although this approach is effective, drivers aren’t the only route malware can take to penetrate the operating system’s kernel mode space. So, for Windows 10, Microsoft has raised the standard for kernel mode code out of the box by requiring the use of security best practices regarding memory management and has provided enterprises with a way to set their own UMCI and KMCI standards.
Historically, UMCI has been available only for Windows RT and Windows Phone devices, which made it difficult for attackers to infect such devices with viruses and malware. This reduced infection rate results from the way the operating system determines which code to execute. Natively, binaries follow a process to prove to the operating system that they are trustworthy before the operating system allows them to execute. This process is intended to restrict the execution of arbitrary code and thereby decrease the risk of malware infection. This successful trust-nothing operating system model is now available in Windows 10 through a feature called *configurable code integrity*.
-
Configurable code integrity allows IT organizations to create and deploy code integrity policies that stipulate exactly which binaries can run in their environment. Administrators can manage this trust at a certification authority or publisher level down to the individual hash values for each executed binary. This level of customization allows organizations to create policies that are as restrictive as they desire. In addition, organizations can choose to provide different levels of restriction for certain types of machines. For example, fixed-workload devices such as kiosks and PoS systems would likely receive a strict policy, because their purpose is to provide the same service day after day. Administrators can manage devices that have more variable workloads, such as users’ PCs, at a higher level, providing certain software publishers’ applications for installation or aligning those devices with the organization’s software catalog.
**Note**
Configurable code integrity is not intended to replace technologies that allow or block programs such as AppLocker or an organization’s antivirus software. Rather, it complements such technologies by establishing a baseline of security, and then using those additional technologies to fine-tune client security.
-
-
Configurable code integrity is not limited to Windows Store applications. In fact, it is not even limited to existing signed applications. Windows 10 gives you a way to sign line-of-business or third-party applications without having to repackage them: you can monitor the application’s installation and initial execution to create a list of binaries called a catalog file. When created, you sign these catalog files and add the signing certificate to the code integrity policy so that those binaries contained within the catalog files are allowed to execute. Then, you can use Group Policy, Configuration Manager, or any other familiar management tool to distribute these catalog files to your client machines. Historically, most malware has been unsigned; simply by deploying code integrity policies, your organization can immediately protect itself against unsigned malware, which is responsible for most modern attacks.
**Note**
For detailed deployment and planning information about configurable code integrity, see the [Device Guard deployment guide](../keep-secure/device-guard-deployment-guide.md).
-
-
The process to create, test, and deploy a code integrity policy is as follows:
-
1. **Create a code integrity policy.** Use the Windows PowerShell cmdlet **New-CIPolicy**, available in Windows 10, to create a new code integrity policy. This cmdlet scans a PC for all listings of a specific policy level. For example, if you set the rule level to **Hash**, the cmdlet would add hash values for all discovered binaries to the policy that resulted from the scan. When you enforce and deploy the policy, this list of hash values determines exactly which binaries are allowed to run on the machines that receive the policy. Code integrity policies can contain both a kernel mode and user mode execution policy, restricting what can run in either or both modes. Finally, when created, this policy is converted to binary format so that the managed client can consume it when the policy is copied to the client’s code integrity folder.
-
2. **Audit the code integrity policy for exceptions.** When you first create a code integrity policy, audit mode is enabled by default so that you can simulate the effect of a code integrity policy without actually blocking the execution of any binaries. Instead, policy exceptions are logged in the CodeIntegrity event log so that you can add the exceptions to the policy later. Be sure to audit any policy to discover potential issues before you deploy it.
-
3. **Merge the audit results with the existing policy.** After you have audited a policy, you can use the audit events to create an additional code integrity policy. Because each machine processes just one code integrity policy, you must merge the file rules within this new code integrity policy with the original policy. To do so, run the **Merge-CIPolicy** cmdlet, which is available in Windows 10 Enterprise.
-
4. **Enforce and sign the policy.** After you create, audit, and merge the resulting code integrity policies, it’s time to enforce your policy. To do so, run the **Set-RuleOption** cmdlet to remove the **Unsigned Policy** rule. When enforced, no binaries that are exceptions to the policy will be allowed to run. In addition to enforcing a policy, signed policies offer an additional level of protection. Signed code integrity policies inherently protect themselves against manipulation and deletion, even by administrators.
-
5. **Deploy the code integrity policy.** When you have enforced and optionally signed your code integrity policy, it’s ready for deployment. To deploy your code integrity policies, you can use Microsoft client management technologies, mobile device management solutions, or Group Policy, or you can simply copy the file to the correct location on your client computers. For Group Policy deployment, a new administrative template is available in Windows 10 and the Windows Server 2016 operating system to simplify the deployment process.
**Note**
Configurable code integrity is available in Windows 10 Enterprise and Windows 10 Education.
-
-
You can enable configurable code integrity as part of a Device Guard deployment or as a stand-alone component. In addition, you can run configurable code integrity on hardware that is compatible with the Windows 7 operating system, even if such hardware is not Device Guard ready. Code integrity policies can align with an existing application catalog, existing corporate imaging strategy, or with any other method that provides the organization’s desired levels of restriction. For more information about configurable code integrity with Device Guard, see the [Device Guard deployment guide](../keep-secure/device-guard-deployment-guide.md).
### Measured Boot and remote attestation
@@ -114,18 +96,13 @@ Measured Boot by itself does not prevent malware from loading during the startup
For Windows 10, Microsoft has revamped Windows Defender and combined it with Microsoft System Center Endpoint Protection. Unlike with Microsoft System Center 2012 R2, there will be no System Center Endpoint Protection client to deploy to Windows 10 machines because Windows Defender is built into the operating system and enabled by default.
In addition to simplified deployment, Windows Defender contains several improvements. The most important improvements to Windows Defender are:
-
- **Early Launch Antimalware (ELAM) compatible.** After Secure Boot has verified that the loading operating system is trusted, ELAM can start a registered and signed antimalware application before any other operating system components. Windows Defender is compatible with ELAM.
-
- **Local context for detections and centralized sensory data.** Unlike most antimalware software and previous versions of Windows Defender, Windows Defender in Windows 10 reports additional information about the context of discovered threats. This information includes the source of the content that contains the threat as well as the historical movement of the malware throughout the system. When collection is complete, Windows Defender reports this information (when users elect to enable cloud-based protection) and uses it to mitigate threats more quickly.
-
- **User Account Control (UAC) integration.** Windows Defender is now closely integrated with the UAC mechanism in Windows 10. Whenever a UAC request is made, Windows Defender automatically scans the threat before prompting the user, which helps prevent users from providing elevated privileges to malware.
-
- **Simplified management.** In Windows 10, you can manage Windows Defender much more easily than ever before. Manage settings through Group Policy, Intune, or Configuration Manager.
## Information protection
-
Protecting the integrity of company data as well as preventing the inappropriate disclosure and sharing of that data are a top priority for IT organizations. Trends like BYOD and mobility make the task of information protection more challenging than ever before. Windows 10 includes several improvements to built-in information protection, including a new Enterprise Data Protection (EDP) feature that offers DLP capability. This feature allows an organizations’ users to classify data themselves and gives you the ability to automatically classify data as it ingresses from business resources. It can also help prevent users from copying business content to unauthorized locations such as personal documents or websites.
Unlike some current DLP solutions, EDP does not require users to switch modes or apps or work within containers to protect data, and the protection happens behind the scenes without altering the user experience that your users have grown accustomed to in Windows. For more information about EDP in Windows 10, see the [Enterprise Data Protection](#enterprise) section.
@@ -145,18 +122,13 @@ To manage EDP, you use the same system management tools you probably already use
With so many laptops stolen annually, protecting data at rest should be a top priority for any IT organization. Microsoft has provided an encryption solution called BitLocker directly in Windows since 2004. If your last encounter with BitLocker was in Windows 7, you’ll find that the manageability and SSO capabilities that were previously lacking are now included in Windows 10. These and other improvements make BitLocker one of the best choices on the marketplace for protecting data on Windows devices. Windows 10 builds on the BitLocker improvements made in the Windows 8.1 and Windows 8 operating systems to make BitLocker more manageable and to simplify its deployment even further.
Microsoft has made the following key improvements to BitLocker:
-
- **Automatic drive encryption through Device Encryption.** By default, BitLocker is automatically enabled on clean installations of Windows 10 if the device has passed the Device Encryption Requirements test from the Windows Hardware Certification Kit. Many Windows 10–compatible PCs will meet this requirement. This version of BitLocker is called Device Encryption. Whenever devices on which Drive Encryption is enabled join your domain, the encryption keys can be escrowed in either Active Directory or MBAM.
-
- **MBAM improvements.** MBAM provides a simplified management console for BitLocker administration. It also simplifies recovery requests by providing a self-service portal in which users can recover their drives without calling the help desk.
-
- **SSO.** BitLocker for Windows 7 often required the use of a pre-boot PIN to access the protected drive’s encryption key and allow Windows to start. In Windows 10, user input-based preboot authentication (in other words, a PIN) is not required because the TPM maintains the keys. In addition, modern hardware often mitigates the cold boot attacks (for example, port-based direct memory access attacks) that have previously necessitated PIN protection. For more information to determine which cases and device types require the use of PIN protection, refer to [BitLocker Countermeasures](../keep-secure/bitlocker-countermeasures.md).
-
- **Used-space-only encryption.** Rather than encrypting an entire hard drive, you can configure BitLocker to encrypt only the used space on a drive. This option drastically reduces the overall encryption time required.
## Identity protection and access control
-
User credentials are vital to the overall security of an organization’s domain. Until Windows 10, user name-password combinations were the primary way for a person to prove his or her identity to a machine or system. Unfortunately, passwords are easily stolen, and attackers can use them remotely to spoof a user’s identity. Some organizations deploy public key infrastructure (PKI)-based solutions, like smart cards, to address the weaknesses of passwords. Because of the complexity and costs associated with these solutions, however, they’re rarely deployed and, even when they are used, frequently used only to protect top-priority assets such as the corporate VPN. Windows 10 introduces new identity-protection and access control features that address the weaknesses of today’s solutions and can effectively remove the need for user passwords in an organization.
Windows 10 also includes a feature called Microsoft Passport, a new 2FA mechanism built directly into the operating system. The two factors of authentication include a combination of something you know (for example, a PIN), something you have (for example, your PC, your phone), or something about the user (for example, biometrics). With Microsoft Passport enabled, when you log on to a computer, Microsoft Passport is responsible for brokering user authentication around the network, providing the same SSO experience with which you’re familiar. For more information about Microsoft Passport, see the [Microsoft Passport](#passport) section.
@@ -176,17 +148,12 @@ Microsoft Passport can use the biometric information from Windows Hello or a uni
In Windows 10, the physical factor of authentication is the user’s device—either his or her PC or mobile phone. By using the new phone sign-in capability which will available to Windows Insiders as a preview in early 2016, users can unlock their PC without ever touching it. Users simply enroll their phone with Microsoft Passport by pairing it with the PC via Wi-Fi or Bluetooth and install a simple-to-use application on their phone that allows them to select which PC to unlock. When selected, users can enter a PIN or their biometric login from their phone to unlock their PC.
### Windows Hello
-
Passwords represent a losing identity and access control mechanism. When an organization relies on password-driven Windows authentication, attackers only have to determine a single string of text to access anything on a corporate network that those credentials protect. Unfortunately, attackers can use several methods to retrieve a user’s password, making credential theft relatively easy for determined attackers. By moving to an MFA mechanism to verify user identities, organizations can remove the threats that single-factor options like passwords represent.
Windows Hello is the enterprise-grade biometric integration feature in Windows 10. This feature allows users to use their face, iris, or fingerprint rather than a password to authenticate. Although biometric logon capabilities have been around since the Windows XPoperating system, they have never been as easy, seamless, and secure as they are in Windows 10. In previous uses of biometrics in Windows, the operating system used the biometric information only to unlock the device; then, behind the scenes the user’s traditional password was used to access resources on the organization’s network. Also, the IT organization had to run additional software to configure the biometric devices to log in to Windows or applications. Windows Hello is integrated directly into the operating system and so doesn’t require additional software to function. However, as with any other biometrics-based login, Windows Hello requires specific hardware to function:
-
- **Facial recognition.** To establish facial recognition, Windows Hello uses special infrared (IR) cameras and anti-spoofing technology to reliably tell the difference between a photograph and a living person. This requirement ensures that no one can take a person’s PC and spoof his or her identity simply by obtaining a high-definition picture. Many manufacturers already offer PC models that include such cameras and are therefore compatible with Windows Hello. For those machines that don’t currently include these special cameras, several external cameras are available.
-
- **Fingerprint recognition.** Fingerprint sensors already exist in a large percentage of consumer and business PCs. Most of them (whether external or integrated into laptops or USB keyboards) work with Windows Hello. The detection and anti-spoofing technology available in Windows 10 is much more advanced than in previous versions of Windows, making it more difficult for attackers to deceive the operating system.
-
- **Iris recognition.** Like facial recognition, iris-based recognition uses special IR cameras and anti-spoofing technology to reliably tell the difference between the user’s iris and an impostor. Iris recognition will be available in mobile devices by the end of 2016 but is also available for independent hardware vendors and OEMs to incorporate into PCs.
-
With Windows Hello in conjunction with Microsoft Passport, users have the same SSO experience they would if they logged on with domain credentials: they simply use biometrics, instead. In addition, because no passwords are involved, users won’t be calling the help desk saying that they have forgotten their password. For an attacker to spoof a user’s identity, he or she would have to have physical possession of both the user and the device on which the user is set up for Windows Hello. From a privacy perspective, organizations can rest assured that the biometric data Windows Hello uses is not centrally stored; can’t be converted to images of the user’s fingerprint, face, or iris; and is designed never to leave the device. In the end, Windows Hello and Microsoft Passport can completely remove the necessity for passwords for Azure AD and hybrid Azure AD/Active Directory environments and the apps and web services that depend on them for identity services. For more information about Microsoft Passport, see the [Microsoft Passport](#passport) section.
### Credential Guard
@@ -196,19 +163,14 @@ Pass the hash is the most commonly used derived credential attack today. This at
Credential Guard is another new feature in Windows 10 Enterprise that employs VBS to protect domain credentials against theft, even when the host operating system is compromised. To achieve such protection, Credential Guard isolates a portion of the LSA service, which is responsible for managing authentication, inside a virtualized container. This container is similar to a VM running on a hypervisor but is extremely lightweight and contains only those files and components required to operate the LSA and other isolated services. By isolating a portion of the LSA service within this virtualized environment, credentials are protected even if the system kernel is compromised, removing the attack vector for pass the hash.
For more information about the hardware requirements for Credential Guard, see the [Windows 10 hardware considerations](#hardware) section. For more information about VBS in Windows 10, see the [Virtualization-based security](#virtualization-security) section.
-
**Note**
Because it requires isolated user mode and a Hyper-V hypervisor, you cannot configure Credential Guard on a VM, only on a physical computer.
-
-
The Credential Guard feature is targeted at resisting the use of pass-the-hash and pass-the-ticket techniques. By employing a MFA option such as Microsoft Passport with Credential Guard, you can gain additional protection against such threats. For more in-depth information about how Credential Guard works and the specific mitigations it provides, see [Protect derived domain credentials with Credential Guard](../keep-secure/credential-guard.md).
## Windows 10 hardware considerations
-
Most of the features this article describes rely on specific hardware to maximize their capabilities. By purchasing hardware that includes these features during your next purchase cycle, you will be able to take advantage of the most comprehensive client security package Windows 10 has to offer. Careful consideration about which hardware vendor and specific models to purchase is vital to the success of your organization’s client security portfolio. Table 1 contains a list of each new Windows 10 security feature and its hardware requirements.
-
Table 1. Windows 10 hardware requirements
| Windows 10 feature | TPM | Input/output memory management unit | Virtualization extensions | SLAT | UEFI 2.3.1 | x64 architecture only |
@@ -222,36 +184,17 @@ Table 1. Windows 10 hardware requirements
| VBS | N | Y | Y | Y | N | Y |
| UEFI Secure Boot | R | N | N | N | Y | N |
| Device health attestation through Measured Boot | Y\* | N | N | N | Y | Y |
-
-
\* Requires use of TPM 2.0.
-
**Note**
In this table, **R** stands for *recommended*, **Y** means that the hardware component is *required* for that Windows 10 feature, and **N** means that the hardware component is *not used* with that Windows 10 feature.
-
-
## Related topics
-
-
[Windows 10 Specifications](http://go.microsoft.com/fwlink/p/?LinkId=717550)
-
[Making Windows 10 More Personal and More Secure with Windows Hello](http://go.microsoft.com/fwlink/p/?LinkId=717551)
-
[Protect BitLocker from pre-boot attacks](../keep-secure/protect-bitlocker-from-pre-boot-attacks.md)
-
[BitLocker Countermeasures](../keep-secure/bitlocker-countermeasures.md)
-
[Device Guard deployment guide](../keep-secure/device-guard-deployment-guide.md)
-
[Protect derived domain credentials with Credential Guard](../keep-secure/credential-guard.md)
-
-
-
-
-
-
-
diff --git a/windows/whats-new/trusted-platform-module.md b/windows/whats-new/trusted-platform-module.md
index e1ba634071..34233ef3a4 100644
--- a/windows/whats-new/trusted-platform-module.md
+++ b/windows/whats-new/trusted-platform-module.md
@@ -5,14 +5,13 @@ ms.assetid: CE8BBC2A-EE2D-4DFA-958E-2A178F2E6C44
ms.prod: W10
ms.mktglfcycl: explore
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# What's new in Trusted Platform Module?
-
**Applies to**
-
- Windows 10
- Windows 10 Mobile
@@ -20,14 +19,11 @@ This topic for the IT professional describes new features for the Trusted Platfo
## New features in Windows 10, version 1511
-
- Key Storage Providers (KSPs) and srvcrypt support elliptical curve cryptography (ECC).
## New features in Windows 10
-
The following sections describe the new and changed functionality in the TPM for Windows 10:
-
- [Device health attestation](#bkmk-dha)
- [Microsoft Passport](microsoft-passport.md) support
- [Device Guard](device-guard-overview.md) support
@@ -35,26 +31,14 @@ The following sections describe the new and changed functionality in the TPM for
## Device health attestation
-
Device health attestation enables enterprises to establish trust based on hardware and software components of a managed device. With device heath attestation, you can configure an MDM server to query a health attestation service that will allow or deny a managed device access to a secure resource.
-
Some things that you can check on the device are:
-
- Is Data Execution Prevention supported and enabled?
- Is BitLocker Drive Encryption supported and enabled?
- Is SecureBoot supported and enabled?
-**Note** The device must be running Windows 10 and it must support at least TPM 2.0.
-
+> **Note** The device must be running Windows 10 and it must support at least TPM 2.0.
-
[Learn how to deploy and manage TPM within your organization](../keep-secure/trusted-platform-module-overview.md).
-
-
-
-
-
-
-
diff --git a/windows/whats-new/user-account-control.md b/windows/whats-new/user-account-control.md
index 1133a6ea3b..0b655fc120 100644
--- a/windows/whats-new/user-account-control.md
+++ b/windows/whats-new/user-account-control.md
@@ -5,14 +5,13 @@ ms.assetid: 9281870C-0819-4694-B4F1-260255BB8D07
ms.prod: W10
ms.mktglfcycl: explore
ms.sitesec: library
+ms.pagetype: security
author: brianlic-msft
---
# What's new in User Account Control?
-
**Applies to**
-
- Windows 10
User Account Control (UAC) helps prevent malware from damaging a computer and helps organizations deploy a better-managed desktop environment.
@@ -25,16 +24,8 @@ In Windows 10, User Account Control has added some improvements.
## New features in Windows 10
-
- **Integration with the Antimalware Scan Interface (AMSI)**. The [AMSI](http://msdn.microsoft.com/library/windows/desktop/dn889587.aspx) scans all UAC elevation requests for malware. If malware is detected, the admin privilege is blocked.
[Learn how to manage User Account Control within your organization](../keep-secure/user-account-control-overview.md).
-
-
-
-
-
-
-