deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-13 13:57:22 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'refs/remotes/origin/master' into live

Browse Source
This commit is contained in:
LizRoss 2016-05-25 10:51:26 -07:00
commit 9dc7943e84
117 changed files with 4286 additions and 3777 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
devices/surface/advanced-uefi-security-features-for-surface.md
View File

@ -2,9 +2,10 @@
title: Advanced UEFI security features for Surface (Surface)
description: 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.
ms.assetid: 90F790C0-E5FC-4482-AD71-60589E3C9C93
keywords: ["Surface, Surface Pro 3, security, features, configure, hardware, device, custom, script, update"]
ms.prod: W10
keywords: security, features, configure, hardware, device, custom, script, update
ms.prod: w10
ms.mktglfcycl: manage
ms.pagetype: surface, devices, security
ms.sitesec: library
author: miladCA
---

5
devices/surface/customize-the-oobe-for-surface-deployments.md
View File

@ -2,9 +2,10 @@
title: Customize the OOBE for Surface deployments (Surface)
description: This article will walk you through the process of customizing the Surface out-of-box experience for end users in your organization.
ms.assetid: F6910315-9FA9-4297-8FA8-2C284A4B1D87
keywords: ["deploy, customize, automate, deployment, network, Pen, pair, boot"]
ms.prod: W10
keywords: deploy, customize, automate, network, Pen, pair, boot
ms.prod: w10
ms.mktglfcycl: deploy
ms.pagetype: surface, devices
ms.sitesec: library
author: jobotto
---

5
devices/surface/deploy-the-latest-firmware-and-drivers-for-surface-devices.md
View File

@ -2,9 +2,10 @@
title: Download the latest firmware and drivers for Surface devices (Surface)
description: This article provides a list of the available downloads for Surface devices and links to download the drivers and firmware for your device.
ms.assetid: 7662BF68-8BF7-43F7-81F5-3580A770294A
keywords: ["update Surface, newest, latest, download, firmware, driver, tablet, hardware, device"]
ms.prod: W10
keywords: update Surface, newest, latest, download, firmware, driver, tablet, hardware, device
ms.prod: w10
ms.mktglfcycl: deploy
ms.pagetype: surface, devices
ms.sitesec: library
author: jobotto
---

3
devices/surface/enable-peap-eap-fast-and-cisco-leap-on-surface-devices.md
View File

@ -2,9 +2,10 @@
title: Enable PEAP, EAP-FAST, and Cisco LEAP on Surface devices (Surface)
description: Find out how to enable support for PEAP, EAP-FAST, or Cisco LEAP protocols on your Surface device.
ms.assetid: A281EFA3-1552-467D-8A21-EB151E58856D
keywords: ["network", "wireless", "device", "deploy", "authenticaion", "protocol"]
keywords: network, wireless, device, deploy, authentication, protocol
ms.prod: w10
ms.mktglfcycl: deploy
ms.pagetype: surface, devices
ms.sitesec: library
author: miladCA
---

5
devices/surface/ethernet-adapters-and-surface-device-deployment.md
View File

@ -2,9 +2,10 @@
title: Ethernet adapters and Surface deployment (Surface)
description: This article provides guidance and answers to help you perform a network deployment to Surface devices.
ms.assetid: 5273C59E-6039-4E50-96B3-426BB38A64C0
keywords: ["ethernet, deploy, removable, network, connectivity, boot, firmware, device, adapter, PXE boot, USB"]
ms.prod: W10
keywords: ethernet, deploy, removable, network, connectivity, boot, firmware, device, adapter, PXE boot, USB
ms.prod: w10
ms.mktglfcycl: deploy
ms.pagetype: surface, devices
ms.sitesec: library
author: jobotto
---

3
devices/surface/index.md
View File

@ -2,8 +2,9 @@
title: Surface (Surface)
description: .
ms.assetid: 2a6aec85-b8e2-4784-8dc1-194ed5126a04
ms.prod: W10
ms.prod: w10
ms.mktglfcycl: manage
ms.pagetype: surface, devices
ms.sitesec: library
author: heatherpoulsen
---

4
devices/surface/manage-surface-dock-firmware-updates.md
View File

@ -2,8 +2,10 @@
title: Manage Surface Dock firmware updates (Surface)
description: Read about the different methods you can use to manage the process of Surface Dock firmware updates.
ms.assetid: 86DFC0C0-C842-4CD1-A2D7-4425471FFE3F
ms.prod: W10
keywords: firmware, update, install, drivers
ms.prod: w10
ms.mktglfcycl: manage
ms.pagetype: surface, devices
ms.sitesec: library
author: jobotto
---

5
devices/surface/manage-surface-pro-3-firmware-updates.md
View File

@ -2,9 +2,10 @@
title: Manage Surface driver and firmware updates (Surface)
description: This article describes the available options to manage firmware and driver updates for Surface devices.
ms.assetid: CD1219BA-8EDE-4BC8-BEEF-99B50C211D73
keywords: ["Surface, Surface Pro 3, firmware, update, device, manage, deploy, driver, USB"]
ms.prod: W10
keywords: Surface, Surface Pro 3, firmware, update, device, manage, deploy, driver, USB
ms.prod: w10
ms.mktglfcycl: manage
ms.pagetype: surface, devices
ms.sitesec: library
author: jobotto
---

5
devices/surface/microsoft-surface-data-eraser.md
View File

@ -2,9 +2,10 @@
title: Microsoft Surface Data Eraser (Surface)
description: Find out how the Microsoft Surface Data Eraser tool can help you securely wipe data from your Surface devices.
ms.assetid: 8DD3F9FE-5458-4467-BE26-E9200341CF10
keywords: ["tool", "USB", "data", "erase"]
ms.prod: W10
keywords: tool, USB, data, erase
ms.prod: w10
ms.mktglfcycl: manage
ms.pagetype: surface, devices, security
ms.sitesec: library
author: miladCA
---

5
devices/surface/microsoft-surface-deployment-accelerator.md
View File

@ -2,9 +2,10 @@
title: Microsoft Surface Deployment Accelerator (Surface)
description: Microsoft Surface Deployment Accelerator provides a quick and simple deployment mechanism for organizations to reimage Surface devices.
ms.assetid: E7991E90-4AAE-44B6-8822-58BFDE3EADE4
keywords: ["deploy", "install", "tool"]
ms.prod: W10
keywords: deploy, install, tool
ms.prod: w10
ms.mktglfcycl: deploy
ms.pagetype: surface, devices
ms.sitesec: library
author: miladCA
---

5
devices/surface/step-by-step-surface-deployment-accelerator.md
View File

@ -2,9 +2,10 @@
title: Step by step Surface Deployment Accelerator (Surface)
description: This article shows you how to install Microsoft Surface Deployment Accelerator (SDA), configure a deployment share for the deployment of Windows to Surface devices, and perform a deployment to Surface devices.
ms.assetid: A944FB9C-4D81-4868-AFF6-B9D1F5CF1032
keywords: ["deploy, configure"]
ms.prod: W10
keywords: deploy, configure
ms.prod: w10
ms.mktglfcycl: deploy
ms.pagetype: surface, devices
ms.sitesec: library
author: miladCA
---

197
devices/surface/surface-diagnostic-toolkit.md
View File

@ -2,9 +2,10 @@
title: Microsoft Surface Diagnostic Toolkit (Surface)
description: Find out how you can use the Microsoft Surface Diagnostic Toolkit to test the hardware of your Surface device.
ms.assetid: FC4C3E76-3613-4A84-A384-85FE8809BEF1
keywords: ["hardware, device, tool, test, component"]
ms.prod: W8
keywords: hardware, device, tool, test, component
ms.prod: w10
ms.mktglfcycl: manage
ms.pagetype: surface, devices
ms.sitesec: library
author: miladCA
---
@ -18,19 +19,19 @@ The [Microsoft Surface Diagnostic Toolkit](http://go.microsoft.com/fwlink/p/?Lin
>**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
- Surface Book
- Surface Pro 4
- Surface Pro 4
- Surface 3 LTE
- Surface 3 LTE
- Surface 3
- Surface 3
- Surface Pro 3
- Surface Pro 3
- Surface Pro 2
- Surface Pro 2
- Surface Pro
- 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.)
@ -38,299 +39,263 @@ Running the Microsoft Surface Diagnostic Toolkit is a hands-on activity. The tes
To run a full set of tests with the Microsoft Surface Diagnostic Toolkit, you should be prepared with the following items:
- An external display with the appropriate HDMI or DisplayPort connection
- An external display with the appropriate HDMI or DisplayPort connection
- A Bluetooth device that can be put into pairing mode
- A Bluetooth device that can be put into pairing mode
- A MicroSD or SD card that is compatible with your Surface device
- A MicroSD or SD card that is compatible with your Surface device
- A Surface Pen
- A Surface Pen
- Room to move the Surface device around
- Room to move the Surface device around
- External speakers or headphones
- 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.
 
## <a href="" id="the-tests--"></a>The tests
## The tests
The Microsoft Surface Diagnostic Toolkit runs several individual tests on a Surface device. Not all tests are applicable to every device. For example, the Home button test is not applicable to Surface Pro 4 where there is no Home button. You can specify which tests to run, or you can choose to run all tests. For tests that require external devices (such as testing output to an external display) but you do not have the required external device at the time of the test, you are given the option to skip the test. If a test fails, you are prompted to continue or stop testing at that time.
### Windows Update
#### Windows Update
This test checks for any outstanding Windows updates and will prompt you to install those updates before you proceed to other tests. It is important to keep a Surface device up to date with the latest Windows updates, including drivers and firmware for the Surface device. The success of some of the tests that are performed later in the task sequence depend on these updated drivers and firmware. You will be prompted to restart the device if required by Windows Update. If you must restart the device, you will need to start the Microsoft Surface Diagnostic Toolkit again.
### <a href="" id="device-information--"></a>Device information
#### Device information
This test reads the Device ID and serial number in addition to basic system information such as device model, operating system version, processor, memory, and storage. The Device ID is recorded in the name of the log file and can be used to identify a log file for a specific device. Several system log files are also collected, including update and rollback logs, and output from several Windows built-in tools, such as [DirectX Diagnostics](http://go.microsoft.com/fwlink/p/?LinkId=746476) and [System Information](http://go.microsoft.com/fwlink/p/?LinkId=746477), power configuration, disk health, and event logs. See the following list for a full set of collected log files:
- Output of **Get-WindowsUpdateLog** if the operating system is Windows 10
- Output of **Get-WindowsUpdateLog** if the operating system is Windows 10
- **%windir%\\Logs**
- **%windir%\\Logs**
- **%windir%\\Panther**
- **%windir%\\Panther**
- **%windir%\\System32\\sysprep\\Panther**
- **%windir%\\System32\\sysprep\\Panther**
- **%windir%\\System32\\WinEvt\\Logs**
- **%windir%\\System32\\WinEvt\\Logs**
- **$windows.~bt\\Sources\\Panther**
- **$windows.~bt\\Sources\\Panther**
- **$windows.~bt\\Sources\\Rollback**
- **$windows.~bt\\Sources\\Rollback**
- **%windir%\\System32\\WinEvt\\Logs**
- **%windir%\\System32\\WinEvt\\Logs**
- Output of **dxdiag.exe /t**
- Output of **dxdiag.exe /t**
- Output of **msinfo32.exe /report**
- Output of **msinfo32.exe /report**
- Output of **powercfg.exe /batteryreport**
- Output of **powercfg.exe /batteryreport**
- Output of **powercfg.exe /sleepstudy**
- Output of **powercfg.exe /sleepstudy**
- Output of **wevtutil.exe epl System**
- Output of **wevtutil.exe epl System**
- Events from:
- Events from:
- **Chkdsk**
- **Chkdsk**
- **Microsoft-Windows-Ntfs**
- **Microsoft-Windows-Ntfs**
- **Microsoft-Windows-WER-SystemErrorReporting**
- **Microsoft-Windows-WER-SystemErrorReporting**
- **Microsoft-Windows-Startuprepair**
- **Microsoft-Windows-Startuprepair**
- **Microsoft-Windows-kernel-Power**
- **Microsoft-Windows-kernel-Power**
- Output of **powercfg.exe /q**
- Output of **powercfg.exe /q**
- Output of **powercfg.exe /qh**
- Output of **powercfg.exe /qh**
- **%windir%\\Inf\\SetupApi\*.log**
- **%windir%\\Inf\\SetupApi\*.log**
These files and logs are stored in a .zip file saved by the Microsoft Surface Diagnostic Toolkit when all selected tests have completed alongside the Microsoft Surface Diagnostic Toolkit log file.
### <a href="" id="type-cover--test"></a>Type Cover test
#### Type Cover test
>**Note:**&nbsp;&nbsp;A Surface Type Cover is required for this test.
 
If a Surface Type Cover is not detected, the test prompts you to connect the Type Cover. When a Type Cover is detected the test prompts you to use the keyboard and touchpad. The cursor should move while you swipe the touchpad, and the keyboard Windows key should bring up the Start menu or Start screen to successfully pass this test. You can skip this test if a Type Cover is not used with the Surface device.
### Integrated keyboard test
#### Integrated keyboard test
>**Note:**&nbsp;&nbsp;This test is only applicable to Surface Book and requires that the Surface Book be docked to the keyboard.
 
This test is essentially the same as the Type Cover test, except the integrated keyboard in the Surface Book base is tested rather than the Type Cover. Move the cursor and use the Windows key to bring up the Start menu to confirm that the touchpad and keyboard are operating successfully. This test will display the status of cursor movement and keyboard input for you to verify. Press **ESC** to complete the test.
### Canvas mode battery test
#### Canvas mode battery test
>**Note:**&nbsp;&nbsp;This test is only applicable to Surface Book.
 
Depending on which mode Surface Book is in, different batteries are used to power the device. When Surface Book is in clipboard mode (detached form the keyboard) it uses an internal battery, and when it is connected in either laptop mode or canvas mode it uses different connections to the battery in the keyboard. In canvas mode, the screen is connected to the keyboard so that when the device is closed, the screen remains face-up and visible. Connect the Surface Book to the keyboard in this manner for the test to automatically proceed.
### Clipboard mode battery test
#### Clipboard mode battery test
>**Note:**&nbsp;&nbsp;This test is only applicable to Surface Book.
 
Disconnect the Surface Book from the keyboard to work in clipboard mode. In clipboard mode the Surface Book operates from an internal battery that is tested when the Surface Book is disconnected from the keyboard. Disconnecting the Surface Book from the keyboard will also disconnect the Surface Book from power and will automatically begin this test.
### Laptop mode battery test
#### Laptop mode battery test
>**Note:**&nbsp;&nbsp;This test is only applicable to Surface Book.
 
Connect the Surface Book to the keyboard in the opposite fashion to canvas mode in laptop mode. In laptop mode the screen will face you when the device is open and the device can be used in the same way as any other laptop. Disconnect AC Power from the laptop base when prompted for this test to check the battery status.
### <a href="" id="battery--test"></a>Battery test
#### Battery test
In this test the battery is discharged for a few seconds and tested for health and estimated runtime. You are prompted to disconnect the power adapter and then to reconnect the power adapter when the test is complete.
### Discrete graphics (dGPU) test
#### Discrete graphics (dGPU) test
>**Note:**&nbsp;&nbsp;This test is only applicable to Surface Book models with a discrete graphics processor.
 
This test will query the device information of current hardware to check for the presence of both the Intel integrated graphics processor in the Surface Book and the NVIDIA discrete graphics processor in the Surface Book keyboard. The keyboard must be attached for this test to function.
### Discrete graphics (dGPU) fan test
#### Discrete graphics (dGPU) fan test
>**Note:**&nbsp;&nbsp;This test is only applicable to Surface Book models with a discrete graphics processor.
 
The discrete graphics processor in the Surface Book includes a separate cooling fan. The fan is turned on automatically by the test for 5 seconds. Listen for the sound of the fan in the keyboard and report if the fan is working correctly when prompted.
### Muscle wire test
#### Muscle wire test
>**Note:**&nbsp;&nbsp;This test is only applicable to Surface Book.
 
To disconnect the Surface Book from the keyboard, software must instruct the muscle wire latch mechanism to open. This is typically accomplished by pressing and holding the undock key on the keyboard. This test sends the same signal to the latch, which unlocks the Surface Book from the Surface Book keyboard. Remove the Surface Book from the keyboard when you are prompted to do so.
### Dead pixel and display artifacts tests
#### Dead pixel and display artifacts tests
>**Note:**&nbsp;&nbsp;Before you run this test, be sure to clean the screen of dust or smudges.
 
This test prompts you to view the display in search of malfunctioning pixels. The test displays full-screen, single-color images including black, white, red, green, and blue. Pixels that remain bright or dark when the screen displays an image of a different color indicate a failed test. You should also look for distortion or variance in the color of the screen.
### <a href="" id="digitizer-edges--"></a>Digitizer edges
#### Digitizer edges
The touchscreen of a Surface device should detect when a user swipes in from the left or right side of the screen. This test prompts you to swipe in from the edges of the screen to bring up the Action Center and Task View. Both Action Center and Task View should launch to pass this test.
### <a href="" id="digitizer-pinch--"></a>Digitizer pinch
#### Digitizer pinch
The pinch gesture (when you bring two fingers closer together or farther apart) is used to manipulate zoom and to position content through the touchscreen. This test displays an image in Windows Picture Viewer and prompts you to zoom in, move, and zoom out of the picture. The picture should zoom in, move, and zoom out as the gestures are performed.
### <a href="" id="digitizer-touch--"></a>Digitizer touch
#### Digitizer touch
The Surface touchscreen should detect input across the entire screen of the device equally. To perform this test a series of lines are displayed on the screen for you to trace with a finger in search of unresponsive areas. The lines traced across the screen should appear continuous for the length of the line as drawn with your finger.
### <a href="" id="digitizer-pen--test"></a>Digitizer pen test
#### Digitizer pen test
>**Note:**&nbsp;&nbsp;A Microsoft Surface Pen is required for this test.
 
This test displays the same lines as those that are displayed during the Digitizer Touch test, but your input is performed with a Surface Pen instead of your finger. The lines should remain unbroken for as long as the Pen is pressed to the screen. Trace all of the lines in the image to look for unresponsive areas across the entire screen of the Surface device.
### <a href="" id="digitizer-multi-touch--"></a>Digitizer multi touch
#### Digitizer multi touch
The Surface touchscreen is capable of detecting 10 fingers simultaneously. Place all of your fingers on the screen simultaneously to perform this test. The screen will show the number of points detected, which should match the number of fingers you have on the screen.
### <a href="" id="home-button-test--"></a>Home button test
#### Home button test
The Home button or Windows button on your Surface device is used to bring up the Start screen or Start menu. This test is successful if the Start screen or Start menu is displayed when the Windows button is pressed. This test is not displayed on Surface Pro 4 because no Windows button exists.
### <a href="" id="volume-rocker--test"></a>Volume rocker test
#### Volume rocker test
This test prompts you to use the volume rocker to turn the volume all the way up, all the way down, and then all the way up again. To pass this test, the volume slider should move up and down as the rocker is pressed.
### <a href="" id="micro-sd-or-sd--slot-test--"></a>Micro SD or SD slot test
#### Micro SD or SD slot test
>**Note:**&nbsp;&nbsp;This test requires a micro SD or SD card that is compatible with the slot in your Surface device.
 
Insert a micro SD or SD card when you are prompted. When the SD card is detected, the test prompts you to remove the SD card to ensure that the card is not left in the device. During this test a small file is written to the SD card and then verified. Detection and verification of the SD card automatically passes this test without additional input.
### <a href="" id="microphone--test"></a>Microphone test
#### Microphone test
This test displays the **Recording** tab of the Sound item in Control Panel. The test prompts you to monitor the meter that is displayed next to the **Microphone Array** recording device. A recommended test is to speak and watch for your speech to be detected in the meter. If the meter moves when you speak, the microphone is working correctly. For Surface Book you will be prompted to tap locations near the microphones. This tapping should produce noticeable spikes in the audio meter.
### <a href="" id="video-out--test"></a>Video out test
#### Video out test
>**Note:**&nbsp;&nbsp;This test requires an external display with the applicable connection for your Surface device.
 
Surface devices provide a Mini DisplayPort connection for connecting to an external display. Connect your display through the Mini DisplayPort on the device when prompted. The display should be detected automatically and an image should appear on the external display.
### <a href="" id="bluetooth--test"></a>Bluetooth test
#### Bluetooth test
>**Note:**&nbsp;&nbsp;This test requires a Bluetooth device. The device must be set to pairing mode or made discoverable to perform this test.
 
After you receive a prompt to put the device in pairing mode, the test opens the **Add a device** window and begins to search for discoverable Bluetooth devices. Watch the **Add a device** window to verify that your Bluetooth device is detected. Select your Bluetooth device from the list and connect to the device to complete the test.
### <a href="" id="camera-test--"></a>Camera test
#### Camera test
Use this test to verify that the cameras on your Surface device are operating properly. Images will be displayed from both the front and rear cameras, and the infrared camera on a Surface Pro 4. Continuous autofocus can be enabled on the rear camera. Move the device closer and farther away from an object to verify the operation of continuous autofocus.
### <a href="" id="speaker-test--"></a>Speaker test
#### Speaker test
>**Note:**&nbsp;&nbsp;Headphones or external speakers are required to test the headphone jack in this test.
 
This test plays audio over left and right channels respectively, both for the internal speakers and for speakers or headphones connected to the headphone jack. Mark each channel as a pass or fail as you hear the audio play.
### <a href="" id="network-test--"></a>Network test
#### Network test
>**Note:**&nbsp;&nbsp;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.
 
This test uses the Windows Network Diagnostics built in troubleshooter to diagnose potential issues with network connectivity, including proxy configuration, DNS problems, and IP address conflicts. An event log is saved by this test in Windows logs and is visible in the Windows Event Viewer. The Event ID is 6100.
### <a href="" id="power-test--"></a>Power test
#### Power test
Settings such as display brightness, the elapsed time until the screen sleeps, and the elapsed time until device sleeps, are checked against default values with the Power built-in troubleshooter. The troubleshooter will automatically correct settings that may prevent the device from conserving power or entering sleep mode.
### <a href="" id="mobile-broadband-test--"></a>Mobile broadband test
#### Mobile broadband test
This test prompts you to enable mobile broadband and attempts to browse to http://www.bing.com. This test is only applicable to Surface devices that come equipped with mobile broadband, such as Surface 3 LTE.
### Accelerometer test
#### Accelerometer test
The accelerometer detects lateral, longitudinal, and vertical movements of the Surface device. This test prompts you to pick up and move the Surface device forward and backward, to the left and to the right, and up and down, to test the sensor for directional movement. The test automatically passes when movement is detected.
### <a href="" id="gyrometer-test--"></a>Gyrometer test
#### Gyrometer test
The gyrometer detects pitch, roll, and yaw movements. This test prompts you to pick up and rotate the Surface device to test the sensors for angular movement. The test automatically passes when movement is detected.
### <a href="" id="compass-test--"></a>Compass test
#### Compass test
The compass detects which direction the Surface device is facing relative to north, south, east, and west. Turn the Surface device to face in different directions to test the sensor. The test automatically passes when a change in direction is detected.
### <a href="" id="ambient-light-test--"></a>Ambient light test
#### Ambient light test
The ambient light sensor is used to automatically adjust screen brightness relative to the ambient lighting in the environment. Turn the device toward or away from a light source to cause the screen to dim or brighten in response increased or decreased light. The test automatically passes when the screen brightness automatically changes.
### <a href="" id="device-orientation-test--"></a>Device orientation test
#### Device orientation test
>**Note:**&nbsp;&nbsp;Before you run this test, disable rotation lock from the Action Center if enabled.
 
The device orientation sensor determines what the angle of the Surface device is, relative to the ground. Rotate the display 90 degrees or 180 degrees to cause the screen orientation to switch between portrait and landscape mode. The test automatically passes when the screen orientation switches.
### <a href="" id="brightness-test--"></a>Brightness test
#### Brightness test
This test cycles the screen through brightness levels from 0 percent to 100 percent, and then a message is displayed to confirm if the brightness level changed accordingly. You are then prompted to disconnect the power adapter. The screen should automatically dim when power is disconnected.
### <a href="" id="system-assessment--"></a>System assessment
#### System assessment
>**Note:**&nbsp;&nbsp;The Surface device must be connected to AC power before you can run this test.
 
The Windows System Assessment Tool (WinSAT) runs a series of benchmarks against the processor, memory, video adapter, and storage devices. The results include the processing speed of various algorithms, read and write performance of memory and storage, and performance in several Direct3D graphical tests.
### Performance Monitor test
#### Performance Monitor test
Performance and diagnostic trace logs are recorded from Performance Monitor for 30 seconds and collected in the .zip file output of the Microsoft Surface Diagnostic Toolkit by this test. You can analyze these trace logs with the [Windows Performance Analyzer](http://go.microsoft.com/fwlink/p/?LinkId=746486) to identify causes of application crashes, performance issues, or other undesirable behavior in Windows.
### Crash dump collection
#### Crash dump collection
If your Surface device has encountered an error that caused the device to fail or produce a blue screen error, this stage of the Microsoft Surface Diagnostic Toolkit records the information from the automatically recorded crash dump files in the diagnostic log. You can use these crash dump files to identify a faulty driver, hardware component, or application through analysis. Use the [Windows Debugging Tool](http://go.microsoft.com/fwlink/p/?LinkId=746488) to analyze these files. If you are not familiar with the analysis of crash dump files, you can describe your issue and post a link to your crash dump files (uploaded to OneDrive or another file sharing service) in the [Windows TechNet Forums](http://go.microsoft.com/fwlink/p/?LinkId=746489).
## <a href="" id="command-line--"></a>Command line
## Command line
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:**&nbsp;&nbsp;Many of the tests performed by the Microsoft Surface Diagnostic Toolkit require technician interaction. The Microsoft Surface Diagnostic Toolkit cannot run unattended.
 
### <a href="" id="exclude--"></a>exclude
#### exclude
Use this argument to exclude specific tests.
@ -424,7 +389,7 @@ See the following list for test names:
- WindowsUpdateCheckTest
### forceplatformsupport
#### forceplatformsupport
Use this argument to force tests to run when the make and model of the device is not properly detected by Windows. Surface Diagnostic Toolkit is intended to run only on Surface devices.
@ -434,7 +399,7 @@ Example:
Surface_Diagnostic_Toolkit_1.0.60.0.exe forceplatformsupport
```
### include
#### include
Use this argument to include tests when you run Microsoft Surface Diagnostic Toolkit from the command line. Tests specified by the **Include** command will be run even if the test is not supported on the model of Surface device. In the following example, the Surface Book specific tests for the latch mechanism and discrete graphics will be run, even if the command is run on a Surface Pro 4 or other Surface model.
@ -444,7 +409,7 @@ Example:
Surface_Diagnostic_Toolkit_1.0.60.0.exe “include=DualGraphicsTest,FanTest,MuscleWireTest”
```
### <a href="" id="logpath--"></a>logpath
#### logpath
Use this argument to specify the path for the log file.

4
devices/surface/surface-dock-updater.md
View File

@ -2,8 +2,10 @@
title: Microsoft Surface Dock Updater (Surface)
description: This article provides a detailed walkthrough of Microsoft Surface Dock Updater.
ms.assetid: 1FEFF277-F7D1-4CB4-8898-FDFE8CBE1D5C
ms.prod: W10
keywords: install, update, firmware
ms.prod: w10
ms.mktglfcycl: manage
ms.pagetype: surface, devices
ms.sitesec: library
author: jobotto
---

53
windows/keep-secure/edit-an-applocker-policy.md
View File

@ -2,70 +2,99 @@
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
ms.pagetype: security
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)
## <a href="" id="bkmk-editapppolingpo"></a>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).
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.
>**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).
>**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.
>**Note:**  If you are performing these steps by using Microsoft Advanced Group Policy Management (AGPM), check out the GPO before exporting the policy.
 
## <a href="" id="bkmk-editapplolnotingpo"></a>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.
>**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).
 
 

19
windows/keep-secure/edit-applocker-rules.md
View File

@ -2,42 +2,55 @@
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
ms.pagetype: security
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**.
 
 

94
windows/keep-secure/enable-computer-and-user-accounts-to-be-trusted-for-delegation.md
View File

@ -2,95 +2,99 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain Controller Effective Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
</tbody>
</table>
| 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 | Administrators|
| Member Server Effective Default Settings | Administrators|
| Client Computer Effective Default Settings | Administrators|
 
## 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.
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.
>**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)
 
 
- [User Rights Assignment](user-rights-assignment.md)

19
windows/keep-secure/enable-the-dll-rule-collection.md
View File

@ -2,24 +2,29 @@
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
ms.pagetype: security
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).
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.
 
 
 
>**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.

43
windows/keep-secure/encrypted-hard-drive.md
View File

@ -2,66 +2,93 @@
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
ms.pagetype: security
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.
>**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.
>**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 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.
 
 

13
windows/keep-secure/enforce-applocker-rules.md
View File

@ -2,22 +2,29 @@
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
ms.pagetype: security
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).
>**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).
 
 
 

85
windows/keep-secure/enforce-password-history.md
View File

@ -2,88 +2,85 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default domain policy</p></td>
<td align="left"><p>24 passwords remembered</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default domain controller policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-alone server default settings</p></td>
<td align="left"><p>0 passwords remembered</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain controller effective default settings</p></td>
<td align="left"><p>24 passwords remembered</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member server effective default settings</p></td>
<td align="left"><p>24 passwords remembered</p></td>
</tr>
<tr class="even">
<td align="left"><p>Effective GPO default settings on client computers</p></td>
<td align="left"><p>24 passwords remembered</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default domain policy | 24 passwords remembered|
| Default domain controller policy | Not defined|
| Stand-alone server default settings | 0 passwords remembered|
| Domain controller effective default settings | 24 passwords remembered|
| Member server effective default settings | 24 passwords remembered|
| Effective GPO default settings on client computers | 24 passwords remembered|
 
## 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.
>**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)
 
 
- [Password Policy](password-policy.md)

86
windows/keep-secure/enforce-user-logon-restrictions.md
View File

@ -2,88 +2,88 @@
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
ms.pagetype: security
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.
We recommend 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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server Type or GPO</th>
<th align="left">Default Value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
</tbody>
</table>
| Server Type or GPO | Default Value |
| - | - |
| Default Domain Policy | Enabled|
| Default Domain Controller Policy | Not defined |
| Stand-Alone Server Default Settings| Not applicable |
| DC Effective Default Settings | Enabled|
| Member Server Effective Default Settings| Not applicable|
| Client Computer Effective Default Settings | Not applicable|
 
## 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)
 
 
- [Kerberos Policy](kerberos-policy.md)

11
windows/keep-secure/export-an-applocker-policy-to-an-xml-file.md
View File

@ -2,20 +2,23 @@
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
ms.pagetype: security
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**.
 
 
3. In the **File name** box, type a file name for the XML file, and then click **Save**.

13
windows/keep-secure/file-system-global-object-access-auditing.md
View File

@ -2,20 +2,25 @@
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
ms.pagetype: security
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)
 
 
- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)

89
windows/keep-secure/force-shutdown-from-a-remote-system.md
View File

@ -2,92 +2,93 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Administrators</p>
<p>Server Operators</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain Controller Effective Default Settings</p></td>
<td align="left"><p>Administrators</p>
<p>Server Operators</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy| Not defined|
| Default Domain Controller Policy | Administrators<br/>Server Operators|
| Stand-Alone Server Default Settings | Administrators|
| Domain Controller Effective Default Settings | Administrators<br/>Server Operators|
| Member Server Effective Default Settings | Administrators|
| Client Computer Effective Default Settings | Administrators|
 
## 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)
 
 
- [User Rights Assignment](user-rights-assignment.md)

91
windows/keep-secure/generate-security-audits.md
View File

@ -2,95 +2,92 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Local Service</p>
<p>Network Service</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Local Service</p>
<p>Network Service</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain Controller Effective Default Settings</p></td>
<td align="left"><p>Local Service</p>
<p>Network Service</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Local Service</p>
<p>Network Service</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Local Service</p>
<p>Network Service</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy| Not defined|
| Default Domain Controller Policy | Local Service<br/>Network Service|
| Stand-Alone Server Default Settings | Local Service<br/>Network Service|
| Domain Controller Effective Default Settings | Local Service<br/>Network Service|
| Member Server Effective Default Settings | Local Service<br/>Network Service|
| Client Computer Effective Default Settings | Local Service<br/>Network Service|
 
## 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)
 
 
- [User Rights Assignment](user-rights-assignment.md)

16
windows/keep-secure/how-applocker-works-techref.md
View File

@ -2,37 +2,47 @@
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
ms.pagetype: security
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)
 
 

36
windows/keep-secure/how-to-configure-security-policy-settings.md
View File

@ -2,59 +2,77 @@
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
ms.pagetype: security
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.
## <a href="" id="bkmk-local"></a>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.
 
## <a href="" id="bkmk-domain"></a>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.
>**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.
>**Note:**  If you want to configure security settings for many devices on your network, you can use the Group Policy Management Console.
 
## <a href="" id="bkmk-dc"></a>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.
>**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)
 
 
- [Security policy settings reference](security-policy-settings-reference.md)

284
windows/keep-secure/how-user-account-control-works.md
View File

@ -2,143 +2,311 @@
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
ms.pagetype: security
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.
![uac windows logon process](images/uacwindowslogonprocess.gif)
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.
![uac consent prompt](images/uacconsentprompt.gif)
**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 credential prompt](images/uaccredentialprompt.gif)
**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.
![uac shield icon](images/uacshieldicon.png)
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.
![uac architecture](images/uacarchitecture.gif)
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.
<table>
<tr>
<th>Component</th>
<th>Description</th>
</tr>
<tr>
<td>
<p><b>User</b></p>
</td>
</tr>
<tr>
<td>
<p>User performs operation requiring privilege</p>
</td>
<td>
<p>If the operation changes the file system or registry, Virtualization is called. All other operations call ShellExecute.</p>
</td>
</tr>
<tr>
<td>
<p>ShellExecute</p>
</td>
<td>
<p>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.</p>
</td>
</tr>
<tr>
<td>
<p>CreateProcess</p>
</td>
<td>
<p>If the application requires elevation, CreateProcess rejects the call with ERROR_ELEVATION_REQUIRED.</p>
</td>
</tr>
<tr>
<td>
<p><b>System</b></p>
</td>
</tr>
<tr>
<td>
<p>Application Information service</p>
</td>
<td>
<p>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.</p>
</td>
</tr>
<tr>
<td>
<p>Elevating an ActiveX install</p>
</td>
<td>
<p>If ActiveX is not installed, the system checks the UAC slider level. If ActiveX is installed, the <b>User Account Control: Switch to the secure desktop when prompting for elevation</b> Group Policy setting is checked.</p>
</td>
</tr>
<tr>
<td>
<p>Check UAC slider level</p>
</td>
<td>
<p>UAC has four levels of notification to choose from and a slider to use to select the notification level:</p>
<ul>
<li>
<p>High</p>
<p>If the slider is set to <b>Always notify</b>, the system checks whether the secure desktop is enabled.</p>
</li>
<li>
<p>Medium</p>
<p>If the slider is set to <b>Notify me only when programs try to make changes to my computer</b>, the <b>User Account Control: Only elevate executable files that are signed and validated</b> policy setting is checked:</p>
<ul>
<li>
<p>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.</p>
</li>
<li>
<p>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 <b>User Account Control: Switch to the secure desktop when prompting for elevation</b> Group Policy setting is checked.</p>
</li>
</ul>
</li>
<li>
<p>Low</p>
<p>If the slider is set to <b>Notify me only when apps try to make changes to my computer (do not dim by desktop)</b>, the CreateProcess is called.</p>
</li>
<li>
<p>Never Notify</p>
<p>If the slider is set to <b>Never notify me when</b>, UAC prompt will never notify when an app is trying to install or trying to make any change on the computer.</p>
<div class="alert"><b>Important</b>  <p class="note">This setting is not recommended. This setting is the same as setting the <b>User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode</b> policy setting to <b>Elevate without prompting</b>.</p>
</div>
<div> </div>
</li>
</ul>
</td>
</tr>
<tr>
<td>
<p>Secure desktop enabled</p>
</td>
<td>
<p>The <b>User Account Control: Switch to the secure desktop when prompting for elevation</b> policy setting is checked: </p>
<ul>
<li>
<p>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.</p>
</li>
<li>
<p>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.</p>
</li>
</ul>
</td>
</tr>
<tr>
<td>
<p>CreateProcess</p>
</td>
<td>
<p>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.</p>
</td>
</tr>
<tr>
<td>
<p>AppCompat</p>
</td>
<td>
<p>The AppCompat database stores information in the application compatibility fix entries for an application.</p>
</td>
</tr>
<tr>
<td>
<p>Fusion</p>
</td>
<td>
<p>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.</p>
</td>
</tr>
<tr>
<td>
<p>Installer detection</p>
</td>
<td>
<p>Installer detection detects setup files, which helps prevent installations from being run without the user's knowledge and consent.</p>
</td>
</tr>
<tr>
<td>
<p><b>Kernel</b></p>
</td>
</tr>
<tr>
<td>
<p>Virtualization</p>
</td>
<td>
<p>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.</p>
</td>
</tr>
<tr>
<td>
<p>File system and registry</p>
</td>
<td>
<p>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.</p>
</td>
</tr>
</table>
 
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**.
>**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.
>**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).
 
 
>**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).

104
windows/keep-secure/impersonate-a-client-after-authentication.md
View File

@ -2,111 +2,101 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not eefined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Administrators</p>
<p>Local Service</p>
<p>Network Service</p>
<p>Service</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Administrators</p>
<p>Local Service</p>
<p>Network Service</p>
<p>Service</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain Controller Effective Default Settings</p></td>
<td align="left"><p>Administrators</p>
<p>Local Service</p>
<p>Network Service</p>
<p>Service</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Administrators</p>
<p>Local Service</p>
<p>Network Service</p>
<p>Service</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Administrators</p>
<p>Local Service</p>
<p>Network Service</p>
<p>Service</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy| Not defined |
| Default Domain Controller Policy| Administrators<br/>Local Service<br/>Network Service<br/>Service|
| Stand-Alone Server Default Settings | Administrators<br/>Local Service<br/>Network Service<br/>Service|
| Domain Controller Effective Default Settings | Administrators<br/>Local Service<br/>Network Service<br/>Service|
| Member Server Effective Default Settings | Administrators<br/>Local Service<br/>Network Service<br/>Service|
| Client Computer Effective Default Settings | Administrators<br/>Local Service<br/>Network Service<br/>Service|
 
## 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\_*&lt;ComputerName&gt;*, IIS\_WPG, ASP.NET, or IWAM\_*&lt;ComputerName&gt;*.
## Related topics
[User Rights Assignment](user-rights-assignment.md)
 
 
- [User Rights Assignment](user-rights-assignment.md)

14
windows/keep-secure/import-an-applocker-policy-from-another-computer.md
View File

@ -2,25 +2,29 @@
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
ms.pagetype: security
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.
>**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**.
 
 

13
windows/keep-secure/import-an-applocker-policy-into-a-gpo.md
View File

@ -2,26 +2,29 @@
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
ms.pagetype: security
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).
>**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**.
 
 

83
windows/keep-secure/increase-a-process-working-set.md
View File

@ -2,88 +2,87 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not Defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Users</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Users</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain Controller Effective Default Settings</p></td>
<td align="left"><p>Users</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Users</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Users</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy| Not Defined|
| Default Domain Controller Policy | Users|
| Stand-Alone Server Default Settings| Users|
| Domain Controller Effective Default Settings| Users|
| Member Server Effective Default Settings | Users|
| Client Computer Effective Default Settings | Users|
 
## 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)
 
 
- [User Rights Assignment](user-rights-assignment.md)

86
windows/keep-secure/increase-scheduling-priority.md
View File

@ -2,90 +2,92 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain Controller Effective Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy| Not defined|
| Default Domain Controller Policy| Administrators|
| Stand-Alone Server Default Settings | Administrators|
| Domain Controller Effective Default Settings | Administrators|
| Member Server Effective Default Settings | Administrators|
| Client Computer Effective Default Settings | Administrators|
 
## 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)
 
 
- [User Rights Assignment](user-rights-assignment.md)

126
windows/keep-secure/initialize-and-configure-ownership-of-the-tpm.md
View File

@ -2,156 +2,176 @@
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
ms.pagetype: security
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.
## <a href="" id="bkmk-init"></a>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)
## <a href="" id="bkmk-initializetpm"></a>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 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.
>**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.
>**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.
>**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.
>**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.
>**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.
>**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.
 
## <a href="" id="bkmk-troubleshootinit"></a>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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Driver name</th>
<th align="left">Manufacturer</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Trusted Platform Module 1.2</p></td>
<td align="left"><p>(Standard)</p></td>
</tr>
<tr class="even">
<td align="left"><p>Broadcom Trusted Platform Module (A1), v1.2</p></td>
<td align="left"><p>Broadcom</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Broadcom Trusted Platform Module (A2), v1.2</p></td>
<td align="left"><p>Broadcom</p></td>
</tr>
</tbody>
</table>
| Driver name | Manufacturer |
| - | - |
| Trusted Platform Module 1.2 | (Standard)|
| Broadcom Trusted Platform Module (A1), v1.2 | Broadcom|
| Broadcom Trusted Platform Module (A2), v1.2 | Broadcom|
 
- 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.
> **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.
## <a href="" id="bkmk-onoff"></a>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.
### <a href="" id="turn-on-the-tpm-"></a>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.
### <a href="" id="turn-off-the-tpm-"></a>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.
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.
## <a href="" id="bkmk-clear1"></a>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.
>**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.
>**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.
>**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.
## <a href="" id="bkmk-tpmcmdlets"></a>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**
`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).
 
 

91
windows/keep-secure/interactive-logon-display-user-information-when-the-session-is-locked.md
View File

@ -2,91 +2,98 @@
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
ms.pagetype: security
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 **&lt;user name&gt; 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
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or Group Policy object (GPO)</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default domain policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default domain controller policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-alone server default settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain controller effective default settings</p></td>
<td align="left"><p><strong>User display name, domain and user names</strong></p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member server effective default settings</p></td>
<td align="left"><p><strong>User display name, domain and user names</strong></p></td>
</tr>
<tr class="even">
<td align="left"><p>Effective GPO default settings on client computers</p></td>
<td align="left"><p><strong>User display name, domain and user names</strong></p></td>
</tr>
</tbody>
</table>
| 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 defined|
| Domain controller effective default settings | **User display name, domain and user names**|
| Member server effective default settings | **User display name, domain and user names**|
| Effective GPO default settings on client computers | **User display name, domain and user names**|
 
## 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)
 
 
- [Security Options](security-options.md)

85
windows/keep-secure/interactive-logon-do-not-display-last-user-name.md
View File

@ -2,86 +2,87 @@
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
ms.pagetype: security
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
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or Group Policy object (GPO)</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default domain policy</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default domain controller policy</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-alone server default settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain controller effective default settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member server effective default settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Effective GPO default settings on client computers</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
</tbody>
</table>
| Server type or Group Policy object (GPO) | Default value|
| - | - |
| Default domain policy| Disabled|
| Default domain controller policy| Disabled|
| Stand-alone server default settings | Disabled|
| Domain controller effective default settings | Disabled|
| Member server effective default settings | Disabled|
| Effective GPO default settings on client computers | 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.
### 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)
 
 
- [Security Options](security-options.md)

87
windows/keep-secure/interactive-logon-do-not-require-ctrl-alt-del.md
View File

@ -2,89 +2,92 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
</tbody>
</table>
| 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
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)
 
 
- [Security Options](security-options.md)

87
windows/keep-secure/interactive-logon-machine-account-lockout-threshold.md
View File

@ -2,84 +2,85 @@
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
ms.pagetype: security
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.
### <a href="" id="bkmk-bestpractices"></a>Best practices
### 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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
</tbody>
</table>
| 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
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)
 
 
- [Security Options](security-options.md)

82
windows/keep-secure/interactive-logon-machine-inactivity-limit.md
View File

@ -2,81 +2,79 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
</tbody>
</table>
| 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
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)
 
 
- [Security Options](security-options.md)

94
windows/keep-secure/interactive-logon-message-text-for-users-attempting-to-log-on.md
View File

@ -2,94 +2,94 @@
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
ms.pagetype: security
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.
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.
>**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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy| Not defined|
| Default Domain Controller Policy | Not defined|
| Stand-Alone Server Default Settings | Not defined|
| DC Effective Default Settings | Not defined|
| Member Server Effective Default Settings | Not defined|
| Client Computer Effective Default Settings | Not defined|
 
## 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.
>**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)
 
 
- [Security Options](security-options.md) 

92
windows/keep-secure/interactive-logon-message-title-for-users-attempting-to-log-on.md
View File

@ -2,93 +2,97 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
</tbody>
</table>
|Server type or GPO | Default value|
| - | - |
| Default Domain Policy| Not defined|
| Default Domain Controller Policy | Not defined|
| Stand-Alone Server Default Settings | Not defined|
| DC 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 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.
>**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)
 
 
- [Security Options](security-options.md)

97
windows/keep-secure/interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md
View File

@ -2,91 +2,100 @@
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
ms.pagetype: security
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.
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>10 logons</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>10 logons</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>10 logons</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>10 logons</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy| Not defined|
| Default Domain Controller Policy | Not defined|
| Stand-Alone Server Default Settings | 10 logons|
| DC Effective Default Settings | 10 logons|
| Member Server Effective Default Settings | 10 logons|
| Client Computer Effective Default Settings| 10 logons|
 
## 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.
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)
 
 
- [Security Options](security-options.md)

83
windows/keep-secure/interactive-logon-prompt-user-to-change-password-before-expiration.md
View File

@ -2,85 +2,84 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>14 days *</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>14 days *</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>14 days *</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>14 days *</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy| Not defined|
| Default Domain Controller Policy | Not defined|
| Stand-Alone Server Default Settings | 14 days|
| DC Effective Default Settings | 14 days |
| Member Server Effective Default Settings| 14 days |
| Client Computer Effective Default Settings | 14 days|
 
## 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)
 
 
- [Security Options](security-options.md)

86
windows/keep-secure/interactive-logon-require-domain-controller-authentication-to-unlock-workstation.md
View File

@ -2,87 +2,89 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
</tbody>
</table>
| 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
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)
 
 
- [Security Options](security-options.md)

87
windows/keep-secure/interactive-logon-require-smart-card.md
View File

@ -2,85 +2,86 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
</tbody>
</table>
| 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
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.
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)
 
 
- [Security Options](security-options.md)

93
windows/keep-secure/interactive-logon-smart-card-removal-behavior.md
View File

@ -2,93 +2,102 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>No Action</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>No Action</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>No Action</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>No Action</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy| Not defined|
| Default Domain Controller Policy | Not defined|
| Stand-Alone Server Default Settings | No Action|
| DC Effective Default Settings | No Action|
| Member Server Effective Default Settings | No Action|
| Client Computer Effective Default Settings | No Action|
 
## 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)
 
 
- [Security Options](security-options.md)

59
windows/keep-secure/kerberos-policy.md
View File

@ -2,56 +2,37 @@
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
ms.pagetype: security
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.
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
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Topic</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>[Enforce user logon restrictions](enforce-user-logon-restrictions.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management, and security considerations for the <strong>Enforce user logon restrictions</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Maximum lifetime for service ticket](maximum-lifetime-for-service-ticket.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management, and security considerations for the <strong>Maximum lifetime for service ticket</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Maximum lifetime for user ticket](maximum-lifetime-for-user-ticket.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management, and security considerations for the <strong>Maximum lifetime for user ticket</strong> policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Maximum lifetime for user ticket renewal](maximum-lifetime-for-user-ticket-renewal.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management, and security considerations for the <strong>Maximum lifetime for user ticket renewal</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Maximum tolerance for computer clock synchronization](maximum-tolerance-for-computer-clock-synchronization.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management, and security considerations for the <strong>Maximum tolerance for computer clock synchronization</strong> security policy setting.</p></td>
</tr>
</tbody>
</table>
| Topic | Description |
| - | - |
| [Enforce user logon restrictions](enforce-user-logon-restrictions.md) | Describes the best practices, location, values, policy management, and security considerations for the **Enforce user logon restrictions** security policy setting.|
| [Maximum lifetime for service ticket](maximum-lifetime-for-service-ticket.md) | Describes the best practices, location, values, policy management, and security considerations for the **Maximum lifetime for service ticket** security policy setting.|
| [Maximum lifetime for user ticket](maximum-lifetime-for-user-ticket.md) | Describes the best practices, location, values, policy management, and security considerations for the **Maximum lifetime for user ticket** policy setting.|
| [Maximum lifetime for user ticket renewal](maximum-lifetime-for-user-ticket-renewal.md) | Describes the best practices, location, values, policy management, and security considerations for the **Maximum lifetime for user ticket renewal** security policy setting.|
| [Maximum tolerance for computer clock synchronization](maximum-tolerance-for-computer-clock-synchronization.md) | Describes the best practices, location, values, policy management, and security considerations for the **Maximum tolerance for computer clock synchronization** security| policy setting.
 
## Related topics
[Configure security policy settings](how-to-configure-security-policy-settings.md)
 
 
- [Configure security policy settings](how-to-configure-security-policy-settings.md)

91
windows/keep-secure/load-and-unload-device-drivers.md
View File

@ -2,96 +2,95 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Administrators</p>
<p>Print Operators</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain Controller Effective Default Settings</p></td>
<td align="left"><p>Administrators</p>
<p>Print Operators</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy| Not defined|
| Default Domain Controller Policy | Administrators<br/>Print Operators|
| Stand-Alone Server Default Settings | Administrators|
| Domain Controller Effective Default Settings | Administrators<br/>Print Operators |
| Member Server Effective Default Settings | Administrators|
| Client Computer Effective Default Settings | Administrators|
 
## 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.
>**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)
 
 
- [User Rights Assignment](user-rights-assignment.md)

89
windows/keep-secure/lock-pages-in-memory.md
View File

@ -2,92 +2,93 @@
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
ms.pagetype: security
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.
>**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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain Controller Effective Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
</tbody>
</table>
| 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.
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)
 
 
- [User Rights Assignment](user-rights-assignment.md)

94
windows/keep-secure/log-on-as-a-batch-job.md
View File

@ -2,98 +2,92 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Administrators</p>
<p>Backup Operators</p>
<p>Performance Log Users</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Administrators</p>
<p>Backup Operators</p>
<p>Performance Log Users</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain Controller Effective Default Settings</p></td>
<td align="left"><p>Administrators</p>
<p>Backup Operators</p>
<p>Performance Log Users</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Administrators</p>
<p>Backup Operators</p>
<p>Performance Log Users</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy| Not defined|
| Default Domain Controller Policy | Administrators<br/>Backup Operators<br/>Performance Log Users|
| Stand-Alone Server Default Settings | Administrators<br/>Backup Operators<br/>Performance Log Users|
| Domain Controller Effective Default Settings | Administrators<br/>Backup Operators<br/>Performance Log Users|
| Member Server Effective Default Settings | Administrators<br/>Backup Operators<br/>Performance Log Users|
| Client Computer Effective Default Settings | Administrators|
 
## 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\_*&lt;ComputerName&gt;* and IWAM\_*&lt;ComputerName&gt;* 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\_*&lt;ComputerName&gt;*, ASPNET, and IWAM\_*&lt;ComputerName&gt;* 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)
 
 
- [User Rights Assignment](user-rights-assignment.md)

91
windows/keep-secure/log-on-as-a-service.md
View File

@ -2,88 +2,91 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain Controller Effective Default Settings</p></td>
<td align="left"><p>Network Service</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Network Service</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Network Service</p></td>
</tr>
</tbody>
</table>
| 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 | Network Service|
| Member Server Effective Default Settings| Network Service|
| Client Computer Effective Default Settings | Network Service|
 
## 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.
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.
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)
 
 
- [User Rights Assignment](user-rights-assignment.md)

48
windows/keep-secure/maintain-applocker-policies.md
View File

@ -2,64 +2,100 @@
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
ms.pagetype: security
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.
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.
 
## <a href="" id="bkmk-applkr-use-gp"></a>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.
## <a href="" id="bkmk-applkr-use-locsnapin"></a>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).
 
 

92
windows/keep-secure/manage-auditing-and-security-log.md
View File

@ -2,95 +2,97 @@
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
ms.pagetype: security
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).
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain Controller Effective Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy| Not defined|
| Default Domain Controller Policy | Administrators|
| Stand-Alone Server Default Settings | Administrators|
| Domain Controller Effective Default Settings | Administrators|
| Member Server Effective Default Settings | Administrators|
| Client Computer Effective Default Settings| Administrators|
 
## 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.
>**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)
 
 
- [User Rights Assignment](user-rights-assignment.md)

44
windows/keep-secure/manage-packaged-apps-with-applocker.md
View File

@ -2,47 +2,71 @@
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
ms.pagetype: security
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.
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.
### <a href="" id="bkmk-compareclassicmetro"></a>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:
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).
>**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.
- 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).
 
 

37
windows/keep-secure/manage-tpm-commands.md
View File

@ -2,54 +2,75 @@
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
ms.pagetype: security
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.
## <a href="" id="bkmk-commands1"></a>
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).
>**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).
>**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.
## <a href="" id="bkmk-tpmcmdlets"></a>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**
`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).
 
 

86
windows/keep-secure/maximum-lifetime-for-service-ticket.md
View File

@ -2,89 +2,91 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server Type or GPO</th>
<th align="left">Default Value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>600 minutes</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>600 minutes</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
</tbody>
</table>
| Server Type or GPO | Default Value |
| - | - |
| Default Domain Policy| 600 minutes|
| Default Domain Controller Policy | Not defined|
| Stand-Alone Server Default Settings | Not applicable|
| DC Effective Default Settings | 600 minutes|
| Member Server Effective Default Settings | Not applicable|
| Client Computer Effective Default Settings | Not applicable|
 
## 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)
 
 
- [Kerberos Policy](kerberos-policy.md)

85
windows/keep-secure/maximum-lifetime-for-user-ticket-renewal.md
View File

@ -2,88 +2,89 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>7 days</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain Controller Effective Default Settings</p></td>
<td align="left"><p>7 days</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy| 7 days|
| Default Domain Controller Policy| Not defined|
| Stand-Alone Server Default Settings | Not applicable|
| Domain Controller Effective Default Settings | 7 days|
| Member Server Effective Default Settings | Not applicable|
| Client Computer Effective Default Settings | Not applicable|
 
### 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)
 
 
- [Kerberos Policy](kerberos-policy.md)

85
windows/keep-secure/maximum-lifetime-for-user-ticket.md
View File

@ -2,88 +2,89 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server Type or GPO</th>
<th align="left">Default Value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>10 hours</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain Controller Effective Default Settings</p></td>
<td align="left"><p>10 hours</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
</tbody>
</table>
| Server Type or GPO | Default Value |
| - | - |
| Default Domain Policy| 10 hours|
| Default Domain Controller Policy| Not defined|
| Stand-Alone Server Default Settings | Not applicable|
| Domain Controller Effective Default Settings | 10 hours|
| Member Server Effective Default Settings | Not applicable|
| Client Computer Effective Default Settings | Not applicable|
 
## 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)
 
 
- [Kerberos Policy](kerberos-policy.md)

82
windows/keep-secure/maximum-password-age.md
View File

@ -2,82 +2,76 @@
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
ms.pagetype: security
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**.
>**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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or Group Policy Object (GPO)</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default domain policy</p></td>
<td align="left"><p>42 days</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default domain controller policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-alone server default settings</p></td>
<td align="left"><p>42 days</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain controller effective default settings</p></td>
<td align="left"><p>42 days</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member server effective default settings</p></td>
<td align="left"><p>42 days</p></td>
</tr>
<tr class="even">
<td align="left"><p>Effective GPO default settings on client computers</p></td>
<td align="left"><p>42 days</p></td>
</tr>
</tbody>
</table>
| Server type or Group Policy Object (GPO) | Default value |
| - | - |
| Default domain policy| 42 days|
| Default domain controller policy| Not defined|
| Stand-alone server default settings | 42 days|
| Domain controller effective default settings | 42 days|
| Member server effective default settings | 42 days|
| Effective GPO default settings on client computers| 42 days|
 
## 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)
 
 
- [Password Policy](password-policy.md)

88
windows/keep-secure/maximum-tolerance-for-computer-clock-synchronization.md
View File

@ -2,88 +2,90 @@
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
ms.pagetype: security
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.
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>5 minutes</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain Controller Effective Default Settings</p></td>
<td align="left"><p>5 minutes</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy| 5 minutes|
| Default Domain Controller Policy | Not defined|
| Stand-Alone Server Default Settings | Not applicable|
| Domain Controller Effective Default Settings| 5 minutes|
| Member Server Effective Default Settings | Not applicable|
| Client Computer Effective Default Settings | Not applicable|
 
## 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)
 
 
- [Kerberos Policy](kerberos-policy.md)

17
windows/keep-secure/merge-applocker-policies-by-using-set-applockerpolicy.md
View File

@ -2,27 +2,36 @@
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
ms.pagetype: security
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&gt;Get-AppLockerPolicy -Local | Set-AppLockerPolicy -LDAP "LDAP: //***&lt;string&gt;***"** **-Merge** where *&lt;string&gt;* 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
```
 
 
```

86
windows/keep-secure/merge-applocker-policies-manually.md
View File

@ -2,84 +2,46 @@
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
ms.pagetype: security
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:
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Rule collection</th>
<th align="left">RuleCollection Type element</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Executable rules</p></td>
<td align="left"><p>Exe</p></td>
</tr>
<tr class="even">
<td align="left"><p>Windows Installer rules</p></td>
<td align="left"><p>Msi</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Script rules</p></td>
<td align="left"><p>Script</p></td>
</tr>
<tr class="even">
<td align="left"><p>DLL rules</p></td>
<td align="left"><p>Dll</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Packaged apps and packaged app installers</p></td>
<td align="left"><p>Appx</p></td>
</tr>
</tbody>
</table>
| Rule collection | RuleCollection Type element |
| - | - |
| Executable rules| Exe|
| Windows Installer rules| Msi|
| Script rules | Script|
| DLL rules | Dll|
| Packaged apps and packaged app installers|Appx|
 
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:
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">XML enforcement mode</th>
<th align="left">Enforcement mode in Group Policy</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>NotConfigured</p></td>
<td align="left"><p>Not configured (rules are enforced)</p></td>
</tr>
<tr class="even">
<td align="left"><p>AuditOnly</p></td>
<td align="left"><p>Audit only</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Enabled</p></td>
<td align="left"><p>Enforce rules</p></td>
</tr>
</tbody>
</table>
| XML enforcement mode |Enforcement mode in Group Policy |
| - | - |
| NotConfigured | Not configured (rules are enforced)|
| AuditOnly | Audit only|
| Enabled | Enforce rules|
 
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.
@ -87,5 +49,3 @@ Membership in the local **Administrators** group, or equivalent, is the minimum
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.
 
 

96
windows/keep-secure/microsoft-network-client-digitally-sign-communications-always.md
View File

@ -2,103 +2,109 @@
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
ms.pagetype: security
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.
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
</tbody>
</table>
| 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
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.
>**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)
 
 
- [Security Options](security-options.md)

100
windows/keep-secure/microsoft-network-client-digitally-sign-communications-if-server-agrees.md
View File

@ -2,103 +2,111 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
</tbody>
</table>
| 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
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.
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.
>**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.
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)
 
 
- [Security Options](security-options.md)

84
windows/keep-secure/microsoft-network-client-send-unencrypted-password-to-third-party-smb-servers.md
View File

@ -2,82 +2,82 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
</tbody>
</table>
| 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
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)
 
 
- [Security Options](security-options.md)

82
windows/keep-secure/microsoft-network-server-amount-of-idle-time-required-before-suspending-session.md
View File

@ -2,81 +2,79 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>15 minutes</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>15 minutes</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>15 minutes</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>15 minutes</p></td>
</tr>
</tbody>
</table>
| Server type or GPO Default value |
| - | - |
| Default Domain Policy| Not defined|
| Default Domain Controller Policy | Not defined |
| Stand-Alone Server Default Settings | 15 minutes|
| DC Effective Default Settings | 15 minutes|
| Member Server Effective Default Settings | 15 minutes|
| Client Computer Effective Default Settings | 15 minutes|
 
## 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)
 
 
- [Security Options](security-options.md)

95
windows/keep-secure/microsoft-network-server-attempt-s4u2self-to-obtain-claim-information.md
View File

@ -2,88 +2,95 @@
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
ms.pagetype: security
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.
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy| Not defined|
| Default Domain Controller Policy | Not defined|
| Stand-Alone Server Default Settings | Not defined|
| 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
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.
None. Enabling this policy setting allows you take advantage of features in Windows Server 2012 and Windows 8 and later 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)
 
 
- [Security Options](security-options.md)

98
windows/keep-secure/microsoft-network-server-digitally-sign-communications-always.md
View File

@ -2,104 +2,112 @@
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
ms.pagetype: security
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.
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy| Not defined|
| Default Domain Controller Policy | Enabled|
| Stand-Alone Server Default Settings | Not defined|
| DC Effective Default Settings | Enabled|
| Member Server Effective Default Settings| Not defined|
| 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
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.
>**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)
 
 
- [Security Options](security-options.md)

97
windows/keep-secure/microsoft-network-server-digitally-sign-communications-if-client-agrees.md
View File

@ -2,103 +2,110 @@
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
ms.pagetype: security
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.
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
</tbody>
</table>
| Server type or GPO Default value |
| - | - |
| Default Domain Policy| Not defined|
| Default Domain Controller Policy| Enabled|
| Stand-Alone Server Default Settings | Not defined|
| DC Effective Default Settings | Enabled|
| Member Server Effective Default Settings|Not defined|
| 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
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.
>**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)
 
 
- [Security Options](security-options.md)

85
windows/keep-secure/microsoft-network-server-disconnect-clients-when-logon-hours-expire.md
View File

@ -2,84 +2,85 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
</tbody>
</table>
| 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
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)
 
 
- [Security Options](security-options.md)

95
windows/keep-secure/microsoft-network-server-server-spn-target-name-validation-level.md
View File

@ -2,94 +2,101 @@
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
ms.pagetype: security
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.
>**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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or Group Policy object (GPO)</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default domain policy</p></td>
<td align="left"><p>Off</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default domain controller policy</p></td>
<td align="left"><p>Off</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-alone server default settings</p></td>
<td align="left"><p>Off</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain controller effective default settings</p></td>
<td align="left"><p>Validation level check not implemented</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member server effective default settings</p></td>
<td align="left"><p>Validation level check not implemented</p></td>
</tr>
<tr class="even">
<td align="left"><p>Effective GPO default settings on client computers</p></td>
<td align="left"><p>Validation level check not implemented</p></td>
</tr>
</tbody>
</table>
| Server type or Group Policy object (GPO) | Default value |
| - | - |
| Default domain policy | Off |
| Default domain controller policy| Off|
| Stand-alone server default settings | Off|
| Domain controller effective default settings| Validation level check not implemented|
| Member server effective default settings | Validation level check not implemented|
| Effective GPO default settings on client computers | Validation level check not implemented|
 
## 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)
 
 
- [Security Options](security-options.md)

81
windows/keep-secure/minimum-password-age.md
View File

@ -2,81 +2,78 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or Group Policy Object (GPO)</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default domain policy</p></td>
<td align="left"><p>1 day</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default domain controller policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-alone server default settings</p></td>
<td align="left"><p>0 days</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain controller effective default settings</p></td>
<td align="left"><p>1 day</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member server effective default settings</p></td>
<td align="left"><p>1 day</p></td>
</tr>
<tr class="even">
<td align="left"><p>Effective GPO default settings on client computers</p></td>
<td align="left"><p>1 day</p></td>
</tr>
</tbody>
</table>
| Server type or Group Policy Object (GPO) | Default value |
| - | - |
| Default domain policy| 1 day|
| Default domain controller policy| Not defined|
| Stand-alone server default settings | 0 days|
| Domain controller effective default settings | 1 day|
| Member server effective default settings | 1 day|
| Effective GPO default settings on client computers| 1 day|
 
## 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)
 
 
- [Password Policy](password-policy.md)

85
windows/keep-secure/minimum-password-length.md
View File

@ -2,85 +2,82 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or Group Policy Object (GPO)</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default domain policy</p></td>
<td align="left"><p>7 characters</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default domain controller policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-alone server default settings</p></td>
<td align="left"><p>0 characters</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain controller effective default settings</p></td>
<td align="left"><p>7 characters</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member server effective default settings</p></td>
<td align="left"><p>7 characters</p></td>
</tr>
<tr class="even">
<td align="left"><p>Effective GPO default settings on client computers</p></td>
<td align="left"><p>0 characters</p></td>
</tr>
</tbody>
</table>
| Server type or Group Policy Object (GPO) | Default value |
| - | - |
| Default domain policy| 7 characters|
| Default domain controller policy | Not defined|
| Stand-alone server default settings | 0 characters|
| Domain controller effective default settings | 7 characters|
| Member server effective default settings | 7 characters|
| Effective GPO default settings on client computers | 0 characters|
 
## 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.
>**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)
 
 
- [Password Policy](password-policy.md)

94
windows/keep-secure/modify-an-object-label.md
View File

@ -2,96 +2,102 @@
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
ms.pagetype: security
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:
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain Controller Effective Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
</tbody>
</table>
| 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.
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.
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)
 
 
- [User Rights Assignment](user-rights-assignment.md)

90
windows/keep-secure/modify-firmware-environment-values.md
View File

@ -2,94 +2,100 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Adminstrators</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Adminstrators</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain Controller Effective Default Settings</p></td>
<td align="left"><p>Adminstrators</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Adminstrators</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Adminstrators</p></td>
</tr>
</tbody>
</table>
| Server type or GPO |Default value |
| - | - |
| Default Domain Policy| Not defined|
| Default Domain Controller Policy | Adminstrators|
| Stand-Alone Server Default Settings | Adminstrators|
| Domain Controller Effective Default Settings | Adminstrators|
| Member Server Effective Default Settings | Adminstrators|
| Client Computer Effective Default Settings | Adminstrators|
 
## 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)
 
 
- [User Rights Assignment](user-rights-assignment.md)

46
windows/keep-secure/monitor-application-usage-with-applocker.md
View File

@ -2,51 +2,83 @@
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
ms.pagetype: security
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.
### <a href="" id="bkmk-applkr-disc-effect-pol"></a>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).
### <a href="" id="bkmk-applkr-review-events"></a>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.
>**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`
### <a href="" id="bkmk-applkr-view-log"></a>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.
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)
 
 
- [AppLocker](applocker-overview.md)

20
windows/keep-secure/monitor-central-access-policy-and-rule-definitions.md
View File

@ -2,22 +2,27 @@
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
ms.pagetype: security
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.
>**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**.
@ -28,8 +33,11 @@ Your server might function differently based on the version and edition of the o
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**.
@ -39,7 +47,7 @@ After you configure settings to monitor changes to central access policy and cen
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)
 
 
- [Using advanced security auditing options to monitor dynamic access control objects](using-advanced-security-auditing-options-to-monitor-dynamic-access-control-objects.md)

27
windows/keep-secure/monitor-claim-types.md
View File

@ -2,39 +2,52 @@
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
ms.pagetype: security
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.
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)
 
 
- [Using advanced security auditing options to monitor dynamic access control objects](using-advanced-security-auditing-options-to-monitor-dynamic-access-control-objects.md)

21
windows/keep-secure/monitor-resource-attribute-definitions.md
View File

@ -2,23 +2,29 @@
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
ms.pagetype: security
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.
>**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**.
@ -29,8 +35,11 @@ Your server might function differently based on the version and edition of the o
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.
@ -38,7 +47,7 @@ After you configure settings to monitor changes to resource attributes in AD DS
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)
 
 
- [Using advanced security auditing options to monitor dynamic access control objects](using-advanced-security-auditing-options-to-monitor-dynamic-access-control-objects.md)

32
windows/keep-secure/monitor-the-central-access-policies-associated-with-files-and-folders.md
View File

@ -2,53 +2,67 @@
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
ms.pagetype: security
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.
>**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**
`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.
>**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)
 
 
- [Using advanced security auditing options to monitor dynamic access control objects](using-advanced-security-auditing-options-to-monitor-dynamic-access-control-objects.md)

25
windows/keep-secure/monitor-the-central-access-policies-that-apply-on-a-file-server.md
View File

@ -2,28 +2,37 @@
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
ms.pagetype: security
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.
>**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**.
@ -32,13 +41,13 @@ After you modify the central access policies on the domain controller, verify th
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**.
>**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)
 
 
- [Using advanced security auditing options to monitor dynamic access control objects](using-advanced-security-auditing-options-to-monitor-dynamic-access-control-objects.md)

24
windows/keep-secure/monitor-the-resource-attributes-on-files-and-folders.md
View File

@ -2,42 +2,54 @@
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
ms.pagetype: security
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.
>**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)
 
 
- [Using advanced security auditing options to monitor dynamic access control objects](using-advanced-security-auditing-options-to-monitor-dynamic-access-control-objects.md)

29
windows/keep-secure/monitor-the-use-of-removable-storage-devices.md
View File

@ -2,22 +2,28 @@
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
ms.pagetype: security
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.
>**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**.
@ -25,22 +31,25 @@ Your server might function differently based on the version and edition of the o
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**.
>**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.
>**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)
 
 
- [Using advanced security auditing options to monitor dynamic access control objects](using-advanced-security-auditing-options-to-monitor-dynamic-access-control-objects.md)

26
windows/keep-secure/monitor-user-and-device-claims-during-sign-in.md
View File

@ -2,36 +2,48 @@
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
ms.pagetype: security
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.
>**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**
`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)
 
 
- [Using advanced security auditing options to monitor dynamic access control objects](using-advanced-security-auditing-options-to-monitor-dynamic-access-control-objects.md)

90
windows/keep-secure/network-access-allow-anonymous-sidname-translation.md
View File

@ -2,90 +2,96 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Note defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy| Not defined|
| Default Domain Controller Policy | Note defined|
| Stand-Alone Server Default Settings | Disabled|
| DC Effective Default Settings | Enabled|
| Member Server Effective Default Settings| Disabled|
| Client Computer Effective Default Settings | Disabled|
 
### 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)
 
 
- [Security Options](security-options.md)

85
windows/keep-secure/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts-and-shares.md
View File

@ -2,85 +2,86 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
</tbody>
</table>
| 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
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)
 
 
- [Security Options](security-options.md)

87
windows/keep-secure/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts.md
View File

@ -2,85 +2,88 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
</tbody>
</table>
| 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
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)
 
 
- [Security Options](security-options.md)

92
windows/keep-secure/network-access-do-not-allow-storage-of-passwords-and-credentials-for-network-authentication.md
View File

@ -2,91 +2,95 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or Group Policy Object (GPO)</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default domain policy</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default domain controller policy</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-alone server default settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain controller effective default settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member server effective default settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Effective GPO default settings on client computers</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
</tbody>
</table>
| Server type or Group Policy Object (GPO) | Default value |
| - | - |
| Default domain policy| Disabled|
| Default domain controller policy| Disabled|
| Stand-alone server default settings | Disabled|
| Domain controller effective default settings| Not defined|
| Member server effective default settings | Not defined|
| Effective GPO default settings on client computers | Not defined|
 
### 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.
>**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)
 
 
- [Security Options](security-options.md)

84
windows/keep-secure/network-access-let-everyone-permissions-apply-to-anonymous-users.md
View File

@ -2,83 +2,83 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
</tbody>
</table>
| 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
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)
 
 
- [Security Options](security-options.md)

138
windows/keep-secure/network-access-named-pipes-that-can-be-accessed-anonymously.md
View File

@ -2,129 +2,91 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Netlogon, samr, lsarpc</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Null</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Netlogon, samr, lsarpc</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy | Not defined |
| Default Domain Controller Policy | Netlogon, samr, lsarpc|
| Stand-Alone Server Default Settings | Null|
| DC Effective Default Settings | Netlogon, samr, lsarpc|
| Member Server Effective Default Settings | Not defined|
| Client Computer Effective Default Settings | Not defined|
 
## 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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Named pipe</th>
<th align="left">Purpose</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>COMNAP</p></td>
<td align="left"><p>SNABase named pipe. Systems network Architecture (SNA) is a collection of network protocols that were originally developed for IBM mainframe computers.</p></td>
</tr>
<tr class="even">
<td align="left"><p>COMNODE</p></td>
<td align="left"><p>SNA Server named pipe.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>SQL\QUERY</p></td>
<td align="left"><p>Default named pipe for SQL Server.</p></td>
</tr>
<tr class="even">
<td align="left"><p>SPOOLSS</p></td>
<td align="left"><p>Named pipe for the Print Spooler service.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>EPMAPPER</p></td>
<td align="left"><p>End Point Mapper named pipe.</p></td>
</tr>
<tr class="even">
<td align="left"><p>LOCATOR</p></td>
<td align="left"><p>Remote Procedure Call Locator service named pipe.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>TrlWks</p></td>
<td align="left"><p>Distributed Link Tracking Client named pipe.</p></td>
</tr>
<tr class="even">
<td align="left"><p>TrkSvr</p></td>
<td align="left"><p>Distributed Link Tracking Server named pipe.</p></td>
</tr>
</tbody>
</table>
| Named pipe | Purpose |
| - | - |
| COMNAP | SNABase named pipe. Systems network Architecture (SNA) is a collection of network protocols that were originally developed for IBM mainframe computers.|
| COMNODE| SNA Server named pipe.|
| SQL\QUERY | Default named pipe for SQL Server.|
| SPOOLSS | Named pipe for the Print Spooler service.|
| EPMAPPER | End Point Mapper named pipe.|
| LOCATOR | Remote Procedure Call Locator service named pipe.|
| TrlWks | Distributed Link Tracking Client named pipe.|
| TrkSvr | Distributed Link Tracking Server named pipe.|
 
### 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)
 
 
- [Security Options](security-options.md)

89
windows/keep-secure/network-access-remotely-accessible-registry-paths-and-subpaths.md
View File

@ -2,69 +2,57 @@
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
ms.pagetype: security
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.
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>See the following registry key combination</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>See the following registry key combination</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>See the following registry key combination</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>See the following registry key combination</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy | Not defined|
| Default Domain Controller Policy | Not defined|
| Stand-Alone Server Default Settings | See the following registry key combination|
| DC Effective Default Settings | See the following registry key combination|
| Member Server Effective Default Settings | See the following registry key combination|
| Client Computer Effective Default Settings | See the following registry key combination|
 
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
@ -76,22 +64,33 @@ The combination of all the following registry keys apply to the previous setting
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.
>**Note:**  If you want to allow remote access, you must also enable the Remote Registry service.
 
## Related topics
[Security Options](security-options.md)
 
 
- [Security Options](security-options.md)

86
windows/keep-secure/network-access-remotely-accessible-registry-paths.md
View File

@ -2,88 +2,86 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>See the following registry key combination</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>See the following registry key combination</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>See the following registry key combination</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>See the following registry key combination</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy | Not defined|
| Default Domain Controller Policy | Not defined|
| Stand-Alone Server Default Settings | See the following registry key combination|
| DC Effective Default Settings | See the following registry key combination|
| Member Server Effective Default Settings | See the following registry key combination|
| Client Computer Effective Default Settings | See the following registry key combination|
 
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.
>**Note:**  If you want to allow remote access, you must also enable the Remote Registry service.
 
## Related topics
[Security Options](security-options.md)
 
 
- [Security Options](security-options.md)

83
windows/keep-secure/network-access-restrict-anonymous-access-to-named-pipes-and-shares.md
View File

@ -2,81 +2,78 @@
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
ms.pagetype: security
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.
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
</tbody>
</table>
| 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
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)
 
 
- [Security Options](security-options.md)

79
windows/keep-secure/network-access-shares-that-can-be-accessed-anonymously.md
View File

@ -2,79 +2,74 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy| Not defined|
| Default Domain Controller Policy | Not defined|
| Stand-Alone Server Default Settings | Not defined|
| DC 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 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)
 
 
- [Security Options](security-options.md)

85
windows/keep-secure/network-access-sharing-and-security-model-for-local-accounts.md
View File

@ -2,88 +2,85 @@
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
ms.pagetype: security
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.
>**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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Classic (local users authenticate as themselves)</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Classic (local users authenticate as themselves)</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Classic (local users authenticate as themselves)</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Classic (local users authenticate as themselves)</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy | Not defined|
| Default Domain Controller Policy | Not defined|
| Stand-Alone Server Default Settings | Classic (local users authenticate as themselves)|
| DC Effective Default Settings | Classic (local users authenticate as themselves)|
| Member Server Effective Default Settings | Classic (local users authenticate as themselves)|
| Client Computer Effective Default Settings | Classic (local users authenticate as themselves)|
 
## 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)
 
 
- [Security Options](security-options.md)

33
windows/keep-secure/network-list-manager-policies.md
View File

@ -2,50 +2,75 @@
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
ms.pagetype: security
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:
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.
 
 

118
windows/keep-secure/network-security-allow-local-system-to-use-computer-identity-for-ntlm.md
View File

@ -2,115 +2,87 @@
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
ms.pagetype: security
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
<table>
<colgroup>
<col width="33%" />
<col width="33%" />
<col width="33%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Setting</th>
<th align="left">Windows Server 2008 and Windows Vista</th>
<th align="left">At least Windows Server 2008 R2 and Windows 7</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Enabled</p></td>
<td align="left"><p>Services running as Local System that use Negotiate will use the computer identity. This might cause some authentication requests between Windows operating systems to fail and log an error.</p></td>
<td align="left"><p>Services running as Local System that use Negotiate will use the computer identity. This is the default behavior.</p></td>
</tr>
<tr class="even">
<td align="left"><p>Disabled</p></td>
<td align="left"><p>Services running as Local System that use Negotiate when reverting to NTLM authentication will authenticate anonymously. This is the default behavior.</p></td>
<td align="left"><p>Services running as Local System that use Negotiate when reverting to NTLM authentication will authenticate anonymously.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Neither</p></td>
<td align="left"><p>Services running as Local System that use Negotiate when reverting to NTLM authentication will authenticate anonymously.</p></td>
<td align="left"><p>Services running as Local System that use Negotiate will use the computer identity. This might cause some authentication requests between Windows operating systems to fail and log an error.</p></td>
</tr>
</tbody>
</table>
| Setting | Windows Server 2008 and Windows Vista | At least Windows Server 2008 R2 and Windows 7 |
| - | - |
| Enabled | Services running as Local System that use Negotiate will use the computer identity. This might cause some authentication requests between Windows operating systems to fail and log an error.| Services running as Local System that use Negotiate will use the computer identity. This is the default behavior. |
| Disabled| Services running as Local System that use Negotiate when reverting to NTLM authentication will authenticate anonymously. This is the default behavior.| Services running as Local System that use Negotiate when reverting to NTLM authentication will authenticate anonymously.|
|Neither|Services running as Local System that use Negotiate when reverting to NTLM authentication will authenticate anonymously. | Services running as Local System that use Negotiate will use the computer identity. This might cause some authentication requests between Windows operating systems to fail and log an error.|
 
### 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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or Group Policy object (GPO)</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default domain policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default domain controller policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-alone server default settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain controller effective default settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member server effective default settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
<tr class="even">
<td align="left"><p>Effective GPO default settings on client computers</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
</tbody>
</table>
| 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 defined|
| Domain controller effective default settings | Not applicable|
| Member server effective default settings | Not applicable|
| Effective GPO default settings on client computers | Not defined|
 
## 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)
 
 
- [Security Options](security-options.md)

85
windows/keep-secure/network-security-allow-localsystem-null-session-fallback.md
View File

@ -2,78 +2,75 @@
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
ms.pagetype: security
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.
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.
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
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or Group Policy Object (GPO)</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default domain policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default domain controller policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-alone server default settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain controller effective default settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member server effective default settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
<tr class="even">
<td align="left"><p>Effective GPO default settings on client computers</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
</tbody>
</table>
| 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 defined|
| Domain controller effective default settings | Not applicable|
| Member server effective default settings | Not applicable |
| Effective GPO default settings on client computers | Not applicable|
 
## 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)
 
 
- [Security Options](security-options.md)

84
windows/keep-secure/network-security-allow-pku2u-authentication-requests-to-this-computer-to-use-online-identities.md
View File

@ -2,83 +2,79 @@
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
ms.pagetype: security
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**.
>**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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or Group Policy Object (GPO)</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default domain policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default domain controller policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-alone server default settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain controller effective default settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member server effective default settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Effective GPO default settings on client computers</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
</tbody>
</table>
| 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 defined|
| Domain controller effective default settings | Disabled|
| Member server effective default settings | Disabled|
| Effective GPO default settings on client computers | 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
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)
 
 
- [Security Options](security-options.md)

133
windows/keep-secure/network-security-configure-encryption-types-allowed-for-kerberos.md
View File

@ -2,128 +2,89 @@
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
ms.pagetype: security
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Encryption type</th>
<th align="left">Description and version support</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>DES_CBC_CRC</p></td>
<td align="left"><p>Data Encryption Standard with Cipher Block Chaining using the Cyclic Redundancy Check function</p>
<p>Supported in Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. The Windows 7 and Windows Server 2008 R2 operating systems do not support DES by default.</p></td>
</tr>
<tr class="even">
<td align="left"><p>DES_CBC_MD5</p></td>
<td align="left"><p>Data Encryption Standard with Cipher Block Chaining using the Message-Digest algorithm 5 checksum function</p>
<p>Supported in Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. The Windows 7 and Windows Server 2008 R2 operating systems do not support DES by default.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>RC4_HMAC_MD5</p></td>
<td align="left"><p>Rivest Cipher 4 with Hashed Message Authentication Code using the Message-Digest algorithm 5 checksum function</p>
<p>Supported in Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2.</p></td>
</tr>
<tr class="even">
<td align="left"><p>AES128_HMAC_SHA1</p></td>
<td align="left"><p>Advanced Encryption Standard in 128 bit cipher block with Hashed Message Authentication Code using the Secure Hash Algorithm (1).</p>
<p>Not supported in Windows 2000 Server, Windows XP, or Windows Server 2003. Supported in Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>AES256_HMAC_SHA1</p></td>
<td align="left"><p>Advanced Encryption Standard in 256 bit cipher block with Hashed Message Authentication Code using the Secure Hash Algorithm (1).</p>
<p>Not supported in Windows 2000 Server, Windows XP, or Windows Server 2003. Supported in Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2.</p></td>
</tr>
<tr class="even">
<td align="left"><p>Future encryption types</p></td>
<td align="left"><p>Reserved by Microsoft for additional encryption types that might be implemented.</p></td>
</tr>
</tbody>
</table>
| Encryption type | Description and version support |
| - | - |
| DES_CBC_CRC | Data Encryption Standard with Cipher Block Chaining using the Cyclic Redundancy Check function<br/>Supported in Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. The Windows 7 and Windows Server 2008 R2 operating systems do not support DES| by default.
| DES_CBC_MD5| Data Encryption Standard with Cipher Block Chaining using the Message-Digest algorithm 5 checksum function<br/>Supported in Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. The Windows 7 and Windows Server 2008 R2 operating systems do not support DES by default. |
| RC4_HMAC_MD5| Rivest Cipher 4 with Hashed Message Authentication Code using the Message-Digest algorithm 5 checksum function<br/>Supported in Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2.|
| AES128_HMAC_SHA1| Advanced Encryption Standard in 128 bit cipher block with Hashed Message Authentication Code using the Secure Hash Algorithm (1).<br/>Not supported in Windows 2000 Server, Windows XP, or Windows Server 2003. Supported in Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. |
| AES256_HMAC_SHA1| Advanced Encryption Standard in 256 bit cipher block with Hashed Message Authentication Code using the Secure Hash Algorithm (1).<br/>Not supported in Windows 2000 Server, Windows XP, or Windows Server 2003. Supported in Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. |
| Future encryption types| Reserved by Microsoft for additional encryption types that might be implemented.|
 
### 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
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or Group Policy Object (GPO)</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default domain policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default domain controller policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-alone server default settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain controller effective default settings</p></td>
<td align="left"><p>None of these encryption types that are available in this policy are allowed.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member server effective default settings</p></td>
<td align="left"><p>None of these encryption types that are available in this policy are allowed.</p></td>
</tr>
<tr class="even">
<td align="left"><p>Effective GPO default settings on client computers</p></td>
<td align="left"><p>None of these encryption types that are available in this policy are allowed.</p></td>
</tr>
</tbody>
</table>
| 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 defined|
| Domain controller effective default settings | None of these encryption types that are available in this policy are allowed.|
| Member server effective default settings | None of these encryption types that are available in this policy are allowed.|
| Effective GPO default settings on client computers | None of these encryption types that are available in this policy are allowed.|
 
## 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.
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)
 
 
- [Security Options](security-options.md)

Some files were not shown because too many files have changed in this diff Show More