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

devices/surface/microsoft-surface-deployment-accelerator.md

@@ -13,17 +13,17 @@ author: miladCA
 # Microsoft Surface Deployment Accelerator
 
 
-Microsoft Surface Deployment Accelerator provides a quick and simple deployment mechanism for organizations to reimage Surface devices.
+Microsoft Surface Deployment Accelerator (SDA) provides a quick and simple deployment mechanism for organizations to reimage Surface devices.
 
-Microsoft Surface Deployment Accelerator includes a wizard that automates the creation and configuration of a Microsoft recommended deployment experience by using free Microsoft deployment tools. The resulting deployment solution is complete with everything you need to immediately begin the deployment of Windows to a Surface device. You can also use Microsoft Surface Deployment Accelerator to create and capture a Windows reference image and then deploy it with the latest Windows Updates.
+SDA includes a wizard that automates the creation and configuration of a Microsoft recommended deployment experience by using free Microsoft deployment tools. The resulting deployment solution is complete with everything you need to immediately begin the deployment of Windows to a Surface device. You can also use SDA to create and capture a Windows reference image and then deploy it with the latest Windows updates.
 
-Microsoft Surface Deployment Accelerator is built on the powerful suite of deployment tools available from Microsoft including the Windows Assessment and Deployment Kit (ADK), the Microsoft Deployment Toolkit (MDT), and Windows Deployment Services (WDS). The resulting deployment share encompasses the recommended best practices for managing drivers during deployment and automating image creation and can serve as a starting point upon which you build your own customized deployment solution.
+SDA is built on the powerful suite of deployment tools available from Microsoft including the Windows Assessment and Deployment Kit (ADK), the Microsoft Deployment Toolkit (MDT), and Windows Deployment Services (WDS). The resulting deployment share encompasses the recommended best practices for managing drivers during deployment and automating image creation and can serve as a starting point upon which you build your own customized deployment solution.
 
 You can find more information about how to deploy to Surface devices, including step-by-step walkthroughs of customized deployment solution implementation, on the Deploy page of the [Surface TechCenter](http://go.microsoft.com/fwlink/p/?LinkId=691693).
 
 **Download Microsoft Surface Deployment Accelerator**
 
-You can download the installation files for Microsoft Surface Deployment Accelerator from the Microsoft Download Center. To download the installation files:
+You can download the installation files for SDA from the Microsoft Download Center. To download the installation files:
 
 1.  Go to the [Surface Tools for IT](http://go.microsoft.com/fwlink/p/?LinkId=618121) page on the Microsoft Download Center.
 
@@ -32,9 +32,9 @@ You can download the installation files for Microsoft Surface Deployment Acceler
 ## Microsoft Surface Deployment Accelerator prerequisites
 
 
-Before you install Microsoft Surface Deployment Accelerator, your environment must meet the following prerequisites:
+Before you install SDA, your environment must meet the following prerequisites:
 
--   Microsoft Surface Deployment Accelerator must be installed on Windows Server 2012 R2 or later
+-   SDA must be installed on Windows Server 2012 R2 or later
 
 -   PowerShell Script Execution Policy must be set to **Unrestricted**
 
@@ -44,45 +44,74 @@ Before you install Microsoft Surface Deployment Accelerator, your environment mu
 
 -   To support network boot, the Windows Server 2012 R2 environment must have Windows Deployment Services installed and configured to respond to PXE requests
 
--   Access to Windows source files or installation media is required when you prepare a deployment with Microsoft Surface Deployment Accelerator
+-   Access to Windows source files or installation media is required when you prepare a deployment with SDA
 
 -   At least 6 GB of free space for each version of Windows you intend to deploy
 
 ## How Microsoft Surface Deployment Accelerator works
 
 
-As you progress through the Microsoft Surface Deployment Accelerator wizard, you will be asked some basic questions about how your deployment solution should be configured. As you select the desired Surface models to be supported and apps to be installed (see Figure 1), the wizard will prepare scripts that download, install, and configure everything needed to perform a complete deployment and capture of a reference image. By using the network boot (PXE) capabilities of Windows Deployment Services (WDS), the resulting solution enables you to boot a Surface device from the network and perform a clean deployment of Windows.
+As you progress through the SDA wizard, you will be asked some basic questions about how your deployment solution should be configured. As you select the desired Surface models to be supported and apps to be installed (see Figure 1), the wizard will prepare scripts that download, install, and configure everything needed to perform a complete deployment and capture of a reference image. By using the network boot (PXE) capabilities of Windows Deployment Services (WDS), the resulting solution enables you to boot a Surface device from the network and perform a clean deployment of Windows.
 
-![figure 1](images/sda-fig1-select-steps.png)
+![Software and driver selection window](images/sda-fig1-select-steps.png "Software and driver selection window")
 
-Figure 1: Select desired apps and drivers
+*Figure 1. Select desired apps and drivers*
 
-When the Microsoft Surface Deployment Accelerator completes, you can use the deployment share to deploy over the network immediately. Simply boot your Surface device from the network using a Surface Ethernet Adapter and select the Surface deployment share you created with the Microsoft Surface Deployment Accelerator wizard. Select the **1- Deploy Microsoft Surface** task sequence and the wizard will walk you through an automated deployment of Windows to your Surface device.
+When the SDA completes, you can use the deployment share to deploy over the network immediately. Simply boot your Surface device from the network using a Surface Ethernet Adapter and select the Surface deployment share you created with the SDA wizard. Select the **1- Deploy Microsoft Surface** task sequence and the wizard will walk you through an automated deployment of Windows to your Surface device.
 
 You can modify the task sequence in the MDT Deployment Workbench to [include your own apps](http://go.microsoft.com/fwlink/p/?linkid=691700), or to [pause the automated installation routine](http://go.microsoft.com/fwlink/p/?linkid=691701). While the installation is paused, you can make changes to customize your reference image. After the image is captured, you can configure a deployment task sequence and distribute this custom configuration by using the same network boot capabilities as before.
 
->**Note:**  With Microsoft Surface Deployment Accelerator v1.9.0258, Surface Pro 3, Surface Pro 4, and Surface Book are supported for Windows 10 deployment, and Surface Pro 3 is supported for Windows 8.1 deployment.
+>**Note:**  With SDA v1.9.0258, Surface Pro 3, Surface Pro 4, and Surface Book are supported for Windows 10 deployment, and Surface Pro 3 is supported for Windows 8.1 deployment.
 
  
 
 ## <a href="" id="use-microsoft-surface-deployment-accelerator-without-an-internet-connection--"></a>Use Microsoft Surface Deployment Accelerator without an Internet connection
 
 
-For environments where the Microsoft Surface Deployment Accelerator server will not be able to connect to the Internet, the required Surface files can be downloaded separately. To specify a local source for Surface driver and app files, select the **Copy from a local directory** option and specify the location of your downloaded files (see Figure 2). All of the driver and app files for your selected choices must be placed in the specified folder.
+For environments where the SDA server will not be able to connect to the Internet, the required Surface files can be downloaded separately. To specify a local source for Surface driver and app files, select the **Copy from a local directory** option and specify the location of your downloaded files (see Figure 2). All of the driver and app files for your selected choices must be placed in the specified folder.
 
-![figure 2](images/sda-fig2-specify-local.png)
+![Specify a local source for Surface driver and app files](images/sda-fig2-specify-local.png "Specify a local source for Surface driver and app files")
 
-Figure 2. Specify a local source for Surface driver and app files
+*Figure 2. Specify a local source for Surface driver and app files*
 
 You can find a full list of available driver downloads at [Download the latest firmware and drivers for Surface devices](deploy-the-latest-firmware-and-drivers-for-surface-devices.md)
 
 >**Note:**&nbsp;&nbsp;Downloaded files do not need to be extracted. The downloaded files can be left as .zip files as long as they are stored in one folder.
 
+>**Note:**&nbsp;&nbsp;Using files from a local directory is not supported when including Office 365 in your deployment share. To include Office 365 in your deployment share, select the **Download from the Internet** check box. 
+
+## Changes and updates
+
+SDA is periodically updated by Microsoft. For instructions on how these features are used, see [Step-by-Step: Microsoft Surface Deployment Accelerator](https://technet.microsoft.com/en-us/itpro/surface/step-by-step-surface-deployment-accelerator).
+
+>**Note:**&nbsp;&nbsp;To install a newer version of SDA on a server with a previous version of SDA installed, you only need to run the installation file for the new version of SDA. The installer will handle the upgrade process automatically. If you used SDA to create a deployment share prior to the upgrade and want to use new features of the new version of SDA, you will need to create a new deployment share. SDA does not support upgrades of an existing deployment share.
  
+### Version 1.96.0405
+This version of SDA adds support for the following:
+* Microsoft Deployment Toolkit (MDT) 2013 Update 2
+* Office 365 Click-to-Run
+* Surface 3 and Surface 3 LTE
+* Reduced Windows Assessment and Deployment Kit (Windows ADK) footprint, only the following Windows ADK components are installed:
+  * Deployment tools
+  * Windows Preinstallation Environment (WinPE)
+  * User State Migration Tool (USMT)
 
- 
+### Version 1.90.0258
+This version of SDA adds support for the following:
+* Surface Book
+* Surface Pro 4
+* Windows 10
 
- 
+### Version 1.90.0000
+This version of SDA adds support for the following:
+* Local driver and app files can be used to create a deployment share without access to the Internet
+
+### Version 1.70.0000
+This version is the original release of SDA. This version of SDA includes support for:
+* MDT 2013 Update 1
+* Windows ADK
+* Surface Pro 3
+* Windows 8.1
 
 
 

devices/surface/step-by-step-surface-deployment-accelerator.md

@@ -26,17 +26,17 @@ For information about prerequisites and instructions for how to download and ins
 
 3.  Accept the End User License Agreement (EULA) by selecting the check box, and then click **Install**, as shown in Figure 1.
 
-    ![figure 1](images/sdasteps-fig1.png)
+    ![Surface Deployment Accelerator setup](images/sdasteps-fig1.png "Surface Deployment Accelerator setup")
 
-    Figure 1. SDA setup
+    *Figure 1. SDA setup*
 
 4.  Click **Finish** to complete the installation of SDA.
 
-The tool installs in the Surface Deployment Accelerator program group, as shown in Figure 2.
+The tool installs in the SDA program group, as shown in Figure 2.
 
-![figure 2](images/sdasteps-fig2.png)
+![SDA program group and icon](images/sdasteps-fig2.png "SDA program group and icon")
 
-Figure 2. The Surface Deployment Accelerator program group and icon
+*Figure 2. The SDA program group and icon*
 
 >**Note:**  At this point the tool has not yet prepared any deployment environment or downloaded any materials from the Internet.
 
@@ -45,7 +45,7 @@ Figure 2. The Surface Deployment Accelerator program group and icon
 ## Create a deployment share
 
 
-The following steps show how you create a deployment share for Windows 10 that supports Surface Pro 3, Surface Pro 4, Surface Book, the Surface Firmware Tool, and the Surface Asset Tag Tool. As you follow the steps below, make the selections that are applicable for your organization. For example, you could choose to deploy Windows 10 to Surface Book only, without any of the Surface apps.
+The following steps show you how to create a deployment share for Windows 10 that supports Surface 3, Surface Pro 3, Surface Pro 4, Surface Book, the Surface Firmware Tool, the Surface Asset Tag Tool, and Office 365. As you follow the steps below, make the selections that are applicable for your organization. For example, you could choose to deploy Windows 10 to Surface Book only, without any of the Surface apps.
 
 >**Note:**  SDA lets you create deployment shares for both Windows 8.1 and Windows 10 deployments, but you can only create a single deployment share at a time. Therefore, to create both Windows 8.1 and Windows 10 deployment shares, you will need to run the tool twice.
 
@@ -55,7 +55,14 @@ The following steps show how you create a deployment share for Windows 10 that
 
 2.  On the **Welcome** page, click **Next** to continue.
 
-3.  On the **Verify System** page, the SDA wizard verifies the prerequisites required for an SDA deployment share. This process also checks for the presence of the Windows Assessment and Deployment Kit (ADK) for Windows 10 and the Microsoft Deployment Toolkit (MDT) 2013 Update 1. If these tools are not detected, they are downloaded and installed automatically. Click **Next** to continue.
+3.  On the **Verify System** page, the SDA wizard verifies the prerequisites required for an SDA deployment share. This process also checks for the presence of the Windows Assessment and Deployment Kit (Windows ADK) for Windows 10 and the Microsoft Deployment Toolkit (MDT) 2013 Update 2. If these tools are not detected, they are downloaded and installed automatically. Click **Next** to continue.
+
+  >**Note:**  As of SDA version 1.96.0405, SDA will install only the components of the Windows ADK that are required for deployment, as follows:
+    * Deployment tools
+    * User State Migration Tool (USMT)
+    * Windows Preinstallation Environment (WinPE)</br>
+
+  >**Note:**&nbsp;&nbsp;As of SDA version 1.96.0405, SDA will install and use MDT 2013 Update 2. Earlier versions of SDA are compatible only with MDT 2013 Update 1.
 
 4.  On the **Windows 8.1** page, to create a Windows 10 deployment share, do not select the **Would you like to support Windows 8.1** check box. Click **Next** to continue.
 
@@ -75,15 +82,17 @@ The following steps show how you create a deployment share for Windows 10 that
 
         -   **Local Path** – Specify or browse to the root directory of Windows 10 installation files. If you have an ISO file, mount it and browse to the root of the mounted drive. You must have a full set of source files, not just **Install.wim**.
 
-    ![figure 3](images/sdasteps-fig3.png)
+    ![Specify Windows 10 deployment share options](images/sdasteps-fig3.png "Specify Windows 10 deployment share options")
 
-    Figure 3. Specify Windows 10 deployment share options
+    *Figure 3. Specify Windows 10 deployment share options*
 
-6.  On the **Configure** page, select the check box next to each device or app that you want to include in your deployment share. Note that Surface Pro 4 and Surface Book only support Windows 10 and are not available for the deployment of Windows 8.1. The Surface Firmware Tool is only applicable to Surface Pro 3 and cannot be selected unless Surface Pro 3 drivers are selected, as shown in Figure 4. Click **Next** to continue.
+6.  On the **Configure** page, select the check box next to each device or app that you want to include in your deployment share. Note that Surface Pro 4 and Surface Book only support Windows 10 and are not available for the deployment of Windows 8.1. The Surface Firmware Tool is only applicable to Surface 3 and Surface Pro 3 and cannot be selected unless Surface 3 or Surface Pro 3 drivers are selected, as shown in Figure 4. Click **Next** to continue.
 
-    ![figure 4](images/sdasteps-fig4-select.png)
+    ![Firmware tool selection](images/sdasteps-fig4-select.png "Firmware tool selection")
 
-    Figure 4. Selecting Surface Firmware Tool requires Surface Pro 3 drivers
+    *Figure 4. Selecting Surface Firmware Tool requires Surface Pro 3 drivers*
+
+    >**Note:**&nbsp;&nbsp;You cannot select both Surface 3 and Surface 3 LTE models at the same time.
 
 7.  On the **Summary** page confirm your selections and click **Finish** to begin the creation of your deployment share. The process can take several minutes as files are downloaded, the tools are installed, and the deployment share is created. While the SDA scripts are creating your deployment share, an **Installation Progress** window will be displayed, as shown in Figure 5. A typical SDA process includes:
 
@@ -105,9 +114,9 @@ The following steps show how you create a deployment share for Windows 10 that
 
     -   Creation of rules and task sequences for Windows deployment
 
-    ![figure 5](images/sdasteps-fig5-installwindow.png)
+    ![The installatin progress window](images/sdasteps-fig5-installwindow.png "The installatin progress window")
 
-    Figure 5. The **Installation Progress** window
+    *Figure 5. The **Installation Progress** window*
 
 8.  When the SDA process completes the creation of your deployment share, a **Success** window is displayed. Click **Finish** to close the window. At this point your deployment share is now ready to perform a Windows deployment to Surface devices.
 
@@ -115,13 +124,15 @@ The following steps show how you create a deployment share for Windows 10 that
 
 If you are unable to connect to the Internet with your deployment server, or if you want to download the Surface drivers and apps separately, you can specify a local source for the driver an app files at the time of deployment share creation. On the **Configure** page of the SDA wizard, select the **Copy from a Local Directory** check box, as shown in Figure 6. The **Download from the Internet** check box will be automatically deselected. Enter the folder location where you have placed the driver and app files in the **Local Path** field, as shown in Figure 6.
 
->**Note:**&nbsp;&nbsp;All of the downloaded driver and applications files must be located in the same folder. The driver and app files do not need to be extracted from the downloaded .zip files.
+>**Note:**&nbsp;&nbsp;All of the downloaded driver and applications files must be located in the same folder. If a required driver or application file is missing from the selected folder when you click **Next**, a warning is displayed and the wizard will not proceed to the next step.
 
- 
+>**Note:**&nbsp;&nbsp;The driver and app files do not need to be extracted from the downloaded .zip files.
 
-![figure 6](images/sdasteps-fig6-specify-driver-app-files.png)
+>**Note:**&nbsp;&nbsp;Including Office 365 in your deployment share requires an Internet connection and cannot be performed if you use local files.
 
-Figure 6. Specify the Surface driver and app files from a local path
+![Specify Surface driver and app files](images/sdasteps-fig6-specify-driver-app-files.png "Specify Surface driver and app files")
+
+*Figure 6. Specify the Surface driver and app files from a local path*
 
 >**Note:**&nbsp;&nbsp;The **Copy from a Local Directory** check box is only available in SDA version 1.90.0221 or later.
 
@@ -159,9 +170,9 @@ Before you can create bootable media files within the MDT Deployment Workbench o
 
 9.  **exit** – Exits DiskPart, after which you can close the PowerShell or Command Prompt window.
 
-    ![figure 7](images/sdasteps-fig7-diskpart.png)
+    ![Use DiskPart to prepare a USB drive for boot](images/sdasteps-fig7-diskpart.png "Use DiskPart to prepare a USB drive for boot")
 
-    Figure 7. Use DiskPart to prepare a USB drive for boot
+    *Figure 7. Use DiskPart to prepare a USB drive for boot*
 
     >**Note:**&nbsp;&nbsp;You can format your USB drive with FAT32 from Disk Management, but you must still use DiskPart to set the partition as active for the drive to boot properly.
 
@@ -177,15 +188,15 @@ After you have prepared the USB drive for boot, the next step is to generate off
 
 4.  Right-click the **Media** folder and click **New Media** as shown in Figure 8 to start the New Media Wizard.
 
-    ![figure 8](images/sdasteps-fig8-mediafolder.png)
+    ![The Media folder of the SDA deployment share](images/sdasteps-fig8-mediafolder.png "The Media folder of the SDA deployment share")
 
-    Figure 8. The Media folder of the SDA deployment share
+    *Figure 8. The Media folder of the SDA deployment share*
 
 5.  On the **General Settings** page in the **Media path** field, enter or browse to a folder where you will create the files for the new offline media. See the example **E:\\SDAMedia** in Figure 9. Leave the default profile **Everything** selected in the **Selection profile** drop-down menu, and then click **Next**.
 
-    ![figure 9](images/sdasteps-fig9-location.png)
+    ![Specify a location and selection profile for your offline media](images/sdasteps-fig9-location.png "Specify a location and selection profile for your offline media")
 
-    Figure 9. Specify a location and selection profile for your offline media
+    *Figure 9. Specify a location and selection profile for your offline media*
 
 6.  On the **Summary** page verify your selections, and then click **Next** to begin creation of the media.
 
@@ -195,9 +206,9 @@ After you have prepared the USB drive for boot, the next step is to generate off
 
 9.  Right-click the **Microsoft Surface Deployment Accelerator** deployment share folder, click **Properties**, and then click the **Rules** tab as shown in Figure 10.
 
-    ![figure 10](images/sdasteps-fig10-rules.png)
+    ![Rules of the SDA deployment share](images/sdasteps-fig10-rules.png "Rules of the SDA deployment share")
 
-    Figure 10. The Rules of the SDA deployment share
+    *Figure 10. Rules of the SDA deployment share*
 
 10. Use your mouse to highlight all of the text displayed in the text box of the **Rules** tab, and then press **Ctrl+C** to copy the text.
 
@@ -229,15 +240,17 @@ After you have prepared the USB drive for boot, the next step is to generate off
     UserPassword=
     ```
 
-    ![figure 11](images/sdasteps-fig11-bootstrap.ini.png)
+    ![The Bootstrap.ini file](images/sdasteps-fig11-bootstrap.ini.png "The Bootstrap.ini file")
 
-    Figure 11. The Bootstrap.ini file of MEDIA001
+    *Figure 11. The Bootstrap.ini file of MEDIA001*
 
 20. Close Bootstrap.ini and click **OK** in **MEDIA001** deployment share properties to close the window.
 
 21. In the **Deployment Workbench** under the **Media** folder, right-click the newly created **MEDIA001** and click **Update Media Content**, as shown in Figure 12. This will update the media files with the content of the **Microsoft Surface Deployment Accelerator** deployment share.
 
-    ![figure 12](images/sdasteps-fig12-updatemedia.png)Figure 12. Select **Update Media Content**
+    ![Select the Update Media Content option](images/sdasteps-fig12-updatemedia.png "Select the Update Media Content option")
+    
+    *Figure 12. Select the **Update Media Content** option*
 
 22. The **Update Media Content** window is displayed and shows the progress as the media files are created. When the process completes, click **Finish.**
 
@@ -252,11 +265,11 @@ Your USB drive is now configured as bootable offline media that contains all of
 ## SDA task sequences
 
 
-The SDA deployment share is configured with all of the resources required to perform a Windows deployment to a Surface device. These resources include Windows source files, image, Surface drivers, and Surface apps. The deployment share also contains two pre-configured task sequences, as shown in Figure 13. These task sequences contain the steps required to perform a deployment to a Surface device using the default Windows image from the installation media or to create a reference image complete with Windows updates and applications. To learn more about task sequences, see [MDT 2013 Update 1 Lite Touch components](http://technet.microsoft.com/en-us/itpro/windows/deploy/mdt-2013-lite-touch-components).
+The SDA deployment share is configured with all of the resources required to perform a Windows deployment to a Surface device. These resources include Windows source files, image, Surface drivers, and Surface apps. The deployment share also contains two pre-configured task sequences, as shown in Figure 13. These task sequences contain the steps required to perform a deployment to a Surface device using the default Windows image from the installation media or to create a reference image complete with Windows updates and applications. To learn more about task sequences, see [MDT 2013 Update 2 Lite Touch components](https://technet.microsoft.com/itpro/windows/deploy/mdt-2013-lite-touch-components).
 
-![figure 13](images/sdasteps-fig13-taskseq.png)
+![Task sequences in the Deployment Workbench](images/sdasteps-fig13-taskseq.png "Task sequences in the Deployment Workbench")
 
-Figure 13. Task sequences in the Deployment Workbench
+*Figure 13. Task sequences in the Deployment Workbench*
 
 ### Deploy Microsoft Surface
 
@@ -286,7 +299,7 @@ The **2 – Create Windows Reference Image** task sequence is used to perform a
 
 Like the **1 – Deploy Microsoft Surface** task sequence, the **2 – Create Windows Reference Image** task sequence performs a deployment of the unaltered Windows image directly from the installation media. Creation of a reference image should always be performed on a virtual machine. Using a virtual machine as your reference system helps to ensure that the resulting image is compatible with different hardware configurations.
 
->**Note:**&nbsp;&nbsp;Using a virtual machine when you create a reference image for Windows deployment is a recommended practice for performing Windows deployments with Microsoft deployment tools including the Microsoft Deployment Toolkit and System Center Configuration Manager. These Microsoft deployment technologies use the hardware agnostic images produced from a virtual machine and a collection of managed drivers to deploy to different configurations of hardware. For more information see [Deploy a Windows 10 image using MDT 2013 Update 1](http://technet.microsoft.com/en-us/itpro/windows/deploy/deploy-a-windows-10-image-using-mdt).
+>**Note:**&nbsp;&nbsp;Using a virtual machine when you create a reference image for Windows deployment is a recommended practice for performing Windows deployments with Microsoft deployment tools including the Microsoft Deployment Toolkit and System Center Configuration Manager. These Microsoft deployment technologies use the hardware agnostic images produced from a virtual machine and a collection of managed drivers to deploy to different configurations of hardware. For more information, see [Deploy a Windows 10 image using MDT 2013 Update 2](http://technet.microsoft.com/en-us/itpro/windows/deploy/deploy-a-windows-10-image-using-mdt).
 
  
 
@@ -323,9 +336,9 @@ To instruct your Surface device to boot from the network, start with the device
 
 4.  Enter the domain credentials that you use to log on to the server where SDA is installed when you are prompted, as shown in Figure 14.
 
-    ![figure 14](images/sdasteps-fig14-credentials.png)
+    ![Prompt for credentials to the deployment share](images/sdasteps-fig14-credentials.png "Prompt for credentials to the deployment share")
 
-    Figure 14. The prompt for credentials to the deployment share
+    *Figure 14. The prompt for credentials to the deployment share*
 
 5.  The Windows Deployment Wizard will start from the deployment share to walk you through the deployment process.
 
@@ -343,15 +356,15 @@ To run the Deploy Microsoft Surface task sequence:
 
 1.  On the **Task Sequence** page, select the **1 – Deploy Microsoft Surface** task sequence as shown in Figure 15, and then click **Next.**
 
-    ![figure 15](images/sdasteps-fig15-deploy.png)
+    ![Select the task sequence](images/sdasteps-fig15-deploy.png "Select the task sequence")
 
-    Figure 15. Select the **1 – Deploy Microsoft Surface** task sequence
+    *Figure 15. Select the **1 – Deploy Microsoft Surface** task sequence*
 
 2.  On the **Computer Details** page, type a name for the Surface device in the **Computer Name** box. In the **Join a domain** section, type your domain name and credentials as shown in Figure 16, and then click **Next**.
 
-    ![figure 16](images/sdasteps-fig16-computername.png)
+    ![Computer name and domain credentials](images/sdasteps-fig16-computername.png "Computer name and domain credentials")
 
-    Figure 16. Enter the computer name and domain information
+    *Figure 16. Enter the computer name and domain information*
 
 3.  On the **Product Key** page, keep the **No product key is required** check box selected if you are deploying the same version and edition of Windows to your Surface devices as they came with from the factory. If you are deploying a different version or edition of Windows to the device, such as Windows Enterprise, select the licensing option that is applicable to your scenario.
 
@@ -363,9 +376,9 @@ To run the Deploy Microsoft Surface task sequence:
 
 7.  On the **Ready** page, verify your selections and then click **Begin** to start the automated deployment to this device. The deployment will not require user interaction again. The Windows Deployment Wizard will close and an **Installation Progress** window is displayed to show progress of the task sequence as the image is applied and applications are installed (Figure 17).
 
-    ![figure 17](images/sdasteps-fig17-installprogresswindow.png)
+    ![Installation progress window](images/sdasteps-fig17-installprogresswindow.png "Installation progress window")
 
-    Figure 17. The **Installation Progress** window
+    *Figure 17. The **Installation Progress** window*
 
 8.  When the deployment task sequence completes, a **Success** window is displayed. Click **Finish** to complete the deployment and begin using your Surface device.
 

windows/keep-secure/TOC.md

@@ -28,6 +28,16 @@
 ## [Use Windows Event Forwarding to help with intrusion detection](use-windows-event-forwarding-to-assist-in-instrusion-detection.md)
 ## [VPN profile options](vpn-profile-options.md)
 ## [Security technologies](security-technologies.md)
+### [Access Control Overview](access-control.md)
+#### [Dynamic Access Control Overview](dynamic-access-control.md)
+#### [Security identifiers](security-identifiers.md)
+#### [Security Principals](security-principals.md)
+#### [Local Accounts](local-accounts.md)
+#### [Active Directory Accounts](active-directory-accounts.md)
+#### [Microsoft Accounts](microsoft-accounts.md)
+#### [Service Accounts](service-accounts.md)
+#### [Active Directory Security Groups](active-directory-security-groups.md)
+#### [Special Identities](special-identities.md)
 ### [AppLocker](applocker-overview.md)
 #### [Administer AppLocker](administer-applocker.md)
 ##### [Maintain AppLocker policies](maintain-applocker-policies.md)

windows/keep-secure/access-control.md

@@ -0,0 +1,137 @@
+---
+title: Access Control Overview (Windows 10)
+description: Access Control Overview
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+---
+
+# Access Control Overview
+
+**Applies to**
+-   Windows 10
+-   Windows Server 2016
+
+This topic for the IT professional describes access control in Windows, which is the process of authorizing users, groups, and computers to access objects on the network or computer. Key concepts that make up access control are permissions, ownership of objects, inheritance of permissions, user rights, and object auditing.
+
+## <a href="" id="bkmk-over"></a>Feature description
+
+
+Computers that are running a supported version of Windows can control the use of system and network resources through the interrelated mechanisms of authentication and authorization. After a user is authenticated, the Windows operating system uses built-in authorization and access control technologies to implement the second phase of protecting resources: determining if an authenticated user has the correct permissions to access a resource.
+
+Shared resources are available to users and groups other than the resource’s owner, and they need to be protected from unauthorized use. In the access control model, users and groups (also referred to as security principals) are represented by unique security identifiers (SIDs). They are assigned rights and permissions that inform the operating system what each user and group can do. Each resource has an owner who grants permissions to security principals. During the access control check, these permissions are examined to determine which security principals can access the resource and how they can access it.
+
+Security principals perform actions (which include Read, Write, Modify, or Full control) on objects. Objects include files, folders, printers, registry keys, and Active Directory Domain Services (AD DS) objects. Shared resources use access control lists (ACLs) to assign permissions. This enables resource managers to enforce access control in the following ways:
+
+-   Deny access to unauthorized users and groups
+
+-   Set well-defined limits on the access that is provided to authorized users and groups
+
+Object owners generally grant permissions to security groups rather than to individual users. Users and computers that are added to existing groups assume the permissions of that group. If an object (such as a folder) can hold other objects (such as subfolders and files), it is called a container. In a hierarchy of objects, the relationship between a container and its content is expressed by referring to the container as the parent. An object in the container is referred to as the child, and the child inherits the access control settings of the parent. Object owners often define permissions for container objects, rather than individual child objects, to ease access control management.
+
+This content set contains:
+
+-   [Dynamic Access Control Overview](dynamic-access-control.md)
+
+-   [Security identifiers](security-identifiers.md)
+
+-   [Security Principals](security-principals.md)
+
+    -   [Local Accounts](local-accounts.md)
+
+    -   [Active Directory Accounts](active-directory-accounts.md)
+
+    -   [Microsoft Accounts](microsoft-accounts.md)
+
+    -   [Service Accounts](service-accounts.md)
+
+    -   [Active Directory Security Groups](active-directory-security-groups.md)
+
+## <a href="" id="bkmk-app"></a>Practical applications
+
+
+Administrators who use the supported version of Windows can refine the application and management of access control to objects and subjects to provide the following security:
+
+-   Protect a greater number and variety of network resources from misuse.
+
+-   Provision users to access resources in a manner that is consistent with organizational policies and the requirements of their jobs.
+
+-   Enable users to access resources from a variety of devices in numerous locations.
+
+-   Update users’ ability to access resources on a regular basis as an organization’s policies change or as users’ jobs change.
+
+-   Account for a growing number of use scenarios (such as access from remote locations or from a rapidly expanding variety of devices, such as tablet computers and mobile phones).
+
+-   Identify and resolve access issues when legitimate users are unable to access resources that they need to perform their jobs.
+
+## Permissions
+
+
+Permissions define the type of access that is granted to a user or group for an object or object property. For example, the Finance group can be granted Read and Write permissions for a file named Payroll.dat.
+
+By using the access control user interface, you can set NTFS permissions for objects such as files, Active Directory objects, registry objects, or system objects such as processes. Permissions can be granted to any user, group, or computer. It is a good practice to assign permissions to groups because it improves system performance when verifying access to an object.
+
+For any object, you can grant permissions to:
+
+-   Groups, users, and other objects with security identifiers in the domain.
+
+-   Groups and users in that domain and any trusted domains.
+
+-   Local groups and users on the computer where the object resides.
+
+The permissions attached to an object depend on the type of object. For example, the permissions that can be attached to a file are different from those that can be attached to a registry key. Some permissions, however, are common to most types of objects. These common permissions are:
+
+-   Read
+
+-   Modify
+
+-   Change owner
+
+-   Delete
+
+When you set permissions, you specify the level of access for groups and users. For example, you can let one user read the contents of a file, let another user make changes to the file, and prevent all other users from accessing the file. You can set similar permissions on printers so that certain users can configure the printer and other users can only print.
+
+When you need to change the permissions on a file, you can run Windows Explorer, right-click the file name, and click **Properties**. On the **Security** tab, you can change permissions on the file. For more information, see [Managing Permissions](http://technet.microsoft.com/library/cc770962.aspx).
+
+**Note**  
+Another kind of permissions, called share permissions, is set on the Sharing tab of a folder's **Properties** page or by using the Shared Folder Wizard. For more information see [Share and NTFS Permissions on a File Server](http://technet.microsoft.com/library/cc754178.aspx).
+
+ 
+
+### Ownership of objects
+
+An owner is assigned to an object when that object is created. By default, the owner is the creator of the object. No matter what permissions are set on an object, the owner of the object can always change the permissions. For more information, see [Manage Object Ownership](http://technet.microsoft.com/library/cc732983.aspx).
+
+### Inheritance of permissions
+
+Inheritance allows administrators to easily assign and manage permissions. This feature automatically causes objects within a container to inherit all the inheritable permissions of that container. For example, the files within a folder inherit the permissions of the folder. Only permissions marked to be inherited will be inherited.
+
+## User rights
+
+
+User rights grant specific privileges and sign-in rights to users and groups in your computing environment. Administrators can assign specific rights to group accounts or to individual user accounts. These rights authorize users to perform specific actions, such as signing in to a system interactively or backing up files and directories.
+
+User rights are different from permissions because user rights apply to user accounts, and permissions are associated with objects. Although user rights can apply to individual user accounts, user rights are best administered on a group account basis. There is no support in the access control user interface to grant user rights. However, user rights assignment can be administered through **Local Security Settings**.
+
+For more information about user rights, see [User Rights Assignment](user-rights-assignment.md).
+
+## Object auditing
+
+
+With administrator's rights, you can audit users' successful or failed access to objects. You can select which object access to audit by using the access control user interface, but first you must enable the audit policy by selecting **Audit object access** under **Local Policies** in **Local Security Settings**. You can then view these security-related events in the Security log in Event Viewer.
+
+For more information about auditing, see [Security Auditing Overview](security-auditing-overview.md).
+
+## See also
+
+-   For more information about access control and authorization, see [Access Control and Authorization Overview](https://technet.microsoft.com/en-us/library/jj134043(v=ws.11).aspx).
+
+
+ 
+
+ 
+
+
+
+

windows/keep-secure/active-directory-accounts.md

@@ -0,0 +1,859 @@
+---
+title: Active Directory Accounts (Windows 10)
+description: Active Directory Accounts
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+---
+
+# Active Directory Accounts
+
+**Applies to**
+-   Windows Server 2016
+
+Windows Server operating systems are installed with default local accounts. In addition, you can create user accounts to meet the requirements of your organization. This reference topic for the IT professional describes the Windows Server default local accounts that are stored locally on the domain controller and are used in Active Directory.
+
+This reference topic does not describe default local user accounts for a member or standalone server or for a Windows client. For more information, see [Local Accounts](local-accounts.md).
+
+## About this topic
+
+
+This topic describes the following:
+
+-   [Default local accounts in Active Directory](#sec-ad-default-accounts)
+
+    -   [Administrator account](#sec-administrator)
+
+    -   [Guest account](#sec-guest)
+
+    -   [HelpAssistant account (installed with a Remote Assistance session)](#sec-helpassistant)
+
+    -   [KRBTGT account](#sec-krbtgt)
+
+-   [Settings for default local accounts in Active Directory](#sec-account-settings)
+
+-   [Manage default local accounts in Active Directory](#sec-manage-local-accounts)
+
+-   [Restrict and protect sensitive domain accounts](#sec-restrict-protect-accounts)
+
+    -   [Separate administrator accounts from user accounts](#task1-separate-admin-accounts)
+
+    -   [Create dedicated workstation hosts without Internet and email access](#task2-admin-workstations)
+
+    -   [Restrict administrator logon access to servers and workstations](#task3-restrict-admin-logon)
+
+    -   [Disable the account delegation right for administrator accounts](#task4-disable-account-delegation)
+
+-   [Secure and manage domain controllers](#sec-secure-manage-dcs)
+
+## <a href="" id="sec-ad-default-accounts"></a>Default local accounts in Active Directory
+
+
+Default local accounts are built-in accounts that are created automatically when a Windows Server domain controller is installed and the domain is created. These default local accounts have counterparts in Active Directory. These accounts also have domain-wide access and are completely separate from the default local user accounts for a member or standalone server.
+
+You can assign rights and permissions to default local accounts on a particular domain controller, and only on that domain controller. These accounts are local to the domain. After the default local accounts are installed, they are stored in the Users container in Active Directory Users and Computers. It is a best practice to keep the default local accounts in the User container and not attempt to move these accounts, for example, to a different organizational unit (OU).
+
+The default local accounts in the Users container include: Administrator, Guest, and KRBTGT. The HelpAssistant account is installed when a Remote Assistance session is established. The following sections describe the default local accounts and their use in Active Directory.
+
+Primarily, default local accounts do the following:
+
+-   Let the domain represent, identify, and authenticate the identity of the user that is assigned to the account by using unique credentials (user name and password). It is a best practice to assign each user to a single account to ensure maximum security. Multiple users are not allowed to share one account. A user account lets a user sign in to computers, networks, and domains with a unique identifier that can be authenticated by the computer, network, or domain.
+
+-   Authorize (grant or deny) access to resources. After a user’s credentials have been authenticated, the user is authorized to access the network and domain resources based on the user’s explicitly assigned rights on the resource.
+
+-   Audit the actions that are carried out on a user account.
+
+In Active Directory, default local accounts are used by administrators to manage domain and member servers directly and from dedicated administrative workstations. Active Directory accounts provide access to network resources. Active Directory User accounts and Computer accounts can represent a physical entity, such as a computer or person, or act as dedicated service accounts for some applications.
+
+Each default local account is automatically assigned to a security group that is preconfigured with the appropriate rights and permissions to perform specific tasks. Active Directory security groups collect user accounts, computer accounts, and other groups into manageable units. For more information, see [Active Directory Security Groups](active-directory-security-groups.md).
+
+On an Active Directory domain controller, each default local account is referred to as a security principal. A security principal is a directory object that is used to secure and manage Active Directory services that provide access to domain controller resources. A security principal includes objects such as user accounts, computer accounts, security groups, or the threads or processes that run in the security context of a user or computer account. For more information, see [Security Principals Technical Overview](security-principals.md).
+
+A security principal is represented by a unique security identifier (SID).The SIDs that are related to each of the default local accounts in Active Directory are described in the sections below.
+
+Some of the default local accounts are protected by a background process that periodically checks and applies a specific security descriptor. A security descriptor is a data structure that contains security information that is associated with a protected object. This process ensures that any successful unauthorized attempt to modify the security descriptor on one of the default local accounts or groups is overwritten with the protected settings.
+
+This security descriptor is present on the AdminSDHolder object. If you want to modify the permissions on one of the service administrator groups or on any of its member accounts, you must modify the security descriptor on the AdminSDHolder object to ensure that it is applied consistently. Be careful when making these modifications, because you are also changing the default settings that are applied to all of your protected accounts.
+
+## <a href="" id="sec-administrator"></a>Administrator account
+
+
+The Administrator account is a default account that is used in all versions of the Windows operating system on every computer and device. The Administrator account is used by the system administrator for tasks that require administrative credentials. This account cannot be deleted or locked out, but the account can be renamed or disabled.
+
+The Administrator account gives the user complete access (Full Control permissions) of the files, directories, services, and other resources that are on that local server. The Administrator account can be used to create local users, and assign user rights and access control permissions. Administrator can also be used to take control of local resources at any time simply by changing the user rights and permissions. Although files and directories can be protected from the Administrator account temporarily, the Administrator account can take control of these resources at any time by changing the access permissions.
+
+**Account group membership**
+
+The Administrator account has membership in the default security groups as described in the Administrator account attributes table later in this topic.
+
+The security groups ensure that you can control administrator rights without having to change each Administrator account. In most instances, you do not have to change the basic settings for this account. However, you might have to change its advanced settings, such as membership in particular groups.
+
+**Security considerations**
+
+After installation of the server operating system, your first task is to set up the Administrator account properties securely. This includes setting up an especially long, strong password, and securing the Remote control and Remote Desktop Services profile settings.
+
+The Administrator account can also be disabled when it is not required. Renaming or disabling the Administrator account makes it more difficult for malicious users to try to gain access to the account. However, even when the Administrator account is disabled, it can still be used to gain access to a domain controller by using safe mode.
+
+On a domain controller, the Administrator account becomes the Domain Admin account. The Domain Admin account is used to sign in to the domain controller and this account requires a strong password. The Domain Admin account gives you access to domain resources.
+
+**Note**  
+When the domain controller is initially installed, you can sign in and use Server Manager to set up a local Administrator account, with the rights and permissions you want to assign. For example, you can use a local Administrator account to manage the operating system when you first install it. By using this approach, you can set up the operating system without getting locked out. Generally, you do not need to use the account after installation. You can only create local user accounts on the domain controller, before Active Directory Domain Services is installed, and not afterwards.
+
+ 
+
+When Active Directory is installed on the first domain controller in the domain, the Administrator account is created for Active Directory. The Administrator account is the most powerful account in the domain. It is given domain-wide access and administrative rights to administer the computer and the domain, and it has the most extensive rights and permissions over the domain. The person who installs Active Directory Domain Services on the computer creates the password for this account during the installation.
+
+**Administrator account attributes**
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-&lt;domain&gt;-500</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>User</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Users, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>N/A</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>Administrators, Domain Admins, Enterprise Administrators, Domain Users. Note that the Primary Group ID of all user accounts is Domain Users.</p>
+<p>Group Policy Creator Owners, and Schema Admins in Active Directory</p>
+<p>Domain Users group</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-service administrators?</p></td>
+<td><p>No</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="sec-guest"></a>Guest account
+
+
+The Guest account is a default local account has limited access to the computer and is disabled by default. The Guest account cannot be deleted or disabled, and the account name cannot be changed. By default, the Guest account password is left blank. A blank password allows the Guest account to be accessed without requiring the user to enter a password.
+
+The Guest account enables occasional or one-time users, who do not have an individual account on the computer, to sign in to the local server or domain with restricted rights and permissions. The Guest account can be enabled, and the password can be set up if needed, but only by a member of the Administrator group on the domain.
+
+**Account group membership**
+
+The Guest account has membership in the default security groups that are described in the following Guest account attributes table. By default, the Guest account is the only member of the default Guests group, which lets a user sign in to a server, and the Domain Guests global group, which lets a user sign in to a domain.
+
+A member of the Administrators group or Domain Admins group can set up a user with a Guest account on one or more computers.
+
+**Security considerations**
+
+Because the Guest account can provide anonymous access, it is a security risk. It also has a well-known SID. For this reason, it is a best practice to leave the Guest account disabled, unless its use is required and then only with restricted rights and permissions for a very limited period of time.
+
+When the Guest account is required, an Administrator on the domain controller is required to enable the Guest account. The Guest account can be enabled without requiring a password, or it can be enabled with a strong password. The Administrator also grants restricted rights and permissions for the Guest account. To help prevent unauthorized access:
+
+-   Do not grant the Guest account the [Shut down the system](shut-down-the-system.md) user right. When a computer is shutting down or starting up, it is possible that a Guest user or anyone with local access, such as a malicious user, could gain unauthorized access to the computer.
+
+-   Do not provide the Guest account with the ability to view the event logs. After the Guest account is enabled, it is a best practice to monitor this account frequently to ensure that other users cannot use services and other resources, such as resources that were unintentionally left available by a previous user.
+
+-   Do not use the Guest account when the server has external network access or access to other computers.
+
+If you decide to enable the Guest account, be sure to restrict its use and to change the password regularly. As with the Administrator account, you might want to rename the account as an added security precaution.
+
+In addition, an administrator is responsible for managing the Guest account. The administrator monitors the Guest account, disables the Guest account when it is no longer in use, and changes or removes the password as needed.
+
+For details about the Guest account attributes, see the following table.
+
+**Guest account attributes**
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-&lt;domain&gt;-501</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>User</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Users, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>Guests, Domain Guests</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Can be moved out, but we do not recommend it.</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>No</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="sec-helpassistant"></a>HelpAssistant account (installed with a Remote Assistance session)
+
+
+The HelpAssistant account is a default local account that is enabled when a Remote Assistance session is run. This account is automatically disabled when no Remote Assistance requests are pending.
+
+HelpAssistant is the primary account that is used to establish a Remote Assistance session. The Remote Assistance session is used to connect to another computer running the Windows operating system, and it is initiated by invitation. For solicited remote assistance, a user sends an invitation from their computer, through e-mail or as a file, to a person who can provide assistance. After the user’s invitation for a Remote Assistance session is accepted, the default HelpAssistant account is automatically created to give the person who provides assistance limited access to the computer. The HelpAssistant account is managed by the Remote Desktop Help Session Manager service.
+
+**Security considerations**
+
+The SIDs that pertain to the default HelpAssistant account include:
+
+-   SID: S-1-5-&lt;domain&gt;-13, display name Terminal Server User. This group includes all users who sign in to a server with Remote Desktop Services enabled. Note that, in Windows Server 2008, Remote Desktop Services are called Terminal Services.
+
+-   SID: S-1-5-&lt;domain&gt;-14, display name Remote Interactive Logon. This group includes all users who connect to the computer by using a remote desktop connection. This group is a subset of the Interactive group. Access tokens that contain the Remote Interactive Logon SID also contain the Interactive SID.
+
+For the Windows Server operating system, Remote Assistance is an optional component that is not installed by default. You must install Remote Assistance before it can be used.
+
+For details about the HelpAssistant account attributes, see the following table.
+
+**HelpAssistant account attributes**
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-&lt;domain&gt;-13 (Terminal Server User), S-1-5-&lt;domain&gt;-14 (Remote Interactive Logon)</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>User</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Users, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>Domain Guests</p>
+<p>Guests</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Can be moved out, but we do not recommend it.</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>No</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="sec-krbtgt"></a>KRBTGT account
+
+
+The KRBTGT account is a local default account that acts as a service account for the Key Distribution Center (KDC) service. This account cannot be deleted, and the account name cannot be changed. The KRBTGT account cannot be enabled in Active Directory.
+
+KRBTGT is also the security principal name used by the KDC for a Windows Server domain, as specified by RFC 4120. The KRBTGT account is the entity for the KRBTGT security principal, and it is created automatically when a new domain is created.
+
+Windows Server Kerberos authentication is achieved by the use of a special Kerberos ticket-granting ticket (TGT) enciphered with a symmetric key. This key is derived from the password of the server or service to which access is requested. The TGT password of the KRBTGT account is known only by the Kerberos service. In order to request a session ticket, the TGT must be presented to the KDC. The TGT is issued to the Kerberos client from the KDC.
+
+### KRBTGT account maintenance considerations
+
+A strong password is assigned to the KRBTGT account automatically. Be sure that you change the password on a regular schedule. The password for the KDC account is used to derive a secret key for encrypting and decrypting the TGT requests that are issued. The password for a domain trust account is used to derive an inter-realm key for encrypting referral tickets.
+
+On occasion, the KRBTGT account password requires a reset, for example, when an attempt to change the password on the KRBTGT account fails. In order to resolve this issue, you reset the KRBTGT user account password twice by using Active Directory Users and Computers. You must reset the password twice because the KRBTGT account stores only two of the most recent passwords in the password history. By resetting the password twice, you effectively clear all passwords from the password history.
+
+Resetting the password requires you either to be a member of the Domain Admins group, or to have been delegated with the appropriate authority. In addition, you must be a member of the local Administrators group, or you must have been delegated the appropriate authority.
+
+After you reset the KRBTGT password, ensure that event ID 6 in the (Kerberos) Key-Distribution-Center event source is written to the System event log.
+
+### Security considerations
+
+It is also a best practice to reset the KRBTGT account password to ensure that a newly restored domain controller does not replicate with a compromised domain controller. In this case, in a large forest recovery that is spread across multiple locations, you cannot guarantee that all domain controllers are shut down, and if they are shut down, they cannot be rebooted again before all of the appropriate recovery steps have been undertaken. After you reset the KRBTGT account, another domain controller cannot replicate this account password by using an old password.
+
+An organization suspecting domain compromise of the KRBTGT account should consider the use of professional incident response services. The impact to restore the ownership of the account is domain-wide and labor intensive an should be undertaken as part of a larger recovery effort.
+
+The KRBTGT password is the key from which all trust in Kerberos chains up to. Resetting the KRBTGT password is similar to renewing the root CA certificate with a new key and immediately not trusting the old key, resulting in almost all subsequent Kerberos operations will be affected.
+
+For all account types (users, computers, and services)
+
+-   All the TGTs that are already issued and distributed will be invalid because the DCs will reject them. These tickets are encrypted with the KRBTGT so any DC can validate them. When the password changes, the tickets become invalid.
+
+-   All currently authenticated sessions that logged on users have established (based on their service tickets) to a resource (such as a file share, SharePoint site, or Exchange server) are good until the service ticket is required to re-authenticate.
+
+-   NTLM authenticated connections are not affected
+
+Because it is impossible to predict the specific errors that will occur for any given user in a production operating environment, you must assume all computers and users will be affected.
+
+**Important**  
+Rebooting a computer is the only reliable way to recover functionality as this will cause both the computer account and user accounts to log back in again. Logging in again will request new TGTs that are valid with the new KRBTGT, correcting any KRBTGT related operational issues on that computer.
+
+<!-- For information how to resolve issues and potential issues from a compromised KRBTGT account, see "Reset the KRBTGT account password." -->
+
+### Read-only domain controllers and the KRBTGT account
+
+Windows Server 2008 introduced the read-only domain controller (RODC). The RODC is advertised as the Key Distribution Center (KDC) for the branch office. The RODC uses a different KRBTGT account and password than the KDC on a writable domain controller when it signs or encrypts ticket-granting ticket (TGT) requests. After an account is successfully authenticated, the RODC determines if a user's credentials or a computer's credentials can be replicated from the writable domain controller to the RODC by using the Password Replication Policy.
+
+After the credentials are cached on the RODC, the RODC can accept that user's sign-in requests until the credentials change. When a TGT is signed with the KRBTGT account of the RODC, the RODC recognizes that it has a cached copy of the credentials. If another domain controller signs the TGT, the RODC forwards requests to a writable domain controller.
+
+### KRBTGT account attributes
+
+For details about the KRBTGT account attributes, see the following table.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-&lt;domain&gt;-502</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>User</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Users, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>Domain Users group. Note that the Primary Group ID of all user accounts is Domain Users.</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Can be moved out, but we do not recommend it.</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>No</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="sec-account-settings"></a>Settings for default local accounts in Active Directory
+
+
+Each default local account in Active Directory has a number of account settings that you can use to configure password settings and security-specific information, as described in the following table.
+
+**Settings for default local accounts in Active Directory**
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Account settings</th>
+<th>Description</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>User must change password at next logon</p></td>
+<td><p>Forces a password change the next time that the user logs signs in to the network. Use this option when you want to ensure that the user is the only person to know his or her password.</p></td>
+</tr>
+<tr class="even">
+<td><p>User cannot change password</p></td>
+<td><p>Prevents the user from changing the password. Use this option when you want to maintain control over a user account, such as for a Guest or temporary account.</p></td>
+</tr>
+<tr class="odd">
+<td><p>Password never expires</p></td>
+<td><p>Prevents a user password from expiring. It is a best practice to enable this option with service accounts and to use strong passwords.</p></td>
+</tr>
+<tr class="even">
+<td><p>Store passwords using reversible encryption</p></td>
+<td><p>Provides support for applications that use protocols requiring knowledge of the plaintext form of the user’s password for authentication purposes.</p>
+<p>This option is required when using Challenge Handshake Authentication Protocol (CHAP) in Internet Authentication Services (IAS), and when using digest authentication in Internet Information Services (IIS).</p></td>
+</tr>
+<tr class="odd">
+<td><p>Account is disabled</p></td>
+<td><p>Prevents the user from signing in with the selected account. As an administrator, you can use disabled accounts as templates for common user accounts.</p></td>
+</tr>
+<tr class="even">
+<td><p>Smart card is required for interactive logon</p></td>
+<td><p>Requires that a user has a smart card to sign on to the network interactively. The user must also have a smart card reader attached to their computer and a valid personal identification number (PIN) for the smart card.</p>
+<p>When this attribute is applied on the account, the effect is as follows:</p>
+<ul>
+<li><p>The attribute only restricts initial authentication for interactive logon and Remote Desktop logon. When interactive or Remote Desktop logon requires a subsequent network logon, such as with a domain credential, an NT Hash provided by the domain controller is used to complete the smartcard authentication process</p></li>
+<li><p>Each time the attribute is enabled on an account, the account’s current password hash value is replaced with a 128-bit random number. This invalidates the use of any previously configured passwords for the account. The value does not change after that unless a new password is set or the attribute is disabled and re-enabled.</p></li>
+<li><p>Accounts with this attribute cannot be used to start services or run scheduled tasks.</p></li>
+</ul></td>
+</tr>
+<tr class="odd">
+<td><p>Account is trusted for delegation</p></td>
+<td><p>Lets a service running under this account perform operations on behalf of other user accounts on the network. A service running under a user account (also known as a service account) that is trusted for delegation can impersonate a client to gain access to resources, either on the computer where the service is running or on other computers. For example, in a forest that is set to the Windows Server 2003 functional level, this setting is found on the <strong>Delegation</strong> tab. It is available only for accounts that have been assigned service principal names (SPNs), which are set by using the <strong>setspn</strong> command from Windows Support Tools. This setting is security-sensitive and should be assigned cautiously.</p></td>
+</tr>
+<tr class="even">
+<td><p>Account is sensitive and cannot be delegated</p></td>
+<td><p>Gives control over a user account, such as for a Guest account or a temporary account. This option can be used if this account cannot be assigned for delegation by another account.</p></td>
+</tr>
+<tr class="odd">
+<td><p>Use DES encryption types for this account</p></td>
+<td><p>Provides support for the Data Encryption Standard (DES). DES supports multiple levels of encryption, including Microsoft Point-to-Point Encryption (MPPE) Standard (40-bit and 56-bit), MPPE standard (56-bit), MPPE Strong (128-bit), Internet Protocol security (IPSec) DES (40-bit), IPSec 56-bit DES, and IPSec Triple DES (3DES).</p>
+<div class="alert">
+<strong>Note</strong>  
+<p>DES is not enabled by default in Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows 7, Windows 8, and Windows 8.1. For these operating systems, you must configure your computers to use the DES-CBC-MD5 or DES-CBC-CRC cipher suites. If your environment requires DES, then this setting might affect compatibility with client computers or services and applications in your environment. For more information, see [Hunting down DES in order to securely deploy Kerberos](http://blogs.technet.com/b/askds/archive/2010/10/19/hunting-down-des-in-order-to-securely-deploy-kerberos.aspx).</p>
+</div>
+<div>
+ 
+</div></td>
+</tr>
+<tr class="even">
+<td><p>Do not require Kerberos preauthentication</p></td>
+<td><p>Provides support for alternate implementations of the Kerberos protocol. Because preauthentication provides additional security, use caution when enabling this option. Note that domain controllers running Windows 2000 or Windows Server 2003 can use other mechanisms to synchronize time.</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="sec-manage-local-accounts"></a>Manage default local accounts in Active Directory
+
+
+After the default local accounts are installed, these accounts reside in the Users container in Active Directory Users and Computers. Default local accounts can be created, disabled, reset, and deleted by using the Active Directory Users and Computers Microsoft Management Console (MMC) and by using command-line tools.
+
+You can use Active Directory Users and Computers to assign rights and permissions on a given local domain controller, and that domain controller only, to limit the ability of local users and groups to perform certain actions. A right authorizes a user to perform certain actions on a computer, such as backing up files and folders or shutting down a computer. In contrast, an access permission is a rule that is associated with an object, usually a file, folder, or printer, that regulates which users can have access to the object and in what manner.
+
+For more information about creating and managing local user accounts in Active Directory, see [Manage Local Users](http://technet.microsoft.com/library/cc731899.aspx).
+
+You can also use Active Directory Users and Computers on a domain controller to target remote computers that are not domain controllers on the network.
+
+You can obtain recommendations from Microsoft for domain controller configurations that you can distribute by using the Security Compliance Manager (SCM) tool. For more information, see [Microsoft Security Compliance Manager](http://technet.microsoft.com/library/cc677002.aspx).
+
+Some of the default local user accounts are protected by a background process that periodically checks and applies a specific security descriptor, which is a data structure that contains security information that is associated with a protected object. This security descriptor is present on the AdminSDHolder object.
+
+This means, when you want to modify the permissions on a service administrator group or on any of its member accounts, you are also required to modify the security descriptor on the AdminSDHolder object. This approach ensures that the permissions are applied consistently. Be careful when you make these modifications, because this action can also affect the default settings that are applied to all of your protected administrative accounts.
+
+## <a href="" id="sec-restrict-protect-accounts"></a>Restrict and protect sensitive domain accounts
+
+
+Restricting and protecting domain accounts in your domain environment requires you to adopt and implement the following best practices approach:
+
+-   Strictly limit membership to the Administrators, Domain Admins, and Enterprise Admins groups.
+
+-   Stringently control where and how domain accounts are used.
+
+Member accounts in the Administrators, Domain Admins, and Enterprise Admins groups in a domain or forest are high-value targets for malicious users. It is a best practice to strictly limit membership to these administrator groups to the smallest number of accounts in order to limit any exposure. Restricting membership in these groups reduces the possibility that an administrator might unintentionally misuse these credentials and create a vulnerability that malicious users can exploit.
+
+Moreover, it is a best practice to stringently control where and how sensitive domain accounts are used. Restrict the use of Domain Admins accounts and other administrator accounts to prevent them from being used to sign in to management systems and workstations that are secured at the same level as the managed systems. When administrator accounts are not restricted in this manner, each workstation from which a domain administrator signs in provides another location that malicious users can exploit.
+
+Implementing these best practices is separated into the following tasks:
+
+-   [Separate administrator accounts from user accounts](#task1-separate-admin-accounts)
+
+-   [Create dedicated workstation hosts for administrators](#task2-admin-workstations)
+
+-   [Restrict administrator logon access to servers and workstations](#task3-restrict-admin-logon)
+
+-   [Disable the account delegation right for administrator accounts](#task4-disable-account-delegation)
+
+Note that, to provide for instances where integration challenges with the domain environment are expected, each task is described according to the requirements for a minimum, better, and ideal implementation. As with all significant changes to a production environment, ensure that you test these changes thoroughly before you implement and deploy them. Then stage the deployment in a manner that allows for a rollback of the change in case technical issues occur.
+
+### <a href="" id="task1-separate-admin-accounts"></a>Separate administrator accounts from user accounts
+
+Restrict Domain Admins accounts and other sensitive accounts to prevent them from being used to sign in to lower trust servers and workstations. Restrict and protect administrator accounts by segregating administrator accounts from standard user accounts, by separating administrative duties from other tasks, and by limiting the use of these accounts. Create dedicated accounts for administrative personnel who require administrator credentials to perform specific administrative tasks, and then create separate accounts for other standard user tasks, according to the following guidelines:
+
+-   **Privileged account**. Allocate administrator accounts to perform the following administrative duties only:
+
+    -   **Minimum**. Create separate accounts for domain administrators, enterprise administrators, or the equivalent with appropriate administrator rights in the domain or forest. Use accounts that have been granted sensitive administrator rights only to administer domain data and domain controllers.
+
+    -   **Better**. Create separate accounts for administrators that have reduced administrative rights, such as accounts for workstation administrators, and accounts with user rights over designated Active Directory organizational units (OUs).
+
+    -   **Ideal**. Create multiple, separate accounts for an administrator who has a variety of job responsibilities that require different trust levels. Set up each administrator account with significantly different user rights, such as for workstation administration, server administration and domain administration, to let the administrator sign in to given workstations, servers and domain controllers based strictly on his or her job responsibilities.
+
+-   **Standard user account**. Grant standard user rights for standard user tasks, such as email, web browsing, and using line-of-business (LOB) applications. These accounts should not be granted administrator rights.
+
+**Important**  
+Ensure that sensitive administrator accounts cannot access email or browse the Internet as described in the following section.
+
+ 
+
+### <a href="" id="task2-admin-workstations"></a>Create dedicated workstation hosts without Internet and email access
+
+Administrators need to manage job responsibilities that require sensitive administrator rights from a dedicated workstation because they do not have easy physical access to the servers. A workstation that is connected to the Internet and has email and web browsing access is regularly exposed to compromise through phishing, downloading, and other types of Internet attacks. Because of these threats, it is a best practice to set these administrators up by using workstations that are dedicated to administrative duties only, and not provide access to the Internet, including email and web browsing. For more information, see [Separate administrator accounts from user accounts](#task1-separate-admin-accounts).
+
+**Note**  
+If the administrators in your environment can sign in locally to managed servers and perform all tasks without elevated rights or domain rights from their workstation, you can skip this task.
+
+ 
+
+-   **Minimum**. Build dedicated administrative workstations and block Internet access on those workstations including web browsing and email. Use the following ways to block Internet access:
+
+    -   Configure authenticating boundary proxy services, if they are deployed, to disallow administrator accounts from accessing the Internet.
+
+    -   Configure boundary firewall or proxy services to disallow Internet access for the IP addresses that are assigned to dedicated administrative workstations.
+
+    -   Block outbound access to the boundary proxy servers in the Windows Firewall.
+
+    The instructions for meeting this minimum requirement are described in the following procedure.
+
+-   **Better**. Do not grant administrators membership in the local Administrator group on the computer in order to restrict the administrator from bypassing these protections.
+
+-   **Ideal**. Restrict workstations from having any network connectivity, except for the domain controllers and servers that the administrator accounts are used to manage. Alternately, use AppLocker application control policies to restrict all applications from running, except for the operating system and approved administrative tools and applications. For more information about AppLocker, see [AppLocker Overview](http://technet.microsoft.com/library/hh831440.aspx).
+
+The following procedure describes how to block Internet access by creating a Group Policy Object (GPO) that configures an invalid proxy address on administrative workstations. These instructions apply only to computers running Internet Explorer and other Windows components that use these proxy settings.
+
+**Note**  
+In this procedure, the workstations are dedicated to domain administrators. By simply modifying the administrator accounts to grant permission to administrators to sign in locally, you can create additional OUs to manage administrators that have fewer administrative rights to use the instructions described in the following procedure.
+
+**To install administrative workstations in a domain and block Internet and email access (minimum)**
+
+1.  As a domain administrator on a domain controller, open Active Directory Users and Computers, and create a new OU for administrative workstations.
+
+2.  Create computer accounts for the new workstations.
+
+    > **Note**&nbsp;&nbsp;You might have to delegate permissions to join the domain by using [KB 932455](http://support.microsoft.com/kb/932455) if the account that joins the workstations to the domain does not already have permissions to join computers to the domain.
+
+    ![Active Directory local accounts](images/adlocalaccounts-proc1-sample1.gif)
+
+3.  Close Active Directory Users and Computers.
+
+4.  Start the **Group Policy Management** Console (GPMC).
+
+5.  Right-click the new OU, and &gt; **Create a GPO in this domain, and Link it here**.
+
+    ![Active Directory local accounts](images/adlocalaccounts-proc1-sample2.png)
+
+6.  Name the GPO, and &gt; **OK**.
+
+7.  Expand the GPO, right-click the new GPO, and &gt; **Edit**.
+
+    ![Active Directory local accounts](images/adlocalaccounts-proc1-sample3.png)
+
+8.  Configure which members of accounts can log on locally to these administrative workstations as follows:
+
+    1.  Navigate to Computer Configuration\\Policies\\Windows Settings\\Local Policies, and then click **User Rights Assignment**.
+
+    2.  Double-click **Allow log on locally**, and then select the **Define these policy settings** check box.
+
+    3.  Click **Add User or Group** &gt; **Browse**, type **Enterprise Admins**, and &gt; **OK**.
+
+    4.  Click **Add User or Group** &gt; **Browse**, type **Domain Admins**, and &gt; **OK**.
+
+        **Important**  
+        These instructions assume that the workstation is to be dedicated to domain administrators.
+
+         
+
+    5.  Click **Add User or Group**, type **Administrators**, and &gt; **OK**.
+
+        ![Active Directory local accounts](images/adlocalaccounts-proc1-sample4.png)
+
+9.  Configure the proxy configuration:
+
+    1.  Navigate to User Configuration\\Policies\\Windows Settings\\Internet Explorer, and &gt; **Connection**.
+
+    2.  Double-click **Proxy Settings**, select the **Enable proxy settings** check box, type **127.0.0.1** (the network Loopback IP address) as the proxy address, and &gt; **OK**.
+
+        ![Active Directory local accounts](images/adlocalaccounts-proc1-sample5.png)
+
+10. Configure the loopback processing mode to enable the user Group Policy proxy setting to apply to all users on the computer as follows:
+
+    1.  Navigate to Computer Configuration\\Policies\\Administrative Templates\\System, and &gt; **Group Policy**.
+
+    2.  Double-click **User Group Policy loopback policy processing mode**, and &gt; **Enabled**.
+
+    3.  Select **Merge Mode**, and &gt; **OK**.
+
+11. Configure software updates as follows:
+
+    1.  Navigate to Computer Configuration\\Policies\\Administrative Templates\\Windows Components, and then click **Windows Update**.
+
+    2.  Configure Windows Update settings as described in the following table.
+
+        <table>
+        <colgroup>
+        <col width="50%" />
+        <col width="50%" />
+        </colgroup>
+        <tbody>
+        <tr class="odd">
+        <td><p><strong>Windows Update Setting</strong></p></td>
+        <td><p><strong>Configuration</strong></p></td>
+        </tr>
+        <tr class="even">
+        <td><p>Allow Automatic Updates immediate installation</p></td>
+        <td><p>Enabled</p></td>
+        </tr>
+        <tr class="odd">
+        <td><p>Configure Automatic Updates</p></td>
+        <td><p>Enabled<br>4 - Auto download and schedule the installation<br>0 - Every day 03:00</p></td>
+        </tr>
+        <tr class="even">
+        <td><p>Enable Windows Update Power Management to automatically wake up the system to install scheduled updates</p></td>
+        <td><p>Enabled</p></td>
+        </tr>
+        <tr class="odd">
+        <td><p>Specify intranet Microsoft Update service location</p></td>
+        <td><p>Enabled http://&lt;WSUSServername&gt; http://&lt;WSUSServername&gt; Where &lt;WSUSServername&gt; is the DNS name or IP address of the Windows Server Update Services (WSUS) in the environment.</p></td>
+        </tr>
+        <tr class="even">
+        <td><p>Automatic Updates detection frequency</p></td>
+        <td><p>6 hours</p></td>
+        </tr>
+        <tr class="odd">
+        <td><p>Re-prompt for restart with scheduled installations</p></td>
+        <td><p>1 minute</p></td>
+        </tr>
+        <tr class="even">
+        <td><p>Delay restart for scheduled installations</p></td>
+        <td><p>5 minutes</p></td>
+        </tr>
+        </tbody>
+        </table>
+
+        > **Note**&nbsp;&nbsp;This step assumes that Windows Server Update Services (WSUS) is installed and configured in the environment. You can skip this step if you use another tool to deploy software updates. Also, if the public Microsoft Windows Update service only is used on the Internet, then these administrative workstations no longer receive updates.
+
+12. Configure the inbound firewall to block all connections as follows:
+
+    1.  Right-click **Windows Firewall with Advanced Security LDAP://path**, and &gt; **Properties**.
+
+        ![Active Directory local accounts](images/adlocalaccounts-proc1-sample6.png)
+
+    2.  On each profile, ensure that the firewall is enabled and that inbound connections are set to **Block all connections**.
+
+        ![Active Directory local accounts](images/adlocalaccounts-proc1-sample7.png)
+
+    3.  Click **OK** to complete the configuration.
+
+13. Close the Group Policy Management Console.
+
+14. Install the Windows operating system on the workstations, give each workstation the same names as the computer accounts assigned to them, and then join them to the domain.
+
+### <a href="" id="task3-restrict-admin-logon"></a>Restrict administrator logon access to servers and workstations
+
+It is a best practice to restrict administrators from using sensitive administrator accounts to sign in to lower-trust servers and workstations. This restriction prevents administrators from inadvertently increasing the risk of credential theft by signing in to a lower-trust computer.
+
+**Important**  
+Ensure that you either have local access to the domain controller or that you have built at least one dedicated administrative workstation.
+
+ 
+
+Restrict logon access to lower-trust servers and workstations by using the following guidelines:
+
+-   **Minimum**. Restrict domain administrators from having logon access to servers and workstations. Before starting this procedure, identify all OUs in the domain that contain workstations and servers. Any computers in OUs that are not identified will not restrict administrators with sensitive accounts from signing-in to them.
+
+-   **Better**. Restrict domain administrators from non-domain controller servers and workstations.
+
+-   **Ideal**. Restrict server administrators from signing in to workstations, in addition to domain administrators.
+
+**Note**  
+For this procedure, do not link accounts to the OU that contain workstations for administrators that perform administration duties only, and do not provide Internet or email access. For more information, see [Create dedicated workstation hosts for administrators](#task2-admin-workstations)
+
+ 
+
+**To restrict domain administrators from workstations (minimum)**
+
+1.  As a domain administrator, open the Group Policy Management Console (GPMC).
+
+2.  Open **Group Policy Management**, and expand *&lt;forest&gt;*\\Domains\\*&lt;domain&gt;*, and then expand to **Group Policy Objects**.
+
+3.  Right-click **Group Policy Objects**, and &gt; **New**.
+
+    ![Active Directory local accounts](images/adlocalaccounts-proc2-sample1.png)
+
+4.  In the **New GPO** dialog box, name the GPO that restricts administrators from signing in to workstations, and &gt; **OK**.
+
+    ![Active Directory local accounts](images/adlocalaccounts-proc2-sample2.png)
+
+5.  Right-click **New GPO**, and &gt; **Edit**.
+
+6.  Configure user rights to deny logon locally for domain administrators.
+
+7.  Navigate to Computer Configuration\\Policies\\Windows Settings\\Local Policies, and then click **User Rights Assignment**, and perform the following:
+
+    1.  Double-click **Deny logon locally**, and &gt; **Define these policy settings**.
+
+    2.  Click **Add User or Group**, click **Browse**, type **Enterprise Admins**, and &gt; **OK**.
+
+    3.  Click **Add User or Group**, click **Browse**, type **Domain Admins**, and &gt; **OK**.
+
+        ![Active Directory local accounts](images/adlocalaccounts-proc2-sample3.png)
+
+        **Note**  
+        You can optionally add any groups that contain server administrators who you want to restrict from signing in to workstations.
+
+         
+
+    4.  Click **OK** to complete the configuration.
+
+8.  Configure the user rights to deny batch and service logon rights for domain administrators as follows:
+
+    **Note**  
+    Completing this step might cause issues with administrator tasks that run as scheduled tasks or services with accounts in the Domain Admins group. The practice of using domain administrator accounts to run services and tasks on workstations creates a significant risk of credential theft attacks and therefore should be replaced with alternative means to run scheduled tasks or services.
+
+     
+
+    1.  Double-click **Deny logon as a batch job**, and &gt; **Define these policy settings**.
+
+    2.  Click **Add User or Group** &gt; **Browse**, type **Enterprise Admins**, and &gt; **OK**.
+
+    3.  Click **Add User or Group** &gt; **Browse**, type **Domain Admins**, and &gt; **OK**.
+
+        ![Active Directory local accounts](images/adlocalaccounts-proc2-sample4.png)
+
+        **Note**  
+        You can optionally add any groups that contain server administrators who you want to restrict from signing in to workstations.
+
+         
+
+    4.  Double-click **Deny logon as a service**, and &gt; **Define these policy settings**.
+
+    5.  Click **Add User or Group** &gt; **Browse**, type **Enterprise Admins**, and &gt; **OK**.
+
+    6.  Click **Add User or Group** &gt; **Browse**, type **Domain Admins**, and &gt; **OK**.
+
+        ![Active Directory local accounts](images/adlocalaccounts-proc2-sample5.png)
+
+        **Note**  
+        You can optionally add any groups that contain server administrators who you want to restrict from signing in to workstations.
+
+         
+
+9.  Link the GPO to the first Workstations OU.
+
+    Navigate to the *&lt;forest&gt;*\\Domains\\*&lt;domain&gt;*\\OU Path, and then:
+
+    1.  Right-click the workstation OU, and then &gt; **Link an Existing GPO**.
+
+        ![Active Directory local accounts](images/adlocalaccounts-proc2-sample6.png)
+
+    2.  Select the GPO that you just created, and &gt; **OK**.
+
+        ![Active Directory local accounts](images/adlocalaccounts-proc2-sample7.png)
+
+10. Test the functionality of enterprise applications on workstations in the first OU and resolve any issues caused by the new policy.
+
+11. Link all other OUs that contain workstations.
+
+    However, do not create a link to the Administrative Workstation OU if it is created for administrative workstations that are dedicated to administration duties only, and that are without Internet or email access. For more information, see [Create dedicated workstation hosts for administrators](#task2-admin-workstations).
+
+    **Important**  
+    If you later extend this solution, do not deny logon rights for the **Domain Users** group. The **Domain Users** group includes all user accounts in the domain, including Users, Domain Administrators, and Enterprise Administrators.
+
+     
+
+### <a href="" id="task4-disable-account-delegation"></a>Disable the account delegation right for sensitive administrator accounts
+
+Although user accounts are not marked for delegation by default, accounts in an Active Directory domain can be trusted for delegation. This means that a service or a computer that is trusted for delegation can impersonate an account that authenticates to them to access other resources across the network.
+
+For sensitive accounts, such as those belonging to members of the Administrators, Domain Admins, or Enterprise Admins groups in Active Directory, delegation can present a substantial risk of rights escalation. For example, if an account in the Domain Admins group is used to sign in to a compromised member server that is trusted for delegation, that server can request access to resources in the context of the Domain Admins account, and escalate the compromise of that member server to a domain compromise.
+
+It is a best practice to configure the user objects for all sensitive accounts in Active Directory by selecting the **Account is sensitive and cannot be delegated** check box under **Account options** to prevent these accounts from being delegated. For more information, see [Setting for default local accounts in Active Directory](#sec-account-settings).
+
+As with any configuration change, test this enabled setting fully to ensure that it performs correctly before you implement it.
+
+![Active Directory local accounts](images/adlocalaccounts-proc3-sample1.png)
+
+## <a href="" id="sec-secure-manage-dcs"></a>Secure and manage domain controllers
+
+
+It is a best practice to strictly enforce restrictions on the domain controllers in your environment. This ensures that the domain controllers:
+
+1.  Run only required software
+
+2.  Required software is regularly updated
+
+3.  Are configured with the appropriate security settings
+
+One aspect of securing and managing domain controllers is to ensure that the default local user accounts are fully protected. It is of primary importance to restrict and secure all sensitive domain accounts, as described in the preceding sections.
+
+Because domain controllers store credential password hashes of all accounts in the domain, they are high-value targets for malicious users. When domain controllers are not well managed and secured by using restrictions that are strictly enforced, they can be compromised by malicious users. For example, a malicious user could steal sensitive domain administrator credentials from one domain controller, and then use these credentials to attack the domain and forest.
+
+In addition, installed applications and management agents on domain controllers might provide a path for escalating rights that malicious users can use to compromise the management service or administrators of that service. The management tools and services, which your organization uses to manage domain controllers and their administrators, are equally important to the security of the domain controllers and the domain administrator accounts. Ensure that these services and administrators are fully secured with equal effort.
+
+## See also
+
+
+[Security Principals Technical Overview](security-principals.md)
+
+
+ 
+
+ 
+
+
+
+

windows/keep-secure/create-edp-policy-using-intune.md

@@ -47,7 +47,6 @@ The steps to add your apps are based on the type of app it is; either a Universa
 
 >**Important**<br>EDP-aware apps are expected to prevent enterprise data from going to unprotected network locations and to avoid encrypting personal data. On the other hand, EDP-unaware apps might not respect the corporate network boundary and will encrypt all files they create or modify, meaning that they could encrypt personal data and cause data loss during the revocation process. Care must be taken to get a support statement from the software provider that their app is safe with EDP before adding it to your **Protected App** list.<p>
 
-
 >**Note**<br>If you want to use **File hash** or **Path** rules, instead of Publisher rules, you must follow the steps in the [Add multiple apps to your enterprise data protection (EDP) Protected Apps list](add-apps-to-protected-list-using-custom-uri.md) topic.
 
 **To add a UWP app**
@@ -75,13 +74,15 @@ The steps to add your apps are based on the type of app it is; either a Universa
         }
         ```
     4.  Copy the `publisherCertificateName` value into the **Publisher Name** box and copy the `packageIdentityName` value into the **Product Name** box of Intune.
-     <p>**Important**<br>The JSON file might also return a `windowsPhoneLegacyId` value for both the **Publisher Name** and **Product Name** boxes. This means that you have an app that’s using a XAP package and that you must set the **Product Name** as `windowsPhoneLegacyId`, and set the **Publisher Name** as “CN=” followed by the `windowsPhoneLegacyId`.
+    
+    >**Important**<br>The JSON file might also return a `windowsPhoneLegacyId` value for both the **Publisher Name** and **Product Name** boxes. This means that you have an app that’s using a XAP package and that you must set the **Product Name** as `windowsPhoneLegacyId`, and set the **Publisher Name** as “CN=” followed by the `windowsPhoneLegacyId`.
     <p>For example:<br>
      ``` json
         {
           "windowsPhoneLegacyId": "ca05b3ab-f157-450c-8c49-a1f127f5e71d",
         }
        ```
+       
     ![Microsoft Intune: Add a UWP app to the Protected Apps list](images/intune-addapps.png)
 
     **To find the Publisher and Product name values for apps installed on Windows 10 Mobile phones**
@@ -251,7 +252,8 @@ If you have multiple domains, you must separate them with the "|" character. For
     ![Microsoft Intune: Add the primary internet domain for your enterprise identity](images/intune-primary-domain.png)
 
 ## Choose where apps can access enterprise data
-After you've added a protection level to your apps, you'll need to decide where those apps can access enterprise data on your network. There are 6 options, including your network domain, cloud domain, proxy server, internal proxy server, IPv4 range, and IPv6 range.
+After you've added a protection mode to your apps, you'll need to decide where those apps can access enterprise data on your network.<p>
+There are no default locations included with EDP, you must add each of your network locations. This area applies to any network endpoint device that gets an IP address in your enterprise’s range and is also bound to one of your enterprise domains, including SMB shares.  Local file system locations should just maintain encryption (for example, on local NTFS, FAT, ExFAT). 
 
 >**Important**<br>
 -   Every EDP policy should include policy that defines your enterprise network locations.<p>
@@ -325,7 +327,7 @@ If you already have an EFS DRA certificate for your organization, you can skip c
 
     The EFSDRA.cer and EFSDRA.pfx files are created in the location you specified in Step 1.
 
-    **Important**<br> 
+    >**Important**<br> 
     Because these files can be used to decrypt any EDP file, you must protect them accordingly. We highly recommend storing them as a public key (PKI) on a smart card with strong protection, stored in a secured physical location.
 
 4. Add your EFS DRA certificate to your EDP policy by using Step 3 of the [Choose where apps can access enterprise data](#choose-where-apps-can-access-enterprise-data) section of this topic. 

windows/keep-secure/device-guard-deployment-guide.md

@@ -752,7 +752,7 @@ To modify the policy rule options of an existing code integrity policy, use the
 
 You can set several rule options within a code integrity policy. Table 2 lists each rule and its high-level meaning.
 
-Table 2. Code integrity policy - policy rule options
+#### Table 2. Code integrity policy - policy rule options
 
 | Rule option | Description |
 |------------ | ----------- |
@@ -769,15 +769,15 @@ Table 2. Code integrity policy - policy rule options
 | **10 Enabled:Boot Audit on Failure** | Used when the code integrity policy is in enforcement mode. When a driver fails during startup, the code integrity policy will be placed in audit mode so that Windows will load. Administrators can validate the reason for the failure in the CodeIntegrity event log. |
 File rule levels allow administrators to specify the level at which they want to trust their applications. This level of trust could be as low as the hash of each binary and as high as a PCA certificate. File rule levels are specified both when you create a new code integrity policy from a scan and when you create a policy from audit events. In addition, to combine rule levels found in multiple policies, you can merge the policies. When merged, code integrity policies combine their file rules. Each file rule level has its benefit and disadvantage. Use Table 3 to select the appropriate protection level for your available administrative resources and Device Guard deployment scenario.
 
-Table 3. Code integrity policy - file rule levels
+#### Table 3. Code integrity policy - file rule levels
 
 | Rule level | Description |
 |----------- | ----------- |
 | **Hash** | Specifies individual hash values for each discovered binary. Although this level is specific, it can cause additional administrative overhead to maintain the current product versions’ hash values. Each time a binary is updated, the hash value changes, therefore requiring a policy update. |
 | **FileName** | Specifies individual binary file names. Although the hash values for an application are modified when updated, the file names are typically not. This offers less specific security than the hash level but does not typically require a policy update when any binary is modified. |
-| **SignedVersion** | This combines the publisher rule with a file version number. This option allows anything from the specified publisher, with a file version at or above the specified version number, to run. |
+| **SignedVersion** | This combines the publisher rule with a version number. This option allows anything from the specified publisher, with a version at or above the specified version number, to run. |
 | **Publisher** | This is a combination of the PCA certificate and the common name (CN) on the leaf certificate. In the scenario that a PCA certificate is used to sign multiple companies’ applications (such as VeriSign), this rule level allows organizations to trust the PCA certificate but only for the company whose name is on the leaf certificate (for example, Intel for device drivers). This level trusts a certificate with a long validity period but only when combined with a trusted leaf certificate. |
-| **FilePublisher** | This is a combination of the publisher file rule level and the SignedVersion rule level. Any signed file from the trusted publisher that is the specified version or newer is trusted. |
+| **FilePublisher** | This is a combination of “FileName” plus “Publisher” (PCA certificate with CN of leaf) plus a minimum version number. This option trusts specific files from the specified publisher, with a version at or above the specified version number. |
 | **LeafCertificate** | Adds trusted signers at the individual signing certificate level. The benefit of using this level versus the individual hash level is that new versions of the product will have different hash values but typically the same signing certificate. Using this level, no policy update would be needed to run the new version of the application. However, leaf certificates have much shorter validity periods than PCA certificates, so additional administrative overhead is associated with updating the code integrity policy when these certificates expire. |
 | **PcaCertificate** | Adds the highest certificate in the provided certificate chain to signers. This is typically one certificate below the root certificate, because the scan does not validate anything above the presented signature by going online or checking local root stores. |
 | **RootCertificate** | Currently unsupported. |

windows/keep-secure/dynamic-access-control.md

@@ -0,0 +1,147 @@
+---
+title: Dynamic Access Control Overview (Windows 10)
+description: Dynamic Access Control Overview
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+---
+
+# Dynamic Access Control Overview
+
+**Applies to**
+-   Windows Server 2016
+
+This overview topic for the IT professional describes Dynamic Access Control and its associated elements, which were introduced in Windows Server 2012 and Windows 8.
+
+Domain-based Dynamic Access Control enables administrators to apply access-control permissions and restrictions based on well-defined rules that can include the sensitivity of the resources, the job or role of the user, and the configuration of the device that is used to access these resources.
+
+For example, a user might have different permissions when they access a resource from their office computer versus when they are using a portable computer over a virtual private network. Or access may be allowed only if a device meets the security requirements that are defined by the network administrators. When Dynamic Access Control is used, a user’s permissions change dynamically without additional administrator intervention if the user’s job or role changes (resulting in changes to the user’s account attributes in AD DS).
+
+Dynamic Access Control is not supported in Windows operating systems prior to Windows Server 2012 and Windows 8. When Dynamic Access Control is configured in environments with supported and non-supported versions of Windows, only the supported versions will implement the changes.
+
+Features and concepts associated with Dynamic Access Control include:
+
+-   [Central access rules](#bkmk-rules)
+
+-   [Central access policies](#bkmk-policies)
+
+-   [Claims](#bkmk-claims)
+
+-   [Expressions](#bkmk-expressions2)
+
+-   [Proposed permissions](#bkmk-permissions2)
+
+### <a href="" id="bkmk-rules"></a>Central access rules
+
+A central access rule is an expression of authorization rules that can include one or more conditions involving user groups, user claims, device claims, and resource properties. Multiple central access rules can be combined into a central access policy.
+
+If one or more central access rules have been defined for a domain, file share administrators can match specific rules to specific resources and business requirements.
+
+### <a href="" id="bkmk-policies"></a>Central access policies
+
+Central access policies are authorization policies that include conditional expressions. For example, let’s say an organization has a business requirement to restrict access to personally identifiable information (PII) in files to only the file owner and members of the human resources (HR) department who are allowed to view PII information. This represents an organization-wide policy that applies to PII files wherever they are located on file servers across the organization. To implement this policy, an organization needs to be able to:
+
+-   Identify and mark the files that contain the PII.
+
+-   Identify the group of HR members who are allowed to view the PII information.
+
+-   Add the central access policy to a central access rule, and apply the central access rule to all files that contain the PII, wherever they are located amongst the file servers across the organization.
+
+Central access policies act as security umbrellas that an organization applies across its servers. These policies are in addition to (but do not replace) the local access policies or discretionary access control lists (DACLs) that are applied to files and folders.
+
+### <a href="" id="bkmk-claims"></a>Claims
+
+A claim is a unique piece of information about a user, device, or resource that has been published by a domain controller. The user’s title, the department classification of a file, or the health state of a computer are valid examples of a claim. An entity can involve more than one claim, and any combination of claims can be used to authorize access to resources. The following types of claims are available in the supported versions of Windows:
+
+-   **User claims**   Active Directory attributes that are associated with a specific user.
+
+-   **Device claims**   Active Directory attributes that are associated with a specific computer object.
+
+-   **Resource attributes**  Global resource properties that are marked for use in authorization decisions and published in Active Directory.
+
+Claims make it possible for administrators to make precise organization- or enterprise-wide statements about users, devices, and resources that can be incorporated in expressions, rules, and policies.
+
+### <a href="" id="bkmk-expressions2"></a>Expressions
+
+Conditional expressions are an enhancement to access control management that allow or deny access to resources only when certain conditions are met, for example, group membership, location, or the security state of the device. Expressions are managed through the Advanced Security Settings dialog box of the ACL Editor or the Central Access Rule Editor in the Active Directory Administrative Center (ADAC).
+
+Expressions help administrators manage access to sensitive resources with flexible conditions in increasingly complex business environments.
+
+### <a href="" id="bkmk-permissions2"></a>Proposed permissions
+
+Proposed permissions enable an administrator to more accurately model the impact of potential changes to access control settings without actually changing them.
+
+Predicting the effective access to a resource helps you plan and configure permissions for those resources before implementing those changes.
+
+## Additional changes
+
+
+Additional enhancements in the supported versions of Windows that support Dynamic Access Control include:
+
+### Support in the Kerberos authentication protocol to reliably provide user claims, device claims, and device groups.
+
+By default, devices running any of the supported versions of Windows are able to process Dynamic Access Control-related Kerberos tickets, which include data needed for compound authentication. Domain controllers are able to issue and respond to Kerberos tickets with compound authentication-related information. When a domain is configured to recognize Dynamic Access Control, devices receive claims from domain controllers during initial authentication, and they receive compound authentication tickets when submitting service ticket requests. Compound authentication results in an access token that includes the identity of the user and the device on the resources that recognize Dynamic Access Control.
+
+### Support for using the Key Distribution Center (KDC) Group Policy setting to enable Dynamic Access Control for a domain.
+
+Every domain controller needs to have the same Administrative Template policy setting, which is located at **Computer Configuration\\Policies\\Administrative Templates\\System\\KDC\\Support Dynamic Access Control and Kerberos armoring**.
+
+### Support for using the Key Distribution Center (KDC) Group Policy setting to enable Dynamic Access Control for a domain.
+
+Every domain controller needs to have the same Administrative Template policy setting, which is located at **Computer Configuration\\Policies\\Administrative Templates\\System\\KDC\\Support Dynamic Access Control and Kerberos armoring**.
+
+### Support in Active Directory to store user and device claims, resource properties, and central access policy objects.
+
+### Support for using Group Policy to deploy central access policy objects.
+
+The following Group Policy setting enables you to deploy central access policy objects to file servers in your organization: **Computer Configuration\\Policies\\ Windows Settings\\Security Settings\\File System\\Central Access Policy**.
+
+### Support for claims-based file authorization and auditing for file systems by using Group Policy and Global Object Access Auditing
+
+You must enable staged central access policy auditing to audit the effective access of central access policy by using proposed permissions. You configure this setting for the computer under **Advanced Audit Policy Configuration** in the **Security Settings** of a Group Policy Object (GPO). After you configure the security setting in the GPO, you can deploy the GPO to computers in your network.
+
+### Support for transforming or filtering claim policy objects that traverse Active Directory forest trusts
+
+You can filter or transform incoming and outgoing claims that traverse a forest trust. There are three basic scenarios for filtering and transforming claims:
+
+-   **Value-based filtering**  Filters can be based on the value of a claim. This allows the trusted forest to prevent claims with certain values from being sent to the trusting forest. Domain controllers in trusting forests can use value-based filtering to guard against an elevation-of-privilege attack by filtering the incoming claims with specific values from the trusted forest.
+
+-   **Claim type-based filtering**  Filters are based on the type of claim, rather than the value of the claim. You identify the claim type by the name of the claim. You use claim type-based filtering in the trusted forest, and it prevents Windows from sending claims that disclose information to the trusting forest.
+
+-   **Claim type-based transformation**  Manipulates a claim before sending it to the intended target. You use claim type-based transformation in the trusted forest to generalize a known claim that contains specific information. You can use transformations to generalize the claim-type, the claim value, or both.
+
+## <a href="" id="software-requirements-"></a>Software requirements
+
+
+Because claims and compound authentication for Dynamic Access Control require Kerberos authentication extensions, any domain that supports Dynamic Access Control must have enough domain controllers running the supported versions of Windows to support authentication from Dynamic Access Control-aware Kerberos clients. By default, devices must use domain controllers in other sites. If no such domain controllers are available, authentication will fail. Therefore, you must support one of the following conditions:
+
+-   Every domain that supports Dynamic Access Control must have enough domain controllers running the supported versions of Windows Server to support authentication from all devices running the supported versions of Windows or Windows Server.
+
+-   Devices running the supported versions of Windows or that do not protect resources by using claims or compound identity, should disable Kerberos protocol support for Dynamic Access Control.
+
+For domains that support user claims, every domain controller running the supported versions of Windows server must be configured with the appropriate setting to support claims and compound authentication, and to provide Kerberos armoring. Configure settings in the KDC Administrative Template policy as follows:
+
+-   **Always provide claims**   Use this setting if all domain controllers are running the supported versions of Windows Server. In addition, set the domain functional level to Windows Server 2012 or higher.
+
+-   **Supported**   When you use this setting, monitor domain controllers to ensure that the number of domain controllers running the supported versions of Windows Server is sufficient for the number of client computers that need to access resources protected by Dynamic Access Control.
+
+If the user domain and file server domain are in different forests, all domain controllers in the file server’s forest root must be set at the Windows Server 2012 or higher functional level.
+
+If clients do not recognize Dynamic Access Control, there must be a two-way trust relationship between the two forests.
+
+If claims are transformed when they leave a forest, all domain controllers in the user’s forest root must be set at the Windows Server 2012 or higher functional level.
+
+A file server running Windows Server 2012 or Windows Server 2012 R2 must have a Group Policy setting that specifies whether it needs to get user claims for user tokens that do not carry claims. This setting is set by default to **Automatic**, which results in this Group Policy setting to be turned **On** if there is a central policy that contains user or device claims for that file server. If the file server contains discretionary ACLs that include user claims, you need to set this Group Policy to **On** so that the server knows to request claims on behalf of users that do not provide claims when they access the server.
+
+## Additional resource
+
+[Access control overview](access-control.md)
+
+ 
+
+ 
+
+
+
+

windows/keep-secure/local-accounts.md

@@ -0,0 +1,513 @@
+---
+title: Local Accounts (Windows 10)
+description: Local Accounts
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+---
+
+# Local Accounts
+
+**Applies to**
+-   Windows 10
+-   Windows Server 2016
+
+This reference topic for the IT professional describes the default local user accounts for servers, including how to manage these built-in accounts on a member or standalone server. This topic does not describe the default local user accounts for an Active Directory domain controller.
+
+**Did you mean…**
+
+-   [Active Directory Accounts](active-directory-accounts.md)
+
+-   [Microsoft Accounts](microsoft-accounts.md)
+
+## <a href="" id="about-local-user-accounts-"></a>About local user accounts
+
+
+Local user accounts are stored locally on the server. These accounts can be assigned rights and permissions on a particular server, but on that server only. Local user accounts are security principals that are used to secure and manage access to the resources on a standalone or member server for services or users.
+
+This topic describes the following:
+
+-   [Default local user accounts](#sec-default-accounts)
+
+    -   [Administrator account](#sec-administrator)
+
+    -   [Guest Account](#sec-guest)
+
+    -   [HelpAssistant account (installed by using a Remote Assistance session)](#sec-helpassistant)
+
+-   [Default local system accounts](#sec-localsystem)
+
+-   [How to manage local accounts](#sec-manage-accounts)
+
+    -   [Restrict and protect local accounts with administrative rights](#sec-restrict-protect-accounts)
+
+    -   [Enforce local account restrictions for remote access](#sec-enforce-account-restrictions)
+
+    -   [Deny network logon to all local Administrator accounts](#sec-deny-network-logon)
+
+    -   [Create unique passwords for local accounts with administrative rights](#sec-create-unique-passwords)
+
+For information about security principals, see [Security Principals Technical Overview](security-principals.md).
+
+## <a href="" id="sec-default-accounts"></a>Default local user accounts
+
+
+The default local user accounts are built-in accounts that are created automatically when you install the Windows Server operating system on a stand-alone server or member server. The **Applies To** list at the beginning of this article designates the Windows operating systems to which this topic applies.
+
+After the Windows Server operating system is installed, the default local user accounts cannot be removed or deleted. In addition, default local user accounts do not provide access to network resources.
+
+Default local user accounts are used to manage access to the local server’s resources based on the rights and permissions that are assigned to the account. The default local user accounts, and the local user accounts that you create, are located in the Users folder. The Users folder is located in the Local Users and Groups folder in the local Computer Management Microsoft Management Console (MMC). Computer Management is a collection of administrative tools that you can use to manage a single local or remote computer. For more information, see [How to manage local accounts](#sec-manage-accounts) later in this topic.
+
+The default local user accounts that are provided include the Administrator account, Guest account and HelpAssistant account. Each of these default local user accounts is described in the following sections.
+
+### <a href="" id="sec-administrator"></a>Administrator account
+
+The default local Administrator account is a user account for the system administrator. Every computer has an Administrator account (SID S-1-5-*domain*-500, display name Administrator). The Administrator account is the first account that is created during the installation for all Windows Server operating systems, and for Windows client operating systems.
+
+For Windows Server operating systems, the Administrator account gives the user full control of the files, directories, services, and other resources that are under the control of the local server. The Administrator account can be used to create local users, and assign user rights and access control permissions. The Administrator account can also be used take control of local resources at any time simply by changing the user rights and permissions.
+
+The default Administrator account cannot be deleted or locked out, but it can be renamed or disabled.
+
+The default Administrator account is initially installed differently for Windows Server operating systems, and the Windows client operating systems. The following table provides a comparison.
+
+| Default restriction | Windows Server operating systems | Windows client operating systems |
+|---------------------|----------------------------------|----------------------------------|
+| Administrator account is disabled on installation | No | Yes |
+| Administrator account is set up on first sign-in | Yes | No, keep disabled |
+| Administrator account is used to set up the local server or client computer | Yes | No, use a local user account with **Run as administrator** to obtain administrative rights |
+| Administrator account requires a strong password when it is enabled | Yes | Yes |
+| Administrator account can be disabled, locked out, or renamed | Yes | Yes |
+
+In summary, for Windows Server operating systems, the Administrator account is used to set up the local server only for tasks that require administrative rights. The default Administrator account is set up by using the default settings that are provided on installation. Initially, the Administrator account is not associated with a password. After installation, when you first set up Windows Server, your first task is to set up the Administrator account properties securely. This includes creating a strong password and securing the **Remote control** and **Remote Desktop Services Profile** settings. You can also disable the Administrator account when it is not required.
+
+In comparison, for the Windows client operating systems, the Administrator account has access to the local system only. The default Administrator account is initially disabled by default, and this account is not associated with a password. It is a best practice to leave the Administrator account disabled. The default Administrator account is considered only as a setup and disaster recovery account, and it can be used to join the computer to a domain. When administrator access is required, do not sign in as an administrator. You can sign in to your computer with your local (non-administrator) credentials and use **Run as administrator**. For more information, see [Security considerations](#sec-administrator-security).
+
+**Account group membership**
+
+By default, the Administrator account is installed as a member of the Administrators group on the server. It is a best practice to limit the number of users in the Administrators group because members of the Administrators group on a local server have Full Control permissions on that computer.
+
+The Administrator account cannot be deleted or removed from the Administrators group, but it can be renamed or disabled.
+
+**Security considerations**
+
+Because the Administrator account is known to exist on many versions of the Windows operating system, it is a best practice to disable the Administrator account when possible to make it more difficult for malicious users to gain access to to the server or client computer.
+
+You can rename the Administrator account. However, a renamed Administrator account continues to use the same automatically assigned security identifier (SID), which can be discovered by malicious users. For more information about how to rename or disable a user account, see [Disable or activate a local user account](http://technet.microsoft.com/library/cc732112.aspx) and [Rename a local user account](http://technet.microsoft.com/library/cc725595.aspx).
+
+As a security best practice, use your local (non-Administrator) account to sign in and then use **Run as administrator** to accomplish tasks that require a higher level of rights than a standard user account. Do not use the Administrator account to sign in to your computer unless it is entirely necessary. For more information, see [Run a program with administrative credentials](https://technet.microsoft.com/en-us/library/cc732200.aspx).
+
+In comparison, on the Windows client operating system, a user with a local user account that has Administrator rights is considered the system administrator of the client computer. The first local user account that is created during installation is placed in the local Administrators group. However, when multiple users run as local administrators, the IT staff has no control over these users or their client computers.
+
+In this case, Group Policy can be used to enable secure settings that can control the use of the local Administrators group automatically on every server or client computer. For more information about Group Policy, see [Group Policy Overview](http://technet.microsoft.com/library/hh831791.aspx) and [Group Policy](http://technet.microsoft.com/windowsserver/bb310732.aspx).
+
+**Note**  
+Blank passwords are not allowed in the versions designated in the **Applies To** list at the beginning of this topic.
+
+ 
+
+**Important**  
+Even when the Administrator account has been disabled, it can still be used to gain access to a computer by using safe mode. In the Recovery Console or in safe mode, the Administrator account is automatically enabled. When normal operations are resumed, it is disabled.
+
+ 
+
+### <a href="" id="sec-guest"></a>Guest account
+
+The Guest account (SID S-1-5-32-546) is disabled by default on installation. The Guest account lets occasional or one-time users, who do not have an account on the computer, temporarily sign in to the local server or client computer with limited user rights. By default, the Guest account has a blank password. Because the Guest account can provide anonymous access, it is a security risk. For this reason, it is a best practice to leave the Guest account disabled, unless its use is entirely necessary.
+
+**Account group membership**
+
+By default, the Guest account is the only member of the default Guests group, which lets a user sign in to a server. On occasion, an administrator who is a member of the Administrators group can set up a user with a Guest account on one or more computers.
+
+**Security considerations**
+
+When an administrator enables the Guest account, it is a best practice to create a strong password for this account. In addition, the administrator on the computer should also grant only limited rights and permissions for the Guest account. For security reasons, the Guest account should not be used over the network and made accessible to other computers.
+
+When a computer is shutting down or starting up, it is possible that a guest user or anyone with local access could gain unauthorized access to the computer. To help prevent this risk, do not grant the Guest account the [Shut down the system](shut-down-the-system.md) user right.
+
+In addition, the guest user in the Guest account should not be able to view the event logs. After the Guest account is enabled, it is a best practice to monitor the Guest account frequently to ensure that other users cannot use services and other resources, such as resources that were unintentionally left available by a previous user.
+
+### <a href="" id="sec-helpassistant"></a>HelpAssistant account (installed by using a Remote Assistance session)
+
+The default HelpAssistant account is enabled when a Windows Remote Assistance session is run. The Windows Remote Assistance session can be used to connect from the server to another computer running the Windows operating system. For solicited remote assistance, a user initiates a Windows Remote Assistance session, and it is initiated by invitation. For solicited remote assistance, a user sends an invitation from their computer, through e-mail or as a file, to a person who can provide assistance.
+
+After the user’s invitation for a Windows Remote Assistance session is accepted, the default HelpAssistant account is automatically created. The HelpAssistant account provides limited access to the computer to the person who provides assistance. The HelpAssistant account is managed by the Remote Desktop Help Session Manager service. The HelpAssistant account is automatically deleted after there are no Remote Assistance requests are pending.
+
+The security identifiers (SIDs) that pertain to the default HelpAssistant account include:
+
+-   SID: S-1-5-13, display name Terminal Server User. This group includes all users who sign in to a server with Remote Desktop Services enabled.
+
+-   SID: S-1-5-14, display name Remote Interactive Logon. This group includes all users who sign in to the computer by using Remote Desktop Connection. This group is a subset of the Interactive group. Access tokens that contain the Remote Interactive Logon SID also contain the Interactive SID.
+
+For the Windows Server operating system, Remote Assistance is an optional component that is not installed by default. You must install Remote Assistance before it can be used.
+
+In comparison, for the Windows client operating system, the HelpAssistant account is enabled on installation by default. For more information about remote desktop connections for those client operating systems designated in the **Applies To** list at the beginning of this topic, see [Enable Remote Desktop](http://technet.microsoft.com/library/dd744299.aspx).
+
+## <a href="" id="sec-localsystem"></a>Default local system accounts
+
+
+The system account and the Administrator account of the Administrators group have the same file rights and permissions, but they have different functions. The system account is used by the operating system and by services that run under Windows. There are many services and processes in the Windows operating system that need the capability to sign in internally, such as during a Windows installation. The system account was designed for that purpose. It is an internal account that does not show up in User Manager, it cannot be added to any groups, and it cannot have user rights assigned to it.
+
+On the other hand, the system account does appear on an NTFS file system volume in File Manager in the **Permissions** portion of the **Security** menu. By default, the system account is granted Full Control permissions to all files on an NTFS volume. Here the system account has the same functional rights and permissions as the Administrator account.
+
+**Note**  
+To grant the account Administrators group file permissions does not implicitly give permission to the system account. The system account's permissions can be removed from a file, but we do not recommend removing them.
+
+ 
+
+## <a href="" id="sec-manage-accounts"></a>How to manage local user accounts
+
+
+The default local user accounts, and the local user accounts that you create, are located in the Users folder. The Users folder is located in the Local Users and Groups folder in the local Computer Management Microsoft Management Console (MMC), a collection of administrative tools that you can use to manage a single local or remote computer. For more information about creating and managing local user accounts, see [Manage Local Users](http://technet.microsoft.com/library/cc731899.aspx).
+
+You can use Local Users and Groups to assign rights and permissions on the local server, and that server only, to limit the ability of local users and groups to perform certain actions. A right authorizes a user to perform certain actions on a server, such as backing up files and folders or shutting down a server. An access permission is a rule that is associated with an object, usually a file, folder, or printer. It regulates which users can have access to an object on the server and in what manner.
+
+You cannot use Local Users and Groups to view local users and groups after a member server is used as a domain controller. However, you can use Local Users and Groups on a domain controller to target remote computers that are not domain controllers on the network.
+
+**Note**  
+You use Active Directory Users and Computers to manage users and groups in Active Directory.
+
+ 
+
+### <a href="" id="sec-restrict-protect-accounts"></a>Restrict and protect local accounts with administrative rights
+
+An administrator can use a number of approaches to prevent malicious users from using stolen credentials, such as a stolen password or password hash, for a local account on one computer from being used to authenticate on another computer with administrative rights; this is also called "lateral movement".
+
+The simplest approach is to sign in to your computer with a standard user account, instead of using the Administrator account for tasks, for example, to browse the Internet, send email, or use a word processor. When you want to perform an administrative task, for example, to install a new program or to change a setting that affects other users, you don't have to switch to an Administrator account. You can use User Account Control (UAC) to prompt you for permission or an administrator password before performing the task, as described in the next section.
+
+The other approaches that can be used to restrict and protect user accounts with administrative rights include:
+
+-   Enforce local account restrictions for remote access.
+
+-   Deny network logon to all local Administrator accounts.
+
+-   Create unique passwords for local accounts with administrative rights.
+
+Each of these approaches is described in the following sections.
+
+**Note**  
+These approaches do not apply if all administrative local accounts are disabled.
+
+ 
+
+### <a href="" id="sec-enforce-account-restrictions"></a>Enforce local account restrictions for remote access
+
+The User Account Control (UAC) is a security feature in Windows that has been in use in Windows Server 2008 and in Windows Vista, and the operating systems to which the **Applies To** list refers. UAC enables you to stay in control of your computer by informing you when a program makes a change that requires administrator-level permission. UAC works by adjusting the permission level of your user account. By default, UAC is set to notify you when applications try to make changes to your computer, but you can change how often UAC notifies you.
+
+UAC makes it possible for an account with administrative rights to be treated as a standard user non-administrator account until full rights, also called elevation, is requested and approved. For example, UAC lets an administrator enter credentials during a non-administrator's user session to perform occasional administrative tasks without having to switch users, sign out, or use the **Run as** command.
+
+In addition, UAC can require administrators to specifically approve applications that make system-wide changes before those applications are granted permission to run, even in the administrator's user session.
+
+For example, a default feature of UAC is shown when a local account signs in from a remote computer by using Network logon (for example, by using NET.EXE USE). In this instance, it is issued a standard user token with no administrative rights, but with the ability to request or receive elevation. Consequently, local accounts that sign in by using Network logon cannot access administrative shares such as C$, or ADMIN$, or perform any remote administration.
+
+For summary information about UAC, see [User Account Control](http://technet.microsoft.com/library/cc731416.aspx). For detailed information about special conditions when you use UAC, see [User Account Control](http://technet.microsoft.com/library/cc772207.aspx).
+
+The following table shows the Group Policy and registry settings that are used to enforce local account restrictions for remote access.
+
+<table>
+<colgroup>
+<col width="33%" />
+<col width="33%" />
+<col width="33%" />
+</colgroup>
+<tbody>
+<tr class="odd">
+<td><p><strong>No.</strong></p></td>
+<td><p><strong>Setting</strong></p></td>
+<td><p><strong>Detailed Description</strong></p></td>
+</tr>
+<tr class="even">
+<td><p></p></td>
+<td><p>Policy location</p></td>
+<td><p>Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options</p></td>
+</tr>
+<tr class="odd">
+<td><p>1</p></td>
+<td><p>Policy name</p></td>
+<td><p>[User Account Control: Run all administrators in Admin Approval Mode](user-account-control-run-all-administrators-in-admin-approval-mode.md)</p></td>
+</tr>
+<tr class="even">
+<td><p></p></td>
+<td><p>Policy setting</p></td>
+<td><p>Enabled</p></td>
+</tr>
+<tr class="odd">
+<td><p>2</p></td>
+<td><p>Policy location</p></td>
+<td><p>Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options</p></td>
+</tr>
+<tr class="even">
+<td><p></p></td>
+<td><p>Policy name</p></td>
+<td><p>[User Account Control: Run all administrators in Admin Approval Mode](user-account-control-run-all-administrators-in-admin-approval-mode.md)</p></td>
+</tr>
+<tr class="odd">
+<td><p></p></td>
+<td><p>Policy setting</p></td>
+<td><p>Enabled</p></td>
+</tr>
+<tr class="even">
+<td><p>3</p></td>
+<td><p>Registry key</p></td>
+<td><p><strong>HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System</strong></p></td>
+</tr>
+<tr class="odd">
+<td><p></p></td>
+<td><p>Registry value name</p></td>
+<td><p>LocalAccountTokenFilterPolicy</p></td>
+</tr>
+<tr class="even">
+<td><p></p></td>
+<td><p>Registry value type</p></td>
+<td><p>DWORD</p></td>
+</tr>
+<tr class="odd">
+<td><p></p></td>
+<td><p>Registry value data</p></td>
+<td><p>0</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+**To enforce local account restrictions for remote access**
+
+1.  Start the **Group Policy Management** Console (GPMC).
+
+2.  In the console tree, expand &lt;*Forest*&gt;\\Domains\\&lt;*Domain*&gt;, and then **Group Policy Objects** where *forest* is the name of the forest, and *domain* is the name of the domain where you want to set the Group Policy Object (GPO).
+
+3.  In the console tree, right-click **Group Policy Objects**, and &gt; **New**.
+
+    ![local accounts 1](images/localaccounts-proc1-sample1.png)
+
+4.  In the **New GPO** dialog box, type &lt;**gpo\_name**&gt;, and &gt; **OK** where *gpo\_name* is the name of the new GPO. The GPO name indicates that the GPO is used to restrict local administrator rights from being carried over to another computer.
+
+    ![local accounts 2](images/localaccounts-proc1-sample2.png)
+
+5.  In the details pane, right-click &lt;**gpo\_name**&gt;, and &gt; **Edit**.
+
+    ![local accounts 3](images/localaccounts-proc1-sample3.png)
+
+6.  Ensure that UAC is enabled and that UAC restrictions apply to the default Administrator account by doing the following:
+
+    1.  Navigate to the Computer Configuration\\Policies\\Windows Settings, and &gt; **Security Options**.
+
+    2.  Double-click **User Account Control: Run all administrators in Admin Approval Mode** &gt; **Enabled** &gt; **OK**.
+
+    3.  Double-click **User Account Control: Admin Approval Mode for the Built-in Administrator account** &gt; **Enabled** &gt; **OK**.
+
+7.  Ensure that the local account restrictions are applied to network interfaces by doing the following:
+
+    1.  Navigate to Computer Configuration\\Preferences and Windows Settings, and &gt; **Registry**.
+
+    2.  Right-click **Registry**, and &gt; **New** &gt; **Registry Item**.
+
+        ![local accounts 4](images/localaccounts-proc1-sample4.png)
+
+    3.  In the **New Registry Properties** dialog box, on the **General** tab, change the setting in the **Action** box to **Replace**.
+
+    4.  Ensure that the **Hive** box is set to **HKEY\_LOCAL\_MACHINE**.
+
+    5.  Click (**…**), browse to the following location for **Key Path** &gt; **Select** for: **SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System**.
+
+    6.  In the **Value name** area, type **LocalAccountTokenFilterPolicy**.
+
+    7.  In the **Value type** box, from the drop-down list, select **REG\_DWORD** to change the value.
+
+    8.  In the **Value data** box, ensure that the value is set to **0**.
+
+    9.  Verify this configuration, and &gt; **OK**.
+
+        ![local accounts 5](images/localaccounts-proc1-sample5.png)
+
+8.  Link the GPO to the first **Workstations** organizational unit (OU) by doing the following:
+
+    1.  Navigate to the &lt;*Forest*&gt;\\Domains\\&lt;*Domain*&gt;\\OU path.
+
+    2.  Right-click the **Workstations** OU, and &gt; **Link an existing GPO**.
+
+        ![local accounts 6](images/localaccounts-proc1-sample6.png)
+
+    3.  Select the GPO that you just created, and &gt; **OK**.
+
+9.  Test the functionality of enterprise applications on the workstations in that first OU and resolve any issues caused by the new policy.
+
+10. Create links to all other OUs that contain workstations.
+
+11. Create links to all other OUs that contain servers.
+
+### <a href="" id="sec-deny-network-logon"></a>Deny network logon to all local Administrator accounts
+
+Denying local accounts the ability to perform network logons can help prevent a local account password hash from being reused in a malicious attack. This procedure helps to prevent lateral movement by ensuring that the credentials for local accounts that are stolen from a compromised operating system cannot be used to compromise additional computers that use the same credentials.
+
+**Note**  
+In order to perform this procedure, you must first identify the name of the local, default Administrator account, which might not be the default user name "Administrator", and any other accounts that are members of the local Administrators group.
+
+ 
+
+The following table shows the Group Policy settings that are used to deny network logon for all local Administrator accounts.
+
+<table>
+<colgroup>
+<col width="33%" />
+<col width="33%" />
+<col width="33%" />
+</colgroup>
+<tbody>
+<tr class="odd">
+<td><p><strong>No.</strong></p></td>
+<td><p><strong>Setting</strong></p></td>
+<td><p><strong>Detailed Description</strong></p></td>
+</tr>
+<tr class="even">
+<td><p></p></td>
+<td><p>Policy location</p></td>
+<td><p>Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment</p></td>
+</tr>
+<tr class="odd">
+<td><p>1</p></td>
+<td><p>Policy name</p></td>
+<td><p>[Deny access to this computer from the network](deny-access-to-this-computer-from-the-network.md)</p></td>
+</tr>
+<tr class="even">
+<td><p></p></td>
+<td><p>Policy setting</p></td>
+<td><p>User name of the default Administrator account</p>
+<p>(Might be renamed through policy.)</p></td>
+</tr>
+<tr class="odd">
+<td><p>2</p></td>
+<td><p>Policy location</p></td>
+<td><p>Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment</p></td>
+</tr>
+<tr class="even">
+<td><p></p></td>
+<td><p>Policy name</p></td>
+<td><p>[Deny log on through Remote Desktop Services](deny-log-on-through-remote-desktop-services.md)</p>
+<p>(Windows Server 2008 R2 and later.)</p>
+<p>Deny logon through Terminal Services</p>
+<p>(Windows Server 2008)</p></td>
+</tr>
+<tr class="odd">
+<td><p></p></td>
+<td><p>Policy setting</p></td>
+<td><p>User name of the default Administrator account</p>
+<p>(Might be renamed through policy).</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+**To deny network logon to all local administrator accounts**
+
+1.  Start the **Group Policy Management** Console (GPMC).
+
+2.  In the console tree, expand &lt;*Forest*&gt;\\Domains\\&lt;*Domain*&gt;, and then **Group Policy Objects**, where *forest* is the name of the forest, and *domain* is the name of the domain where you want to set the Group Policy Object (GPO).
+
+3.  In the console tree, right-click **Group Policy Objects**, and &gt; **New**.
+
+4.  In the **New GPO** dialog box, type &lt;**gpo\_name**&gt;, and then &gt; **OK** where *gpo\_name* is the name of the new GPO indicates that it is being used to restrict the local administrative accounts from interactively signing in to the computer.
+
+    ![local accounts 7](images/localaccounts-proc2-sample1.png)
+
+5.  In the details pane, right-click &lt;**gpo\_name**&gt;, and &gt; **Edit**.
+
+    ![local accounts 8](images/localaccounts-proc2-sample2.png)
+
+6.  Configure the user rights to deny network logons for administrative local accounts as follows:
+
+    1.  Navigate to the Computer Configuration\\Policies\\Windows Settings, and &gt; **User Rights Assignment**.
+
+    2.  Double-click **Deny access to this computer from the network**, and &gt; **Define these policy settings**.
+
+    3.  Click **Add User or Group**, type the name of the default Administrator account, and &gt; **OK**. The default name is Administrator on US English installations, but it can be renamed either by policy or manually.
+
+        ![local accounts 9](images/localaccounts-proc2-sample3.png)
+
+        **Important**  
+        In the **User and group names** box, type the user name of the account that you identified at the start of this process. Do not click **Browse** and do not type the domain name or the local computer name in this dialog box. For example, type only **Administrator**. If the text that you typed resolved to a name that is underlined, includes a computer name, or includes the domain, it restricts the wrong account and causes this mitigation to work incorrectly. Also, be careful that you do not enter the group name Administrator to prevent blocking domain accounts in that group.
+
+         
+
+    4.  For any additional local accounts in the Administrators group on all of the workstations that you are configuring, click **Add User or Group**, type the user names of these accounts in the dialog box in the same manner as described in the previous step, and then click **OK**.
+
+7.  Configure the user rights to deny Remote Desktop (Remote Interactive) logons for administrative local accounts as follows:
+
+    1.  Navigate to Computer Configuration\\Policies\\Windows Settings and Local Policies, and then click **User Rights Assignment**.
+
+        **Note**  
+        Depending on the Windows operating system, you can choose the name of the Remote Interactive logon user right.
+
+         
+
+    2.  On computers that run Windows Server 2008, double-click **Deny logon through Terminal Services**, and then select **Define these policy settings**.
+
+    3.  On computers running Windows Server 2012 R2, Windows Server 2012, and Windows Server 2008 R2, double-click **Deny logon through Remote Desktop Services**, and then select **Define these settings**.
+
+    4.  Click **Add User or Group**, type the user name of the default Administrator account, and &gt; **OK**. (The default name is Administrator on US English installations, but it can be renamed either by policy or manually.
+
+        **Important**  
+        In the **User and group names** box, type the user name of the account that you identified at the start of this process. Do not click **Browse** and do not type the domain name or the local computer name in this dialog box. For example, type only **Administrator**. If the text that you typed resolves to a name that is underlined or includes a domain name, it restricts the wrong account and causes this mitigation to work incorrectly. Also, be careful that you do not enter the group name Administrator because this also blocks domain accounts in that group.
+
+         
+
+    5.  For any additional local accounts in the Administrators group on all of the workstations that you are setting up, click **Add User or Group**, type the user names of these accounts in the dialog box in the same manner as the previous step, and &gt; **OK**.
+
+8.  Link the GPO to the first **Workstations** OU as follows:
+
+    1.  Navigate to the &lt;*Forest*&gt;\\Domains\\&lt;*Domain*&gt;\\OU path.
+
+    2.  Right-click the **Workstations** OU, and &gt; **Link an existing GPO**.
+
+    3.  Select the GPO that you just created, and &gt; **OK**.
+
+9.  Test the functionality of enterprise applications on the workstations in that first OU and resolve any issues caused by the new policy.
+
+10. Create links to all other OUs that contain workstations.
+
+11. Create links to all other OUs that contain servers.
+
+    **Note**  
+    You might have to create a separate GPO if the user name of the default Administrator account is different on workstations and servers.
+
+     
+
+### <a href="" id="sec-create-unique-passwords"></a>Create unique passwords for local accounts with administrative rights
+
+Passwords should be unique per individual account. While this is generally true for individual user accounts, many enterprises have identical passwords for common local accounts, such as the default Administrator account. This also occurs when the same passwords are used for local accounts during operating system deployments.
+
+Passwords that are left unchanged or changed synchronously to keep them identical add a significant risk for organizations. Randomizing the passwords mitigates "pass-the-hash" attacks by using different passwords for local accounts, which hampers the ability of malicious users to use password hashes of those accounts to compromise other computers.
+
+Passwords can be randomized by:
+
+-   Purchasing and implementing an enterprise tool to accomplish this task. These tools are commonly referred to as "privileged password management" tools.
+
+-   Configuring, customizing and implementing a free tool to accomplish this task. A sample tool with source code is available at [Solution for management of built-in Administrator account’s password via GPO](http://code.msdn.microsoft.com/windowsdesktop/Solution-for-management-of-ae44e789).
+
+    **Note**  
+    This tool is not supported by Microsoft. There are some important considerations to make before deploying this tool because this tool requires client-side extensions and schema extensions to support password generation and storage.
+
+     
+
+-   Create and implement a custom script or solution to randomize local account passwords.
+
+## <a href="" id="dhcp-references"></a>See also
+
+
+The following resources provide additional information about technologies that are related to local accounts.
+
+-   [Security Principals Technical Overview](security-principals.md)
+
+-   [Security Identifiers Technical Overview](security-identifiers.md)
+
+-   [Access Control Overview](access-control.md)
+
+ 
+
+ 
+
+
+
+

windows/keep-secure/microsoft-accounts.md

@@ -0,0 +1,168 @@
+---
+title: Microsoft Accounts (Windows 10)
+description: Microsoft Accounts
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+---
+
+# Microsoft Accounts
+
+**Applies to**
+-   Windows 10
+
+This topic for the IT professional explains how a Microsoft account works to enhance security and privacy for users, and how you can manage this consumer account type in your organization.
+
+Microsoft sites, services, and properties such as Windows Live, MSN, Xbox LIVE, Zune, Windows Phone, and computers running Windows 8.1, Windows 8, and Windows RT use a Microsoft account as a mean of identifying users. Microsoft account is the name for what was previously called Windows Live ID. It has user-defined secrets associated with it, and it consists of a unique email address and a password.
+
+There are some benefits and considerations when using Microsoft accounts in the enterprise. For more information, see [Microsoft account in the enterprise](#bkmk-msaccountintheenterprise) later in this topic.
+
+When a user signs in with a Microsoft account, their device is connected to cloud services, and many of the settings, preferences, and apps associated with that user account can roam between devices.
+
+**Note**  
+This content applies to the operating system versions that are designated in the **Applies To** list at the beginning of this topic.
+
+ 
+
+## <a href="" id="bkmk-benefits"></a>How a Microsoft account works
+
+
+The Microsoft account allows users to sign in to websites that support this service by using a single set of credentials. Users' credentials are validated by a Microsoft account authentication server that is associated with a website. The Windows Store is an example of this association. When new users sign in to websites that are enabled to use Microsoft accounts, they are redirected to the nearest authentication server, which asks for a user name and password. Windows uses the Schannel Security Support Provider to open a Transport Level Security/Secure Sockets Layer (TLS/SSL) connection for this function. Users then have the option to use Credential Manager to store their credentials.
+
+When users sign in to websites that are enabled to use a Microsoft account, a time-limited cookie is installed on their computers, which includes a triple DES encrypted ID tag. This encrypted ID tag has been agreed upon between the authentication server and the website. This ID tag is sent to the website, and the website plants another time-limited encrypted HTTP cookie on the user’s computer. When these cookies are valid, users are not required to supply a user name and password. If a user actively signs out of their Microsoft account, these cookies are removed.
+
+**Important**  
+Local Windows account functionality has not been removed, and it is still an option to use in managed environments.
+
+ 
+
+### How Microsoft accounts are created
+
+To prevent fraud, the Microsoft system verifies the IP address when a user creates an account. If a user tries to create multiple Microsoft accounts with the same IP address, they are stopped.
+
+Microsoft accounts are not designed to be created in batches, for example, for a group of domain users within your enterprise.
+
+There are two methods for creating a Microsoft account:
+
+-   **Use an existing email address**.
+
+    Users are able to use their valid email addresses to sign up for Microsoft accounts. The service turns the requesting user's email address into a Microsoft account. Users can also choose their personal password.
+
+-   **Sign up for a Microsoft email address**.
+
+    Users can sign up for an email account with Microsoft's webmail services. This account can be used to sign in to websites that are enabled to use Microsoft accounts.
+
+### How the Microsoft account information is safeguarded
+
+Credential information is encrypted twice. The first encryption is based on the account’s password. Credentials are encrypted again when they are sent across the Internet. The data that is stored is not available to other Microsoft or non-Microsoft services.
+
+-   **Strong password is required**.
+
+    Blank passwords are not allowed.
+
+    For more information, see [Microsoft Account Security Overview](http://www.microsoft.com/account/security/default.aspx).
+
+-   **Secondary proof of identity is required**.
+
+    Before user profile information and settings can be accessed on a second supported Windows computer for the first time, trust must established for that device by providing secondary proof of identity. This can be accomplished by providing Windows with a code that is sent to a mobile phone number or by following the instructions that are sent to an alternate email address that a user specifies in the account settings.
+
+-   **All user profile data is encrypted on the client before it is transmitted to the cloud**.
+
+    User data does not roam over a wireless wide area network (WWAN) by default, thereby protecting profile data. All data and settings that leave a device are transmitted through the TLS/SSL protocol.
+
+**Microsoft account security information is added**.
+
+Users can add security information to their Microsoft accounts through the **Accounts** interface on computers running the supported versions of Windows. This feature allows the user to update the security information that they provided when they created their accounts. This security information includes an alternate email address or phone number so if their password is compromised or forgotten, a verification code can be sent to verify their identity. Users can potentially use their Microsoft accounts to store corporate data on a personal OneDrive or email app, so it is safe practice for the account owner to keep this security information up-to-date.
+
+## <a href="" id="bkmk-msaccountintheenterprise"></a>The Microsoft account in the enterprise
+
+
+Although the Microsoft account was designed to serve consumers, you might find situations where your domain users can benefit by using their personal Microsoft account in your enterprise. The following list describes some advantages.
+
+-   **Download Windows Store apps**:
+
+    If your enterprise chooses to distribute software through the Windows Store, your users can use their Microsoft accounts to download and use them on up to five devices running any version of Windows 8.1, Windows 8, or Windows RT.
+
+-   **Single sign-on**:
+
+    Your users can use Microsoft account credentials to sign in to devices running Windows 8.1, Windows 8 or Windows RT. When they do this, Windows works with your Windows Store app to provide authenticated experiences for them. Users can associate a Microsoft account with their sign-in credentials for Windows Store apps or websites, so that these credentials roam across any devices running these supported versions.
+
+-   **Personalized settings synchronization**:
+
+    Users can associate their most commonly used operating-system settings with a Microsoft account. These settings are available whenever a user signs in with that account on any device that is running a supported version of Windows and is connected to the cloud. After a user signs in, the device automatically attempts to get the user's settings from the cloud and apply them to the device.
+
+-   **App synchronization**:
+
+    Windows Store apps can store user-specific settings so that these settings are available to any device. As with operating system settings, these user-specific app settings are available whenever the user signs in with the same Microsoft account on any device that is running a supported version of Windows and is connected to the cloud. After the user signs in, that device automatically downloads the settings from the cloud and applies them when the app is installed.
+
+-   **Integrated social media services**:
+
+    Contact information and status for your users’ friends and associates automatically stay up-to-date from sites such as Hotmail, Outlook, Facebook, Twitter, and LinkedIn. Users can also access and share photos, documents, and other files from sites such as SkyDrive, Facebook, and Flickr.
+
+### Managing the Microsoft account in the domain
+
+Depending on your IT and business models, introducing Microsoft accounts into your enterprise might add complexity or it might provide solutions. You should address the following considerations before you allow the use of these account types in your enterprise:
+
+-   [Restrict the use of the Microsoft account](#bkmk-restrictuse)
+
+-   [Configure connected accounts](#bkmk-cfgconnectedaccounts)
+
+-   [Provision Microsoft accounts in the enterprise](#bkmk-provisionaccounts)
+
+-   [Audit account activity](#bkmk-audit)
+
+-   [Perform password resets](#bkmk-passwordresets)
+
+-   [Restrict app installation and usage](#bkmk-restrictappinstallationandusage)
+
+### <a href="" id="bkmk-restrictuse"></a>Restrict the use of the Microsoft account
+
+If employees are allowed to join the domain with their personal devices, they might expect to connect to enterprise resources by using their Microsoft accounts. If you want to prevent any use of Microsoft accounts within your enterprise, you can configure the local security policy setting [Accounts: Block Microsoft accounts](accounts-block-microsoft-accounts.md). However, this setting can prevent the users from signing in to their Windows devices with their Microsoft accounts (if they had set them up to do so) when they are joined to the domain.
+
+The default for this setting is **Disabled**, which enables users to use their Microsoft accounts on devices that are joined to your domain. Other options in the setting can:
+
+1.  Prevent users from creating new Microsoft accounts on a computer, switch a local account to a Microsoft account, or connect a domain account to a Microsoft account. This is the preferred option if you need to limit the use of Microsoft accounts in your enterprise.
+
+2.  Prevent users with an existing Microsoft account from signing in to Windows. Selecting this option might make it impossible for an existing administrator to sign in to a computer and manage the system.
+
+### <a href="" id="bkmk-cfgconnectedaccounts"></a>Configure connected accounts
+
+Users can connect a Microsoft account to their domain account and synchronize the settings and preferences between them. This enables users to see the same desktop background, app settings, browser history and favorites, and other Microsoft account settings on their other devices.
+
+Users can disconnect a Microsoft account from their domain account at any time as follows: In **PC settings**, tap or click **Users**, tap or click **Disconnect**, and then tap or click **Finish**.
+
+**Note**  
+Connecting Microsoft accounts with domain accounts can limit access to some high-privileged tasks in Windows. For example, Task Scheduler will evaluate the connected Microsoft account for access and fail. In these situations, the account owner should disconnect the account.
+
+ 
+
+### <a href="" id="bkmk-provisionaccounts"></a>Provision Microsoft accounts in the enterprise
+
+Microsoft accounts are private user accounts. There are no methods provided by Microsoft to provision Microsoft accounts for an enterprise. Enterprises should use domain accounts.
+
+### <a href="" id="bkmk-audit"></a>Audit account activity
+
+Because Microsoft accounts are Internet-based, Windows does not have a mechanism to audit their use until the account is associated with a domain account. But this association does not restrict the user from disconnecting the account or disjoining from the domain. It is not possible to audit the activity of accounts that are not associated with your domain.
+
+### <a href="" id="bkmk-passwordresets"></a>Perform password resets
+
+Only the owner of the Microsoft account can change the password. Passwords can be changed in the [Microsoft account sign-in portal](https://login.live.com).
+
+### <a href="" id="bkmk-restrictappinstallationandusage"></a>Restrict app installation and usage
+
+Within your organization, you can set application control policies to regulate app installation and usage for Microsoft accounts. For more information, see [AppLocker](applocker-overview.md) and [Packaged Apps and Packaged App Installer Rules in AppLocker](packaged-apps-and-packaged-app-installer-rules-in-applocker.md).
+
+## See also
+
+
+[Managing Privacy: Using a Microsoft Account to Logon and Resulting Internet Communication](https://technet.microsoft.com/library/jj884082(v=ws.11).aspx)
+
+
+ 
+
+ 
+
+
+
+

windows/keep-secure/security-identifiers.md

@@ -0,0 +1,279 @@
+---
+title: Security identifiers (Windows 10)
+description: Security identifiers
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+---
+
+# Security identifiers
+
+**Applies to**
+-   Windows 10
+-   Windows Server 2016
+
+This topic for the IT professional describes security identifiers and how they work in regards to accounts and groups in the Windows operating system.
+
+## What are security identifiers?
+
+A security identifier (SID) is used to uniquely identify a security principal or security group. Security principals can represent any entity that can be authenticated by the operating system, such as a user account, a computer account, or a thread or process that runs in the security context of a user or computer account.
+
+Each account or group, or process running in the security context of the account, has a unique SID that is issued by an authority, such as a Windows domain controller. It is stored in a security database. The system generates the SID that identifies a particular account or group at the time the account or group is created. When a SID has been used as the unique identifier for a user or group, it can never be used again to identify another user or group.
+
+Each time a user signs in, the system creates an access token for that user. The access token contains the user's SID, user rights, and the SIDs for any groups the user belongs to. This token provides the security context for whatever actions the user performs on that computer.
+
+In addition to the uniquely created, domain-specific SIDs that are assigned to specific users and groups, there are well-known SIDs that identify generic groups and generic users. For example, the Everyone and World SIDs identify a group that includes all users. Well-known SIDs have values that remain constant across all operating systems.
+
+SIDs are a fundamental building block of the Windows security model. They work with specific components of the authorization and access control technologies in the security infrastructure of the Windows Server operating systems. This helps protect access to network resources and provides a more secure computing environment.
+
+The content in this topic applies to computers that are running the supported versions of the Windows operating system as designated in the **Applies To** list at the beginning of this topic.
+
+## How security identifiers work
+
+Users refer to accounts by using the account name, but the operating system internally refers to accounts and processes that run in the security context of the account by using their security identifiers (SIDs). For domain accounts, the SID of a security principal is created by concatenating the SID of the domain with a relative identifier (RID) for the account. SIDs are unique within their scope (domain or local), and they are never reused.
+
+The operating system generates a SID that identifies a particular account or group at the time the account or group is created. The SID for a local account or group is generated by the Local Security Authority (LSA) on the computer, and it is stored with other account information in a secure area of the registry. The SID for a domain account or group is generated by the domain security authority, and it is stored as an attribute of the User or Group object in Active Directory Domain Services.
+
+For every local account and group, the SID is unique for the computer where it was created. No two accounts or groups on the computer ever share the same SID. Likewise, for every domain account and group, the SID is unique within an enterprise. This means that the SID for an account or group that is created in one domain will never match the SID for an account or group created in any other domain in the enterprise.
+
+SIDs always remain unique. Security authorities never issue the same SID twice, and they never reuse SIDs for deleted accounts. For example, if a user with a user account in a Windows domain leaves her job, an administrator deletes her Active Directory account, including the SID that identifies the account. If she later returns to a different job at the same company, an administrator creates a new account, and the Windows Server operating system generates a new SID. The new SID does not match the old one; so none of the user's access from her old account is transferred to the new account. Her two accounts represent two completely different security principals.
+
+## Security identifier architecture
+
+A security identifier is a data structure in binary format that contains a variable number of values. The first values in the structure contain information about the SID structure. The remaining values are arranged in a hierarchy (similar to a telephone number), and they identify the SID-issuing authority (for example, the Windows Server 2012 operating system), the SID-issuing domain, and a particular security principal or group. The following image illustrates the structure of a SID.
+
+![](images/security-identifider-architecture.jpg)
+
+The individual values of a SID are described in the following table.
+
+| Comment | Description |
+| - | - |
+|  Revision | Indicates the version of the SID structure that is used in a particular SID. |
+| Identifier authority | Identifies the highest level of authority that can issue SIDs for a particular type of security principal. For example, the identifier authority value in the SID for the Everyone group is 1 (World Authority). The identifier authority value in the SID for a specific Windows Server account or group is 5 (NT Authority). |
+| Subauthorities | >Holds the most important information in a SID, which is contained in a series of one or more subauthority values. All values up to, but not including, the last value in the series collectively identify a domain in an enterprise. This part of the series is called the domain identifier. The last value in the series, which is called the relative identifier (RID), identifies a particular account or group relative to a domain. |
+
+The components of a SID are easier to visualize when SIDs are converted from a binary to a string format by using standard notation:
+```
+S-R-X-Y1-Y2-Yn-1-Yn
+```
+
+In this notation, the components of a SID are represented as shown in the following table.
+
+| Comment | Description |
+| - | - |
+| S | Indicates that the string is a SID |
+| R | Indicates the revision level |
+| X | Indicates the identifier authority value |
+| Y | Represents a series of subauthority values, where *n* is the number of values |
+
+The SID's most important information is contained in the series of subauthority values. The first part of the series (-Y1-Y2-Y*n*-1) is the domain identifier. This element of the SID becomes significant in an enterprise with several domains, because the domain identifier differentiates SIDs that are issued by one domain from SIDs that are issued by all other domains in the enterprise. No two domains in an enterprise share the same domain identifier.
+
+The last item in the series of subauthority values (-Y*n*) is the relative identifier. It distinguishes one account or group from all other accounts and groups in the domain. No two accounts or groups in any domain share the same relative identifier.
+
+For example, the SID for the built-in Administrators group is represented in standardized SID notation as the following string:
+
+```
+S-1-5-32-544
+```
+
+This SID has four components:
+
+-   A revision level (1)
+
+-   An identifier authority value (5, NT Authority)
+
+-   A domain identifier (32, Builtin)
+
+-   A relative identifier (544, Administrators)
+
+SIDs for built-in accounts and groups always have the same domain identifier value: 32. This value identifies the domain **Builtin**, which exists on every computer that is running a version of the Windows Server operating system. It is never necessary to distinguish one computer's built-in accounts and groups from another computer's built-in accounts and groups because they are local in scope. They are local to a single computer, or in the case of domain controllers for a network domain, they are local to several computers that are acting as one.
+
+Built-in accounts and groups need to be distinguished from one another within the scope of the **Builtin** domain. Therefore, the SID for each account and group has a unique relative identifier. A relative identifier value of 544 is unique to the built-in Administrators group. No other account or group in the **Builtin** domain has a SID with a final value of 544.
+
+In another example, consider the SID for the global group, Domain Admins. Every domain in an enterprise has a Domain Admins group, and the SID for each group is different. The following example represents the SID for the Domain Admins group in the Contoso, Ltd. domain (Contoso\\Domain Admins):
+
+```
+S-1-5-21-1004336348-1177238915-682003330-512
+```
+
+The SID for Contoso\\Domain Admins has:
+
+-   A revision level (1)
+
+-   An identifier authority (5, NT Authority)
+
+-   A domain identifier (21-1004336348-1177238915-682003330, Contoso)
+
+-   A relative identifier (512, Domain Admins)
+
+The SID for Contoso\\Domain Admins is distinguished from the SIDs for other Domain Admins groups in the same enterprise by its domain identifier: 21-1004336348-1177238915-682003330. No other domain in the enterprise uses this value as its domain identifier. The SID for Contoso\\Domain Admins is distinguished from the SIDs for other accounts and groups that are created in the Contoso domain by its relative identifier, 512. No other account or group in the domain has a SID with a final value of 512.
+
+## Relative identifier allocation
+
+When accounts and groups are stored in an account database that is managed by a local Security Accounts Manager (SAM), it is fairly easy for the system to generate a unique relative identifier for each account and in a group that it creates on a stand-alone computer. The SAM on a stand-alone computer can track the relative identifier values that it has used before and make sure that it never uses them again.
+
+In a network domain, however, generating unique relative identifiers is a more complex process. Windows Server network domains can have several domain controllers. Each domain controller stores Active Directory account information. This means that, in a network domain, there are as many copies of the account database as there are domain controllers. In addition to this, every copy of the account database is a master copy. New accounts and groups can be created on any domain controller. Changes that are made to Active Directory on one domain controller are replicated to all other domain controllers in the domain. The process of replicating changes in one master copy of the account database to all other master copies is called a multimaster operation.
+
+The process of generating unique relative identifiers is a single-master operation. One domain controller is assigned the role of relative identifier (RID) master, and it allocates a sequence of relative identifiers to each domain controller in the domain. When a new domain account or group is created in one domain controller's replica of Active Directory, it is assigned a SID. The relative identifier for the new SID is taken from the domain controller's allocation of relative identifiers. When its supply of relative identifiers begins to run low, the domain controller requests another block from the RID master.
+
+Each domain controller uses each value in a block of relative identifiers only once. The RID master allocates each block of relative identifier values only once. This process assures that every account and group created in the domain has a unique relative identifier.
+
+## Security identifiers and globally unique identifiers
+
+When a new domain user or group account is created, Active Directory stores the account's SID in the **ObjectSID** property of a User or Group object. It also assigns the new object a globally unique identifier (GUID), which is a 128-bit value that is unique not only in the enterprise, but also across the world. GUIDs are assigned to every object that is created by Active Directory, not only User and Group objects. Each object's GUID is stored in its **ObjectGUID** property.
+
+Active Directory uses GUIDs internally to identify objects. For example, the GUID is one of an object's properties that is published in the global catalog. Searching the global catalog for a User object GUID produces results if the user has an account somewhere in the enterprise. In fact, searching for any object by **ObjectGUID** might be the most reliable way of finding the object you want to locate. The values of other object properties can change, but the **ObjectGUID** property never changes. When an object is assigned a GUID, it keeps that value for life.
+
+If a user moves from one domain to another, the user gets a new SID. The SID for a group object does not change because groups stay in the domain where they were created. However, if people move, their accounts can move with them. If an employee moves from North America to Europe, but stays in the same company, an administrator for the enterprise can move the employee's User object from, for example, Contoso\\NoAm to Contoso\\Europe. If the administrator does this, the User object for the account needs a new SID. The domain identifier portion of a SID that is issued in NoAm is unique to NoAm; so the SID for the user's account in Europe has a different domain identifier. The relative identifier portion of a SID is unique relative to the domain; so if the domain changes, the relative identifier also changes.
+
+When a User object moves from one domain to another, a new SID must be generated for the user account and stored in the **ObjectSID** property. Before the new value is written to the property, the previous value is copied to another property of a User object, **SIDHistory**. This property can hold multiple values. Each time a User object moves to another domain, a new SID is generated and stored in the **ObjectSID** property, and another value is added to the list of old SIDs in **SIDHistory**. When a user signs in and is successfully authenticated, the domain authentication service queries Active Directory for all the SIDs that are associated with the user, including the user's current SID, the user's old SIDs, and the SIDs for the user's groups. All these SIDs are returned to the authentication client, and they are included in the user's access token. When the user tries to gain access to a resource, any one of the SIDs in the access token (including one of the SIDs in **SIDHistory**), can allow or deny the user access.
+
+If you allow or deny users' access to a resource based on their jobs, you should allow or deny access to a group, not to an individual. That way, when users change jobs or move to other departments, you can easily adjust their access by removing them from certain groups and adding them to others.
+
+However, if you allow or deny an individual user access to resources, you probably want that user's access to remain the same no matter how many times the user's account domain changes. The **SIDHistory** property makes this possible. When a user changes domains, there is no need to change the access control list (ACL) on any resource. If an ACL has the user's old SID, but not the new one, the old SID is still in the user's access token. It is listed among the SIDs for the user's groups, and the user is granted or denied access based on the old SID.
+
+## Well-known SIDs
+
+The values of certain SIDs are constant across all systems. They are created when the operating system or domain is installed. They are called well-known SIDs because they identify generic users or generic groups.
+
+There are universal well-known SIDs that are meaningful on all secure systems that use this security model, including operating systems other than Windows. In addition, there are well-known SIDs that are meaningful only on Windows operating systems.
+
+The following table lists the universal well-known SIDs.
+
+| Value | Universal Well-Known SID | Identifies |
+| - | - | - |
+| S-1-0-0 | Null SID | A group with no members. This is often used when a SID value is not known.|
+| S-1-1-0 | World | A group that includes all users. |
+| S-1-2-0 | Local | Users who log on to terminals that are locally (physically) connected to the system. |
+| S-1-2-1 | Console Logon | A group that includes users who are logged on to the physical console. |
+| S-1-3-0 | Creator Owner ID | A security identifier to be replaced by the security identifier of the user who created a new object. This SID is used in inheritable ACEs. |
+| S-1-3-1 | Creator Group ID | A security identifier to be replaced by the primary-group SID of the user who created a new object. Use this SID in inheritable ACEs. |
+| S-1-3-2 | Creator Owner Server | |
+| S-1-3-3 | Creator Group Server | |
+| S-1-3-4 | Owner Rights | A group that represents the current owner of the object. When an ACE that carries this SID is applied to an object, the system ignores the implicit READ_CONTROL and WRITE_DAC permissions for the object owner. |
+| S-1-4 | Non-unique Authority | A SID that represents an identifier authority. |
+| S-1-5 | NT Authority | A SID that represents an identifier authority. |
+| S-1-5-80-0 | All Services | A group that includes all service processes configured on the system. Membership is controlled by the operating system.|
+
+The following table lists the predefined identifier authority constants. The first four values are used with universal well-known SIDs, and the last value is used with well-known SIDs in Windows operating systems designated in the **Applies To** list.
+
+| Identifier Authority | Value | SID String Prefix |
+| - | - | - |
+| SECURITY_NULL_SID_AUTHORITY | 0 | S-1-0 |
+| SECURITY_WORLD_SID_AUTHORITY | 1 | S-1-1 |
+| SECURITY_LOCAL_SID_AUTHORITY | 2 | S-1-2 |
+| SECURITY_CREATOR_SID_AUTHORITY | 3 | S-1-3 |
+
+The following RID values are used with universal well-known SIDs. The Identifier authority column shows the prefix of the identifier authority with which you can combine the RID to create a universal well-known SID.
+
+| Relative Identifier Authority | Value | Identifier Authority |
+| - | - | - |
+| SECURITY_NULL_RID | 0 | S-1-0 |
+| SECURITY_WORLD_RID | 0 | S-1-1 |
+| SECURITY_LOCAL_RID | 0 | S-1-2 |
+| SECURITY_CREATOR_OWNER_RID | 0 | S-1-3 |
+| SECURITY_CREATOR_GROUP_RID | 1 | S-1-3 |
+
+The SECURITY\_NT\_AUTHORITY (S-1-5) predefined identifier authority produces SIDs that are not universal and are meaningful only in installations of the Windows operating systems that are designated in the **Applies To** list at the beginning of this topic. The following table lists the well-known SIDs.
+
+| SID | Display Name | Description |
+| - | - | - |
+| S-1-5-1 | Dialup | A group that includes all users who are logged on to the system by means of a dial-up connection.| 
+| S-1-5-113 | Local account| You can use this SID when restricting network logon to local accounts instead of "administrator" or equivalent. This SID can be effective in blocking network logon for local users and groups by account type regardless of what they are actually named.|
+| S-1-5-114| Local account and member of Administrators group | You can use this SID when restricting network logon to local accounts instead of "administrator" or equivalent. This SID can be effective in blocking network logon for local users and groups by account type regardless of what they are actually named. |
+| S-1-5-2 | Network | A group that includes all users who are logged on by means of a network connection. Access tokens for interactive users do not contain the Network SID.|
+| S-1-5-3 | Batch | A group that includes all users who have logged on by means of a batch queue facility, such as task scheduler jobs.| 
+| S-1-5-4 | Interactive| A group that includes all users who log on interactively. A user can start an interactive logon session by logging on directly at the keyboard, by opening a Remote Desktop Services connection from a remote computer, or by using a remote shell such as Telnet. In each case, the user's access token contains the Interactive SID. If the user signs in by using a Remote Desktop Services connection, the user's access token also contains the Remote Interactive Logon SID.| 
+| S-1-5-5- *X *- *Y * | Logon Session| The  *X * and  *Y * values for these SIDs uniquely identify a particular logon session.| 
+| S-1-5-6 | Service| A group that includes all security principals that have signed in as a service.|
+| S-1-5-7 | Anonymous Logon| A user who has connected to the computer without supplying a user name and password.<br/>The Anonymous Logon identity is different from the identity that is used by Internet Information Services (IIS) for anonymous web access. IIS uses an actual account—by default, IUSR_ *ComputerName *, for anonymous access to resources on a website. Strictly speaking, such access is not anonymous because the security principal is known even though unidentified people are using the account. IUSR_ *ComputerName * (or whatever you name the account) has a password, and IIS logs on the account when the service starts. As a result, the IIS "anonymous" user is a member of Authenticated Users but Anonymous Logon is not.| 
+| S-1-5-8| Proxy| Does not currently apply: this SID is not used.| 
+| S-1-5-9 | Enterprise Domain Controllers| A group that includes all domain controllers in a forest of domains.|
+| S-1-5-10 | Self| A placeholder in an ACE for a user, group, or computer object in Active Directory. When you grant permissions to Self, you grant them to the security principal that is represented by the object. During an access check, the operating system replaces the SID for Self with the SID for the security principal that is represented by the object.| 
+| S-1-5-11 | Authenticated Users| A group that includes all users and computers with identities that have been authenticated. Authenticated Users does not include Guest even if the Guest account has a password.<br/>This group includes authenticated security principals from any trusted domain, not only the current domain.|
+| S-1-5-12 | Restricted Code| An identity that is used by a process that is running in a restricted security context. In Windows and Windows Server operating systems, a software restriction policy can assign one of three security levels to code: unrestricted, restricted, or disallowed. When code runs at the restricted security level, the Restricted SID is added to the user's access token.| 
+| S-1-5-13 | Terminal Server User| A group that includes all users who sign in to a server with Remote Desktop Services enabled.| 
+| S-1-5-14 | Remote Interactive Logon| A group that includes all users who log on to the computer by using a remote desktop connection. This group is a subset of the Interactive group. Access tokens that contain the Remote Interactive Logon SID also contain the Interactive SID.| 
+| S-1-5-15| This Organization| A group that includes all users from the same organization. Only included with Active Directory accounts and only added by a domain controller.| 
+| S-1-5-17 | IIS_USRS| An account that is used by the default Internet Information Services (IIS) user.| 
+| S-1-5-18 | System (or LocalSystem)| An identity that is used locally by the operating system and by services that are configured to sign in as LocalSystem.<br/>System is a hidden member of Administrators. That is, any process running as System has the SID for the built-in Administrators group in its access token.<br/>When a process that is running locally as System accesses network resources, it does so by using the computer's domain identity. Its access token on the remote computer includes the SID for the local computer's domain account plus SIDs for security groups that the computer is a member of, such as Domain Computers and Authenticated Users.| 
+| S-1-5-19 | NT Authority (LocalService)| An identity that is used by services that are local to the computer, have no need for extensive local access, and do not need authenticated network access. Services that run as LocalService access local resources as ordinary users, and they access network resources as anonymous users. As a result, a service that runs as LocalService has significantly less authority than a service that runs as LocalSystem locally and on the network.| 
+| S-1-5-20 | Network Service| An identity that is used by services that have no need for extensive local access but do need authenticated network access. Services running as NetworkService access local resources as ordinary users and access network resources by using the computer's identity. As a result, a service that runs as NetworkService has the same network access as a service that runs as LocalSystem, but it has significantly reduced local access.| 
+| S-1-5-*domain*-500 | Administrator| A user account for the system administrator. Every computer has a local Administrator account and every domain has a domain Administrator account.<br/>The Administrator account is the first account created during operating system installation. The account cannot be deleted, disabled, or locked out, but it can be renamed.<br/>By default, the Administrator account is a member of the Administrators group, and it cannot be removed from that group.| 
+| S-1-5-*domain*-501 | Guest| A user account for people who do not have individual accounts. Every computer has a local Guest account, and every domain has a domain Guest account.<br/>By default, Guest is a member of the Everyone and the Guests groups. The domain Guest account is also a member of the Domain Guests and Domain Users groups.<br/>Unlike Anonymous Logon, Guest is a real account, and it can be used to log on interactively. The Guest account does not require a password, but it can have one.| 
+| S-1-5-*domain*-502| krbtgt| A user account that is used by the Key Distribution Center (KDC) service. The account exists only on domain controllers.| 
+| S-1-5-*domain*-512| Domain Admins| A global group with members that are authorized to administer the domain. By default, the Domain Admins group is a member of the Administrators group on all computers that have joined the domain, including domain controllers.<br/>Domain Admins is the default owner of any object that is created in the domain's Active Directory by any member of the group. If members of the group create other objects, such as files, the default owner is the Administrators group.| 
+| S-1-5-*domain*-513| Domain Users| A global group that includes all users in a domain. When you create a new User object in Active Directory, the user is automatically added to this group.| 
+| S-1-5-*domain*-514| Domain Guests| A global group, which by default, has only one member: the domain's built-in Guest account.| 
+| S-1-5-*domain*-515 | Domain Computers| A global group that includes all computers that have joined the domain, excluding domain controllers.| 
+| S-1-5-*domain*-516| Domain Controllers| A global group that includes all domain controllers in the domain. New domain controllers are added to this group automatically.| 
+| S-1-5-*domain*-517 | Cert Publishers| A global group that includes all computers that host an enterprise certification authority.<br/>Cert Publishers are authorized to publish certificates for User objects in Active Directory.| 
+| S-1-5-*root domain*-518| Schema Admins| A group that exists only in the forest root domain. It is a universal group if the domain is in native mode, and it is a global group if the domain is in mixed mode. The Schema Admins group is authorized to make schema changes in Active Directory. By default, the only member of the group is the Administrator account for the forest root domain.| 
+| S-1-5-*root domain*-519| Enterprise Admins| A group that exists only in the forest root domain. It is a universal group if the domain is in native mode, and it is a global group if the domain is in mixed mode.<br/>The Enterprise Admins group is authorized to make changes to the forest infrastructure, such as adding child domains, configuring sites, authorizing DHCP servers, and installing enterprise certification authorities.<br/>By default, the only member of Enterprise Admins is the Administrator account for the forest root domain. The group is a default member of every Domain Admins group in the forest. |
+| S-1-5-*domain*-520| Group Policy Creator Owners| A global group that is authorized to create new Group Policy Objects in Active Directory. By default, the only member of the group is Administrator.<br/>Objects that are created by members of Group Policy Creator Owners are owned by the individual user who creates them. In this way, the Group Policy Creator Owners group is unlike other administrative groups (such as Administrators and Domain Admins). Objects that are created by members of these groups are owned by the group rather than by the individual.| 
+| S-1-5-*domain*-553| RAS and IAS Servers| A local domain group. By default, this group has no members. Computers that are running the Routing and Remote Access service are added to the group automatically.<br/>Members of this group have access to certain properties of User objects, such as Read Account Restrictions, Read Logon Information, and Read Remote Access Information.| 
+| S-1-5-32-544 | Administrators| A built-in group. After the initial installation of the operating system, the only member of the group is the Administrator account. When a computer joins a domain, the Domain Admins group is added to the Administrators group. When a server becomes a domain controller, the Enterprise Admins group also is added to the Administrators group.| 
+| Users | S-1-5-32-545| A built-in group. After the initial installation of the operating system, the only member is the Authenticated Users group.| 
+| S-1-5-32-546 | Guests| A built-in group. By default, the only member is the Guest account. The Guests group allows occasional or one-time users to log on with limited privileges to a computer's built-in Guest account.| 
+| S-1-5-32-547 | Power Users| A built-in group. By default, the group has no members. Power users can create local users and groups; modify and delete accounts that they have created; and remove users from the Power Users, Users, and Guests groups. Power users also can install programs; create, manage, and delete local printers; and create and delete file shares. |
+| S-1-5-32-548| Account Operators| A built-in group that exists only on domain controllers. By default, the group has no members. By default, Account Operators have permission to create, modify, and delete accounts for users, groups, and computers in all containers and organizational units of Active Directory except the Builtin container and the Domain Controllers OU. Account Operators do not have permission to modify the Administrators and Domain Admins groups, nor do they have permission to modify the accounts for members of those groups.| 
+| S-1-5-32-549| Server Operators| Description: A built-in group that exists only on domain controllers. By default, the group has no members. Server Operators can log on to a server interactively; create and delete network shares; start and stop services; back up and restore files; format the hard disk of the computer; and shut down the computer.| 
+| S-1-5-32-550 | Print Operators| A built-in group that exists only on domain controllers. By default, the only member is the Domain Users group. Print Operators can manage printers and document queues.| 
+| S-1-5-32-551 | Backup Operators| A built-in group. By default, the group has no members. Backup Operators can back up and restore all files on a computer, regardless of the permissions that protect those files. Backup Operators also can log on to the computer and shut it down. 
+| S-1-5-32-552 | Replicators | A built-in group that is used by the File Replication service on domain controllers. By default, the group has no members. Do not add users to this group.|
+| S-1-5-64-10| NTLM Authentication| A SID that is used when the NTLM authentication package authenticated the client| 
+| S-1-5-64-14 | SChannel Authentication| A SID that is used when the SChannel authentication package authenticated the client.| 
+| S-1-5-64-21 | Digest Authentication| A SID that is used when the Digest authentication package authenticated the client.| 
+| S-1-5-80 | NT Service | A SID that is used as an NT Service account prefix.| 
+| S-1-5-80-0 | All Services| A group that includes all service processes that are configured on the system. Membership is controlled by the operating system. SID S-1-5-80-0 equals NT SERVICES\ALL SERVICES. This SID was introduced in Windows Server 2008 R2.| 
+| S-1-5-83-0| NT VIRTUAL MACHINE\Virtual Machines| A built-in group. The group is created when the Hyper-V role is installed. Membership in the group is maintained by the Hyper-V Management Service (VMMS). This group requires the **Create Symbolic Links** right (SeCreateSymbolicLinkPrivilege), and also the **Log on as a Service** right (SeServiceLogonRight). | 
+| S-1-16-0| Untrusted Mandatory Level| A SID that represents an untrusted integrity level.| 
+| S-1-16-4096 | Low Mandatory Level| A SID that represents a low integrity level.| 
+| S-1-16-8192 | Medium Mandatory Level| This SID represents a medium integrity level.| 
+| S-1-16-8448 | Medium Plus Mandatory Level| A SID that represents a medium plus integrity level.| 
+| S-1-16-12288 | High Mandatory Level| A SID that represents a high integrity level.| 
+| S-1-16-16384 | System Mandatory Level| A SID that represents a system integrity level.| 
+| S-1-16-20480 | Protected Process Mandatory Level| A SID that represents a protected-process integrity level.| 
+| S-1-16-28672 | Secure Process Mandatory Level| A SID that represents a secure process integrity level.| 
+
+The following RIDs are relative to each domain.
+
+| RID | Identifies |
+| - | - |
+| DOMAIN_USER_RID_ADMIN | The administrative user account in a domain. |
+| DOMAIN_USER_RID_GUEST| The guest-user account in a domain. Users who do not have an account can automatically sign in to this account.| 
+| DOMAIN_GROUP_RID_USERS | A group that contains all user accounts in a domain. All users are automatically added to this group.| 
+| DOMAIN_GROUP_RID_GUESTS | The group Guest account in a domain.| 
+| DOMAIN_GROUP_RID_COMPUTERS | The Domain Computer group. All computers in the domain are members of this group.| 
+| DOMAIN_GROUP_RID_CONTROLLERS | The Domain Controller group. All domain controllers in the domain are members of this group.| 
+| DOMAIN_GROUP_RID_CERT_ADMINS | The certificate publishers' group. Computers running Active Directory Certificate Services are members of this group.| 
+| DOMAIN_GROUP_RID_SCHEMA_ADMINS | The schema administrators' group. Members of this group can modify the Active Directory schema.| 
+| DOMAIN_GROUP_RID_ENTERPRISE_ADMINS | The enterprise administrators' group. Members of this group have full access to all domains in the Active Directory forest. Enterprise administrators are responsible for forest-level operations such as adding or removing new domains.| 
+| DOMAIN_GROUP_RID_POLICY_ADMINS| The policy administrators' group.| 
+
+The following table provides examples of domain-relative RIDs that are used to form well-known SIDs for local groups.
+
+
+| RID | Identifies |
+| - | - |
+| DOMAIN_ALIAS_RID_ADMINS | Administrators of the domain.| 
+| DOMAIN_ALIAS_RID_USERS | All users in the domain.| 
+| DOMAIN_ALIAS_RID_GUESTS | Guests of the domain.| 
+| DOMAIN_ALIAS_RID_POWER_USERS | A user or a set of users who expect to treat a system as if it were their personal computer rather than as a workstation for multiple users.| 
+| DOMAIN_ALIAS_RID_BACKUP_OPS | A local group that is used to control the assignment of file backup-and-restore user rights.| 
+| DOMAIN_ALIAS_RID_REPLICATOR | A local group that is responsible for copying security databases from the primary domain controller to the backup domain controllers. These accounts are used only by the system.| 
+| DOMAIN_ALIAS_RID_RAS_SERVERS | A local group that represents remote access and servers running Internet Authentication Service (IAS). This group permits access to various attributes of User objects.| 
+
+## Changes in security identifier's functionality
+
+The following table describes changes in SID implementation in the Windows operating systems that are designated in the list.
+
+| Change | Operating system version | Description and resources |
+| - | - | - |
+| Most of the operating system files are owned by the TrustedInstaller security identifier (SID)| Windows Server 2008, Windows Vista| The purpose of this change is to prevent a process that is running as an administrator or under the LocalSystem account from automatically replacing the operating system files. |
+| Restricted SID checks are implemented| Windows Server 2008, Windows Vista| When restricting SIDs are present, Windows performs two access checks. The first is the normal access check, and the second is the same access check against the restricting SIDs in the token. Both access checks must pass to allow the process to access the object. |
+
+## See also
+
+- [Access Control Overview](access-control.md)

windows/keep-secure/security-principals.md

@@ -0,0 +1,147 @@
+---
+title: Security Principals (Windows 10)
+description: Security Principals
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+---
+
+# Security Principals
+
+**Applies to**
+-   Windows 10
+-   Windows Server 2016
+
+This reference topic for the IT professional describes security principals in regards to Windows accounts and security groups, in addition to security technologies that are related to security principals.
+
+## <a href="" id="w2k3tr-princ-what"></a>What are security principals?
+
+
+Security principals are any entity that can be authenticated by the operating system, such as a user account, a computer account, or a thread or process that runs in the security context of a user or computer account, or the security groups for these accounts. Security principals have long been a foundation for controlling access to securable resources on Windows computers. Each security principal is represented in the operating system by a unique security identifier (SID).
+
+The following content applies to the versions of Windows that are designated in the **Applies To** list at the beginning of this topic.
+
+## How security principals work
+
+
+Security principals that are created in an Active Directory domain are Active Directory objects, which can be used to manage access to domain resources. Each security principal is assigned a unique identifier, which it retains for its entire lifetime. Local user accounts and security groups are created on a local computer, and they can be used to manage access to resources on that computer. Local user accounts and security groups are managed by the Security Accounts Manager (SAM) on the local computer.
+
+### <a href="" id="bkmk-authzandac"></a>Authorization and access control components
+
+The following diagram illustrates the Windows authorization and access control process. In this diagram, the subject (a process that is initiated by a user) attempts to access an object, such as a shared folder. The information in the user’s access token is compared to the access control entries (ACEs) in the object’s security descriptor, and the access decision is made. The SIDs of security principals are used in the user’s access token and in the ACEs in the object’s security descriptor.
+
+**Authorization and access control process**
+
+![authorization and access control process](images/authorizationandaccesscontrolprocess.gif)
+
+Security principals are closely related to the following components and technologies:
+
+-   [Security identifiers](#bkmk-sids)
+
+-   [Access tokens](#bkmk-accesstokens)
+
+-   [Security descriptors and access control lists](#bkmk-sdandacls)
+
+-   [Permissions](#bkmk-permissions)
+
+### <a href="" id="bkmk-sids"></a>Security identifiers
+
+Security identifiers (SIDs) provide a fundamental building block of the Windows security model. They work with specific components of the authorization and access control technologies in the security infrastructure of the Windows Server operating systems. This helps protect access to network resources and provides a more secure computing environment.
+
+A SID is a value of variable length that is used to uniquely identify a security principal that represents any entity that can be authenticated by the system. These entities include a user account, a computer account, or a thread or process that runs in the security context of a user or computer account. Each security principal is automatically assigned a SID when it is created. The SID is stored in a security database. When a SID is used as the unique identifier for a user or group, it can never be used to identify another user or group.
+
+Each time a user signs in, the system creates an access token for that user. The access token contains the user’s SID, user rights, and the SIDs for groups that the user belongs to. This token provides the security context for whatever actions the user performs on that computer.
+
+In addition to the uniquely created, domain-specific SIDs that are assigned to specific users and groups, there are well-known SIDs that identify generic groups and generic users. For example, the Everyone and the World SIDs identify groups that includes all users. Well-known SIDs have values that remain constant across all operating systems.
+
+### <a href="" id="bkmk-accesstokens"></a>Access tokens
+
+An access token is a protected object that contains information about the identity and user rights that are associated with a user account.
+
+When a user signs in interactively or tries to make a network connection to a computer running Windows, the sign-in process authenticates the user’s credentials. If authentication is successful, the process returns a SID for the user and a list of SIDs for the user’s security groups. The Local Security Authority (LSA) on the computer uses this information to create an access token (in this case, the primary access token). This includes the SIDs that are returned by the sign-in process and a list of user rights that are assigned by the local security policy to the user and to the user’s security groups.
+
+After the LSA creates the primary access token, a copy of the access token is attached to every thread and process that executes on the user’s behalf. Whenever a thread or process interacts with a securable object or tries to perform a system task that requires user rights, the operating system checks the access token that is associated with the thread to determine the level of authorization.
+
+There are two kinds of access tokens, primary and impersonation. Every process has a primary token that describes the security context of the user account that is associated with the process. A primary access token is typically assigned to a process to represent the default security information for that process. Impersonation tokens, on the other hand, are usually used for client and server scenarios. Impersonation tokens enable a thread to run in a security context that differs from the security context of the process that owns the thread.
+
+### <a href="" id="bkmk-sdandacls"></a>Security descriptors and access control lists
+
+A security descriptor is a data structure that is associated with each securable object. All objects in Active Directory and all securable objects on a local computer or on the network have security descriptors to help control access to the objects. Security descriptors include information about who owns an object, who can access it and in what way, and what types of access are audited. Security descriptors contain the access control list (ACL) of an object, which includes all of the security permissions that apply to that object. An object’s security descriptor can contain two types of ACLs:
+
+-   A discretionary access control list (DACL), which identifies the users and groups who are allowed or denied access
+
+-   A system access control list (SACL), which controls how access is audited
+
+You can use this access control model to individually secure objects and attributes such as files and folders, Active Directory objects, registry keys, printers, devices, ports, services, processes, and threads. Because of this individual control, you can adjust the security of objects to meet the needs of your organization, delegate authority over objects or attributes, and create custom objects or attributes that require unique security protections to be defined.
+
+### <a href="" id="bkmk-permissions"></a>Permissions
+
+Permissions enable the owner of each securable object, such as a file, Active Directory object, or registry key, to control who can perform an operation or a set of operations on the object or object property. Permissions are expressed in the security architecture as access control entries (ACEs). Because access to an object is at the discretion of the object’s owner, the type of access control that is used in Windows is called discretionary access control.
+
+Permissions are different from user rights in that permissions are attached to objects, and user rights apply to user accounts. Administrators can assign user rights to groups or users. These rights authorize users to perform specific actions, such as signing in to a system interactively or backing up files and directories.
+
+On computers, user rights enable administrators to control who has the authority to perform operations that affect an entire computer, rather than a particular object. Administrators assign user rights to individual users or groups as part of the security settings for the computer. Although user rights can be managed centrally through Group Policy, they are applied locally. Users can (and usually do) have different user rights on different computers.
+
+For information about which user rights are available and how they can be implemented, see [User Rights Assignment](user-rights-assignment.md).
+
+### <a href="" id="bkmk-authn"></a> Security context in authentication
+
+A user account enables a user to sign in to computers, networks, and domains with an identity that can be authenticated by the computer, network, or domain.
+
+In Windows, any user, service, group, or computer that can initiate action is a security principal. Security principals have accounts, which can be local to a computer or domain-based. For example, domain-joined Windows client computers can participate in a network domain by communicating with a domain controller, even when no user is signed in.
+
+To initiate communications, the computer must have an active account in the domain. Before accepting communications from the computer, the Local Security Authority on the domain controller authenticates the computer’s identity and then defines the computer’s security context just as it would for a user’s security principal.
+
+This security context defines the identity and capabilities of a user or service on a particular computer, or of a user, service, group or computer on a network. For example, it defines the resources (such as a file share or printer) that can be accessed and the actions (such as Read, Write, or Modify) that can be performed by a user, service, or computer on that resource.
+
+The security context of a user or computer can vary from one computer to another, such as when a user authenticates to a server or a workstation other than the user’s primary workstation. It can also vary from one session to another, such as when an administrator modifies the user’s rights and permissions. In addition, the security context is usually different when a user or computer is operating on a stand-alone basis, in a mixed network domain, or as part of an Active Directory domain.
+
+## <a href="" id="w2k3tr-princ-what-vblj"></a>Accounts and security groups
+
+
+Accounts and security groups that are created in an Active Directory domain are stored in the Active Directory database and managed by using Active Directory tools. These security principals are directory objects, and they can be used to manage access to domain resources.
+
+Local user accounts and security groups are created on a local computer, and they can be used to manage access to resources on that computer. Local user accounts and security groups are stored in and managed by the Security Accounts Manager (SAM) on the local computer.
+
+### User accounts
+
+A user account uniquely identifies a person who is using a computer system. The account signals the system to enforce the appropriate authorization to allow or deny that user access to resources. User accounts can be created in Active Directory and on local computers, and administrators use them to:
+
+-   Represent, identify, and authenticate the identity of a user. A user account enables a user to sign in to computers, networks, and domains with a unique identifier that can be authenticated by the computer, network, or domain.
+
+-   Authorize (grant or deny) access to resources. After a user has been authenticated, the user is authorized access to resources based on the permissions that are assigned to that user for the resource.
+
+-   Audit the actions that are carried out on a user account.
+
+Windows and the Windows Server operating systems have built-in user accounts, or you can create user accounts to meet the requirements of your organization.
+
+### Security groups
+
+A security group is a collection of user accounts, computer accounts, and other groups of accounts that can be managed as a single unit from a security perspective. In Windows operating systems, there are several built-in security groups that are preconfigured with the appropriate rights and permissions for performing specific tasks. Additionally, you can (and, typically, will) create a security group for each unique combination of security requirements that applies to multiple users in your organization.
+
+Groups can be Active Directory-based or local to a particular computer:
+
+-   Active Directory security groups are used to manage rights and permissions to domain resources.
+
+-   Local groups exist in the SAM database on local computers (on all Windows-based computers) except domain controllers. You use local groups to manage rights and permissions only to resources on the local computer.
+
+By using security groups to manage access control, you can:
+
+-   Simplify administration. You can assign a common set of rights, a common set of permissions, or both to many accounts at one time, rather than assigning them to each account individually. Also, when users transfer jobs or leave the organization, permissions are not tied to their user accounts, making permission reassignment or removal easier.
+
+-   Implement a role-based access-control model. You can use this model to grant permissions by using groups with different scopes for appropriate purposes. Scopes that are available in Windows include local, global, domain local, and universal.
+
+-   Minimize the size of access control lists (ACLs) and speed security checking. A security group has its own SID; therefore, the group SID can be used to specify permissions for a resource. In an environment with more than a few thousand users, if the SIDs of individual user accounts are used to specify access to a resource, the ACL of that resource can become unmanageably large, and the time that is needed for the system to check permissions to the resource can become unacceptable.
+
+For descriptions and settings information about the domain security groups that are defined in Active Directory, see [Active Directory Security Groups](active-directory-security-groups.md).
+
+For descriptions and settings information about the Special Identities group, see [Special Identities](special-identities.md).
+
+ 
+
+ 
+
+
+
+

windows/keep-secure/security-technologies.md

@@ -15,6 +15,7 @@ Learn more about the different security technologies that are available in Windo
 
 | Topic | Description |
 |-|-|
+| [Access control](access-control.md) | Describes access control in Windows, which is the process of authorizing users, groups, and computers to access objects on the network or computer. Key concepts that make up access control are permissions, ownership of objects, inheritance of permissions, user rights, and object auditing. |
 | [AppLocker](applocker-overview.md)| This topic provides a description of AppLocker and can help you decide if your organization can benefit from deploying AppLocker application control policies. AppLocker helps you control which apps and files users can run. These include executable files, scripts, Windows Installer files, dynamic-link libraries (DLLs), packaged apps, and packaged app installers.|
 | [BitLocker](bitlocker-overview.md)| This topic provides a high-level overview of BitLocker, including a list of system requirements, practical applications, and deprecated features.|
 | [Encrypted Hard Drive](encrypted-hard-drive.md) | Encrypted Hard Drive uses the rapid encryption that is provided by BitLocker Drive Encryption to enhance data security and management.|

windows/keep-secure/service-accounts.md

@@ -0,0 +1,156 @@
+---
+title: Service Accounts (Windows 10)
+description: Service Accounts
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+---
+
+# Service Accounts
+
+**Applies to**
+-   Windows 10
+-   Windows Server 2016
+
+This topic for the IT professional explains group and standalone managed service accounts, and the computer-specific virtual computer account, and it points to resources about these service accounts.
+
+## Overview
+
+
+A service account is a user account that is created explicitly to provide a security context for services running on Windows Server operating systems. The security context determines the service's ability to access local and network resources. The Windows operating systems rely on services to run various features. These services can be configured through the applications, the Services snap-in, or Task Manager, or by using Windows PowerShell.
+
+This topic contains information about the following types of service accounts:
+
+-   [Standalone managed service accounts](#bkmk-standalonemanagedserviceaccounts)
+
+-   [Group managed service accounts](#bkmk-groupmanagedserviceaccounts)
+
+-   [Virtual accounts](#bkmk-virtualserviceaccounts)
+
+### <a href="" id="bkmk-standalonemanagedserviceaccounts"></a>Standalone managed service accounts
+
+A managed service account is designed to isolate domain accounts in crucial applications, such as Internet Information Services (IIS), and eliminate the need for an administrator to manually administer the service principal name (SPN) and credentials for the accounts.
+
+To use managed service accounts, the server on which the application or service is installed must be running at least Windows Server 2008 R2. One managed service account can be used for services on a single computer. Managed service accounts cannot be shared between multiple computers, and they cannot be used in server clusters where a service is replicated on multiple cluster nodes. For this scenario, you must use a group managed service account. For more information, see [Group Managed Service Accounts Overview](https://technet.microsoft.com/library/hh831782(v=ws.11).aspx).
+
+In addition to the enhanced security that is provided by having individual accounts for critical services, there are four important administrative benefits associated with managed service accounts:
+
+-   You can create a class of domain accounts that can be used to manage and maintain services on local computers.
+
+-   Unlike domain accounts in which administrators must reset manually passwords, the network passwords for these accounts are automatically reset.
+
+-   You do not have to complete complex SPN management tasks to use managed service accounts.
+
+-   Administrative tasks for managed service accounts can be delegated to non-administrators.
+
+### Software requirements
+
+Managed service accounts apply to the Windows operating systems that are designated in the **Applies To** list at the beginning of this topic.
+
+### <a href="" id="bkmk-groupmanagedserviceaccounts"></a>Group managed service accounts
+
+Group managed service accounts are an extension of the standalone managed service accounts, which were introduced in Windows Server 2008 R2. These are managed domain accounts that provide automatic password management and simplified service principal name (SPN) management, including delegation of management to other administrators.
+
+The group managed service account provides the same functionality as a standalone managed service account within the domain, but it extends that functionality over multiple servers. When connecting to a service that is hosted on a server farm, such as Network Load Balancing, the authentication protocols that support mutual authentication require all instances of the services to use the same principal. When group managed service accounts are used as service principals, the Windows Server operating system manages the password for the account instead of relying on the administrator to manage the password.
+
+The Microsoft Key Distribution Service (kdssvc.dll) provides the mechanism to securely obtain the latest key or a specific key with a key identifier for an Active Directory account. This service was introduced in Windows Server 2012, and it does not run on previous versions of the Windows Server operating system. The Key Distribution Service shares a secret, which is used to create keys for the account. These keys are periodically changed. For a group managed service account, the domain controller computes the password on the key that is provided by the Key Distribution Services, in addition to other attributes of the group managed service account.
+
+### <a href="" id="bkmk-app"></a>Practical applications
+
+Group managed service accounts provide a single identity solution for services running on a server farm, or on systems that use Network Load Balancing. By providing a group managed service account solution, services can be configured for the group managed service account principal, and the password management is handled by the operating system.
+
+By using a group managed service account, services or service administrators do not need to manage password synchronization between service instances. The group managed service account supports hosts that are kept offline for an extended time period and the management of member hosts for all instances of a service. This means that you can deploy a server farm that supports a single identity to which existing client computers can authenticate without knowing the instance of the service to which they are connecting.
+
+Failover clusters do not support group managed service account s. However, services that run on top of the Cluster service can use a group managed service account or a standalone managed service account if they are a Windows service, an App pool, a scheduled task, or if they natively support group managed service account or standalone managed service accounts.
+
+### <a href="" id="bkmk-soft"></a>Software requirements
+
+Group managed service accounts can only be configured and administered on computers running at least Windows Server 2012, but they can be deployed as a single service identity solution in domains that still have domain controllers running operating systems earlier than Windows Server 2012. There are no domain or forest functional level requirements.
+
+A 64-bit architecture is required to run the Windows PowerShell commands that are used to administer group managed service accounts.
+
+A managed service account is dependent on encryption types supported by Kerberos. When a client computer authenticates to a server by using Kerberos protocol, the domain controller creates a Kerberos service ticket that is protected with encryption that the domain controller and the server support. The domain controller uses the account’s **msDS-SupportedEncryptionTypes** attribute to determine what encryption the server supports, and if there is no attribute, it assumes that the client computer does not support stronger encryption types. The Advanced Encryption Standard (AES) should always be explicitly configured for managed service accounts. If computers that host the managed service account are configured to not support RC4, authentication will always fail.
+
+**Note**  
+Introduced in Windows Server 2008 R2, the Data Encryption Standard (DES) is disabled by default. For more information about supported encryption types, see [Changes in Kerberos Authentication](http://technet.microsoft.com/library/dd560670(WS.10).aspx).
+
+ 
+
+Group managed service accounts are not applicable in Windows operating systems prior to Windows Server 2012.
+
+### <a href="" id="bkmk-virtualserviceaccounts"></a>Virtual accounts
+
+Virtual accounts were introduced in Windows Server 2008 R2 and Windows 7, and are managed local accounts that provide the following features to simplify service administration:
+
+-   The virtual account is automatically managed.
+
+-   The virtual account can access the network in a domain environment.
+
+-   No password management is required. For example, if the default value is used for the service accounts during SQL Server setup on Windows Server 2008 R2, a virtual account that uses the instance name as the service name is established in the format NT SERVICE\\&lt;SERVICENAME&gt;.
+
+Services that run as virtual accounts access network resources by using the credentials of the computer account in the format &lt;domain\_name&gt;\\&lt;computer\_name&gt;$.
+
+For information about how to configure and use virtual service accounts, see [Service Accounts Step-by-Step Guide](http://technet.microsoft.com/library/dd548356.aspx).
+
+### Software requirements
+
+Virtual accounts apply to the Windows operating systems that are designated in the **Applies To** list at the beginning of this topic.
+
+## <a href="" id="bkmk-links"></a>See also
+
+
+The following table provides links to additional resources that are related to standalone managed service accounts, group managed service accounts, and virtual accounts.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Content type</th>
+<th>References</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p><strong>Product evaluation</strong></p></td>
+<td><p>[What's New for Managed Service Accounts](https://technet.microsoft.com/library/hh831451(v=ws.11).aspx)</p>
+<p>[Managed Service Accounts Documentation for Windows 7 and Windows Server 2008 R2](http://technet.microsoft.com/library/ff641731.aspx)</p>
+<p>[Service Accounts Step-by-Step Guide](http://technet.microsoft.com/library/dd548356.aspx)</p>
+<p>[Getting Started with Group Managed Service Accounts](https://technet.microsoft.com/library/jj128431(v=ws.11).aspx)</p></td>
+</tr>
+<tr class="even">
+<td><p><strong>Deployment</strong></p></td>
+<td><p>[Windows Server 2012: Group Managed Service Accounts - Ask Premier Field Engineering (PFE) Platforms - Site Home - TechNet Blogs](http://blogs.technet.com/b/askpfeplat/archive/2012/12/17/windows-server-2012-group-managed-service-accounts.aspx)</p></td>
+</tr>
+<tr class="odd">
+<td><p><strong>Operations</strong></p></td>
+<td><p>[Managed Service Accounts in Active Directory](http://technet.microsoft.com/library/dd378925.aspx)</p></td>
+</tr>
+<tr class="even">
+<td><p><strong>Tools and settings</strong></p></td>
+<td><p>[Managed Service Accounts in Active Directory Domain Services](http://technet.microsoft.com/library/dd378925.aspx)</p></td>
+</tr>
+<tr class="odd">
+<td><p><strong>Community resources</strong></p></td>
+<td><p>[Managed Service Accounts: Understanding, Implementing, Best Practices, and Troubleshooting](http://blogs.technet.com/b/askds/archive/2009/09/10/managed-service-accounts-understanding-implementing-best-practices-and-troubleshooting.aspx)</p></td>
+</tr>
+<tr class="even">
+<td><p><strong>Related technologies</strong></p></td>
+<td><p>[Security Principals Technical Overview](security-principals.md)</p>
+<p>[What's new in Active Directory Domain Services](https://technet.microsoft.com/library/mt163897.aspx)</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+ 
+
+ 
+
+
+
+