deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-21 21:33:38 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Merged PR 14618: MTE updates

Browse Source
This commit is contained in:
DulceMV
2019-03-04 18:44:17 +00:00
parent e22ac405be d88c26d4c7
commit 860a5fc479
45 changed files with 578 additions and 280 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
windows/client-management/mdm/oma-dm-protocol-support.md
View File

@ -13,7 +13,7 @@ ms.date: 06/26/2017
# OMA DM protocol support
The OMA DM client communicates with the server over HTTPS and uses DM Sync (OMA DM v1.2) as the message payload. This topic describes the OMA DM functionality that the DM client supports in general. The full description of the OMA DM protocol v1.2 can be found at the [OMA website](https://go.microsoft.com/fwlink/p/?LinkId=267526).
The OMA DM client communicates with the server over HTTPS and uses DM Sync (OMA DM v1.2) as the message payload. This topic describes the OMA DM functionality that the DM client supports in general. The full description of the OMA DM protocol v1.2 can be found at the [OMA website](https://www.openmobilealliance.org/release/DM/V1_2-20070209-A/OMA-TS-DM_Protocol-V1_2-20070209-A.pdf).
## In this topic
@ -62,7 +62,7 @@ The following table shows the OMA DM standards that Windows uses.
</tr>
<tr class="odd">
<td style="vertical-align:top"><p>DM protocol commands</p></td>
<td style="vertical-align:top"><p>The following list shows the commands that are used by the device. For further information about the OMA DM command elements, see &quot;SyncML Representation Protocol Device Management Usage (OMA-SyncML-DMRepPro-V1_1_2-20030613-A)&quot; available from the [OMA website](https://go.microsoft.com/fwlink/p/?LinkId=267526).</p>
<td style="vertical-align:top"><p>The following list shows the commands that are used by the device. For further information about the OMA DM command elements, see &quot;SyncML Representation Protocol Device Management Usage (OMA-SyncML-DMRepPro-V1_1_2-20030613-A)&quot; available from the [OMA website](https://www.openmobilealliance.org/release/DM/V1_1_2-20031209-A/).</p>
<ul>
<li><p>Add (Implicit Add supported)</p></li>
<li><p>Alert (DM alert): Generic alert (1226) is used by enterprise management client when the user triggers an MDM unenrollment action from the device or when a CSP finishes some asynchronous actions. Device alert (1224) is used to notify the server some device triggered event.</p></li>
@ -146,7 +146,7 @@ The following table shows the OMA DM standards that Windows uses.
<a href="" id="protocol-common-elements"></a>
## OMA DM protocol common elements
Common elements are used by other OMA DM element types. The following table lists the OMA DM common elements used to configure the devices. For more information about OMA DM common elements, see "SyncML Representation Protocol Device Management Usage" (OMA-SyncML-DMRepPro-V1\_1\_2-20030613-A) available from the [OMA website](https://go.microsoft.com/fwlink/p/?LinkId=526900).
Common elements are used by other OMA DM element types. The following table lists the OMA DM common elements used to configure the devices. For more information about OMA DM common elements, see "SyncML Representation Protocol Device Management Usage" (OMA-SyncML-DMRepPro-V1_1_2-20030613-A) available from the [OMA website](https://www.openmobilealliance.org/release/DM/V1_1_2-20031209-A/).
<table>
<colgroup>
@ -301,15 +301,15 @@ The following table shows the sequence of events during a typical DM session.
</tbody>
</table>
 
The step numbers in the table do not represent message identification numbers (MsgID). All messages from the server must have a MsgID that is unique within the session, starting at 1 for the first message, and increasing by an increment of 1 for each additional message. For more information about MsgID and OMA SyncML protocol, see "OMA Device Management Representation Protocol" (OMA-TS-DM\_RepPro-V1\_2-20070209-A) available from the [OMA website](https://go.microsoft.com/fwlink/p/?LinkId=526900).
The step numbers in the table do not represent message identification numbers (MsgID). All messages from the server must have a MsgID that is unique within the session, starting at 1 for the first message, and increasing by an increment of 1 for each additional message. For more information about MsgID and OMA SyncML protocol, see "OMA Device Management Representation Protocol" (DM_RepPro-V1_2-20070209-A) available from the [OMA website](https://www.openmobilealliance.org/release/DM/V1_2-20070209-A/).
During OMA DM application level mutual authentication, if the device response code to Cred element in the server request is 212, no further authentication is needed for the remainder of the DM session. In the case of the MD5 authentication, the Chal element can be returned. Then the next nonce in Chal must be used for the MD5 digest when the next DM session is started.
If a request includes credentials and the response code to the request is 200, the same credential must be sent within the next request. If the Chal element is included and the MD5 authentication is required, a new digest is created by using the next nonce via the Chal element for next request.
For more information about Basic or MD5 client authentication, MD5 server authentication, MD5 hash, and MD5 nonce, see the OMA Device Management Security specification (OMA-TS-DM\_Security-V1\_2\_1-20080617-A), authentication response code handling and step-by-step samples in OMA Device Management Protocol specification (OMA-TS-DM\_Protocol-V1\_2\_1-20080617-A), available from the [OMA website](https://go.microsoft.com/fwlink/p/?LinkId=526900).
For more information about Basic or MD5 client authentication, MD5 server authentication, MD5 hash, and MD5 nonce, see the OMA Device Management Security specification (OMA-TS-DM_Security-V1_2_1-20080617-A), authentication response code handling and step-by-step samples in OMA Device Management Protocol specification (OMA-TS-DM_Protocol-V1_2_1-20080617-A), available from the [OMA website](https://www.openmobilealliance.org/release/DM/V1_2_1-20080617-A/).
## User targeted vs. Device targeted configuration

5
windows/client-management/mdm/policy-csp-devicelock.md
View File

@ -724,7 +724,10 @@ The following list shows the supported values:
<!--/Scope-->
<!--Description-->
Specifies the maximum amount of time (in minutes) allowed after the device is idle that will cause the device to become PIN or password locked. Users can select any existing timeout value less than the specified maximum time in the Settings app. Note the Lumia 950 and 950XL have a maximum timeout value of 5 minutes, regardless of the value set by this policy.
Specifies the maximum amount of time (in minutes) allowed after the device is idle that will cause the device to become PIN or password locked. Users can select any existing timeout value less than the specified maximum time in the Settings app.
* On Mobile, the Lumia 950 and 950XL have a maximum timeout value of 5 minutes, regardless of the value set by this policy.
* On HoloLens, this timeout is controlled by the device's system sleep timeout, regardless of the value set by this policy.
> [!NOTE]
> This policy must be wrapped in an Atomic command.

5
windows/client-management/mdm/uefi-csp.md
View File

@ -17,6 +17,9 @@ The UEFI configuration service provider (CSP) interfaces to UEFI's Device Firmwa
> [!Note]
> The UEFI CSP version published in Windows 10, version 1803 is replaced with this one (version 1809).
> [!Note]
> The production UEFI CSP is present in 1809, but it depends upon the Device Firmware Configuration Interface (DFCI) and UEFI firmware to comply with this interface. The specification for this interface and compatible firmware is not yet available.
The following diagram shows the UEFI CSP in tree format.
![Uefi CSP diagram](images/provisioning-csp-uefi.png)
@ -124,4 +127,4 @@ Value type is Base64. Supported operation is Replace.
<a href="" id="settings2-result"></a>**Settings2/Result**
Retrieves the binary result package of previous Settings2/Apply operation. This binary package contains XML describing the action taken for each individual setting.
Supported operation is Get.
Supported operation is Get.

2
windows/client-management/mdm/vpnv2-csp.md
View File

@ -448,6 +448,8 @@ Required for native profiles. Type of tunneling protocol used. This value can be
Value type is chr. Supported operations include Get, Add, Replace, and Delete.
> **Note** The **Automatic** option means that the device will try each of the built-in tunneling protocols until one succeeds. It will attempt protocols in following order: IKEv2, PPTP and then L2TP. This order is not customizable.
<a href="" id="vpnv2-profilename-nativeprofile-authentication"></a>**VPNv2/***ProfileName***/NativeProfile/Authentication**
Required node for native profile. It contains authentication information for the native VPN profile.

1
windows/configuration/kiosk-prepare.md
View File

@ -44,6 +44,7 @@ Disable the camera. | Go to **Settings** &gt; **Privacy** &gt; **Camera**, a
Turn off app notifications on the lock screen. | Go to **Group Policy Editor** &gt; **Computer Configuration** &gt; **Administrative Templates\\System\\Logon\\Turn off app notifications on the lock screen**.
Disable removable media. | Go to **Group Policy Editor** &gt; **Computer Configuration** &gt; **Administrative Templates\\System\\Device Installation\\Device Installation Restrictions**. Review the policy settings available in **Device Installation Restrictions** for the settings applicable to your situation.</br></br>**NOTE**: To prevent this policy from affecting a member of the Administrators group, in **Device Installation Restrictions**, enable **Allow administrators to override Device Installation Restriction policies**.
## Enable logging
Logs can help you [troubleshoot issues](multi-app-kiosk-troubleshoot.md) kiosk issues. Logs about configuration and runtime issues can be obtained by enabling the **Applications and Services Logs\Microsoft\Windows\AssignedAccess\Operational** channel, which is disabled by default.

27
windows/configuration/start-layout-troubleshoot.md
View File

@ -300,6 +300,33 @@ C:\Windows\System32\tdlrecover.exe -reregister -resetlayout -resetcache
Although a reboot is not required, it may help clear up any residual issues after the command is run.
### Symptoms: Start Menu and Apps cannot start after upgrade to Windows 10 version 1809 when Symantec Endpoint Protection is installed
**Description** Start Menu, Search and Apps do not start after you upgrade a Windows 7-based computer that has Symantec Endpoint Protection installed to Windows 10 version 1809.
**Cause** This occurs because of a failure to load sysfer.dll. During upgrade, the setup process does not set the privilege group "All Application Packages" on sysfer.dll and other Symantec modules.
**Resolution** This issue was fixed by the Windows Cumulative Update that were released on December 5, 2018—KB4469342 (OS Build 17763.168).
If you have already encountered this issue, use one of the following two options to fix the issue:
**Option 1** Remove sysfer.dll from system32 folder and copy it back. Windows will set privilege automatically.
**Option 2**
1. Locate the directory C:\Windows\system32.
2. Right-click on sysfer.dll and choose **Properties**.
3. Switch to the **Security** tab.
4. Confirm that **All Application Packages** group is missing.
5. Click **Edit**, and then click **Add** to add the group.
6. Test Start and other Apps.

2
windows/configuration/ue-v/uev-getting-started.md
View File

@ -110,7 +110,7 @@ With Windows 10, version 1607 and later, the UE-V service is installed on user d
2. Navigate to **Computer Configuration** &gt; **Administrative Templates** &gt; **Windows Components** &gt; **Microsoft** **User Experience Virtualization**.
3. Double click **Use Users Experience Virtualization (UE-V)**.
3. Double click **Use User Experience Virtualization (UE-V)**.
4. Select **Enabled** and click **OK**.

4
windows/deployment/update/how-windows-update-works.md
View File

@ -19,7 +19,7 @@ The Windows Update workflow has four core areas of functionality:
### Scan
1. Orchestrator schedules the scan.
2. Orchestrator vertifies admin approvals and policies for download.
2. Orchestrator verifies admin approvals and policies for download.
### Download
@ -139,4 +139,4 @@ The action list describes all the files needed from WU, and what the install age
When the option to automatically install updates is configured, the Windows Update Orchestrator, in most cases, automatically restarts the PC for you after installing the updates. This is necessary because your PC may be insecure, or not fully updated, until a restart is completed. You can use Group Policy settings, mobile device management (MDM), or the registry (not recommended) to configure when devices will restart after a Windows 10 update is installed.
For more information see [Manage device restarts after updates](waas-restart.md).
For more information see [Manage device restarts after updates](waas-restart.md).

12
windows/deployment/upgrade/windows-10-upgrade-paths.md
View File

@ -42,7 +42,6 @@ D = Edition downgrade; personal data is maintained, applications and settings ar
<td>Windows 10 Pro Education</td>
<td>Windows 10 Education</td>
<td>Windows 10 Enterprise</td>
<td>Windows 10 Enterprise LTSC</td>
<td>Windows 10 Mobile</td>
<td>Windows 10 Mobile Enterprise</td>
</tr>
@ -264,17 +263,6 @@ D = Edition downgrade; personal data is maintained, applications and settings ar
<td></td>
<td></td>
</tr>
<tr>
<td>Enterprise LTSC</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>✔</td>
<td>✔</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Mobile</td>
<td></td>

6
windows/deployment/windows-10-enterprise-e3-overview.md
View File

@ -15,7 +15,7 @@ author: greg-lindsay
Windows 10 Enterprise E3 launched in the Cloud Solution Provider (CSP) channel on September 1, 2016. Windows 10 Enterprise E3 in CSP is a new offering that delivers, by subscription, exclusive features reserved for Windows 10 Enterprise edition. This offering is available through the Cloud Solution Provider (CSP) channel via the Partner Center as an online service. Windows 10 Enterprise E3 in CSP provides a flexible, per-user subscription for small- and medium-sized organizations (from one to hundreds of users). To take advantage of this offering, you must have the following:
- Windows 10 Pro, version 1607 (also known as Windows 10 Anniversary Update) or later installed on the devices to be upgraded
- Windows 10 Pro, version 1607 (Windows 10 Anniversary Update) or later, installed and activated, on the devices to be upgraded
- Azure Active Directory (Azure AD) available for identity management
Starting with Windows 10, version 1607 (Windows 10 Anniversary Update), you can move from Windows 10 Pro to Windows 10 Enterprise more easily than ever before—no keys and no reboots. After one of your users enters the Azure AD credentials associated with a Windows 10 Enterprise E3 license, the operating system turns from Windows 10 Pro to Windows 10 Enterprise and all the appropriate Windows 10 Enterprise features are unlocked. When a subscription license expires or is transferred to another user, the Windows 10 Enterprise device seamlessly steps back down to Windows 10 Pro.
@ -249,5 +249,5 @@ The Managed User Experience feature is a set of Windows 10 Enterprise edition f
[Windows 10 Enterprise Subscription Activation](windows-10-enterprise-subscription-activation.md)
<BR>[Connect domain-joined devices to Azure AD for Windows 10 experiences](https://azure.microsoft.com/documentation/articles/active-directory-azureadjoin-devices-group-policy/)
<BR>[Compare Windows 10 editions](https://www.microsoft.com/en-us/WindowsForBusiness/Compare)
<BR>[Windows for business](https://www.microsoft.com/en-us/windowsforbusiness/default.aspx)
<BR>[Compare Windows 10 editions](https://www.microsoft.com/WindowsForBusiness/Compare)
<BR>[Windows for business](https://www.microsoft.com/windowsforbusiness/default.aspx)

141
windows/security/identity-protection/access-control/local-accounts.md
View File

@ -12,16 +12,17 @@ manager: dansimp
ms.collection: M365-identity-device-management
ms.topic: article
ms.localizationpriority: medium
ms.date: 12/10/2018
ms.date: 02/28/2019
---
# Local Accounts
**Applies to**
- Windows 10
- Windows Server 2019
- 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.
This reference topic for IT professionals describes the default local user accounts for servers, including how to manage these built-in accounts on a member or standalone server.
## <a href="" id="about-local-user-accounts-"></a>About local user accounts
@ -37,6 +38,8 @@ This topic describes the following:
- [HelpAssistant account (installed by using a Remote Assistance session)](#sec-helpassistant)
- [DefaultAccount](#defaultaccount)
- [Default local system accounts](#sec-localsystem)
- [How to manage local accounts](#sec-manage-accounts)
@ -53,42 +56,29 @@ For information about security principals, see [Security Principals](security-pr
## <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 Windows.
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.
After Windows 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.
Default local user accounts are 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.
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 Windows installation.
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 Administrator account has full control of the files, directories, services, and other resources on the local computer. The Administrator account can create other local users, assign user rights, and assign permissions. The Administrator account can 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**.
In Windows 10 and Windows Server 20016, Windows setup disables the built-in Administrator account and creates another local account that is a member of the Administrators group. Members of the Administrators groups can run apps with elevated permissions without using the **Run as Administrator** option. Fast User Switching is more secure than using Runas or different-user elevation.
**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.
The Administrator account cannot be deleted or removed from the Administrators group, but it can be renamed.
**Security considerations**
@ -122,53 +112,78 @@ By default, the Guest account is the only member of the default Guests group (SI
**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](/windows/device-security/security-policy-settings/shut-down-the-system) user right.
When enabling the Guest account, only grant limited rights and permissions. For security reasons, the Guest account should not be used over the network and made accessible to other computers.
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.
### DefaultAccount
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 DefaultAccount, also known as the Default System Managed Account (DSMA), is a built-in account introduced in Windows 10 version 1607 and Windows Server 2016.
The DMSA is a well-known user account type.
It is a user neutral account that can be used to run processes that are either multi-user aware or user-agnostic.
The DMSA is disabled by default on the desktop SKUs (full windows SKUs) and WS 2016 with the Desktop.
The security identifiers (SIDs) that pertain to the default HelpAssistant account include:
The DMSA has a well-known RID of 503. The security identifier (SID) of the DMSA will thus have a well-known SID in the following format: S-1-5-21-<ComputerIdentifier>-503
- 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.
The DMSA is a member of the well-known group **System Managed Accounts Group**, which has a well-known SID of S-1-5-32-581.
- 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.
The DMSA alias can be granted access to resources during offline staging even before the account itself has been created. The account and the group are created during first boot of the machine within the Security Accounts Manager (SAM).
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.
#### How Windows uses the DefaultAccount
From a permission perspective, the DefaultAccount is a standard user account.
The DefaultAccount is needed to run multi-user-manifested-apps (MUMA apps).
MUMA apps run all the time and react to users signing in and signing out of the devices.
Unlike Windows Desktop where apps run in context of the user and get terminated when the user signs off, MUMA apps run by using the DSMA.
In comparison, for the Windows client operating system, the HelpAssistant account is enabled on installation by default.
MUMA apps are functional in shared session SKUs such as Xbox. For example, Xbox shell is a MUMA app.
Today, Xbox automatically signs in as Guest account and all apps run in this context.
All the apps are multi-user-aware and respond to events fired by user manager.
The apps run as the Guest account.
Similarly, Phone auto logs in as a “DefApps” account which is akin to the standard user account in Windows but with a few extra privileges. Brokers, some services and apps run as this account.
In the converged user model, the multi-user-aware apps and multi-user-aware brokers will need to run in a context different from that of the users.
For this purpose, the system creates DSMA.
#### How the DefaultAccount gets created on domain controllers
If the domain was created with domain controllers that run Windows Server 2016, the DefaultAccount will exist on all domain controllers in the domain.
If the domain was created with domain controllers that run an earlier version of Windows Server, the DefaultAccount will be created after the PDC Emulator role is transferred to a domain controller that runs Windows Server 2016. The DefaultAccount will then be replicated to all other domain controllers in the domain.
#### Recommendations for managing the Default Account (DSMA)
Microsoft does not recommend changing the default configuration, where the account is disabled. There is no security risk with having the account in the disabled state. Changing the default configuration could hinder future scenarios that rely on this account.
## <a href="" id="sec-localsystem"></a>Default local system accounts
### SYSTEM
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, and Windows manages the SYSTEM account’s user rights. It is an internal account that does not show up in User Manager, and it cannot be added to any groups.
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.
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.
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.
 
### NETWORK SERVICE
The NETWORK SERVICE account is a predefined local account used by the service control manager (SCM). A service that runs in the context of the NETWORK SERVICE account presents the computer's credentials to remote servers. For more information, see [NetworkService Account](https://docs.microsoft.com/windows/desktop/services/networkservice-account).
### LOCAL SERVICE
The LOCAL SERVICE account is a predefined local account used by the service control manager. It has minimum privileges on the local computer and presents anonymous credentials on the network. For more information, see [LocalService Account](https://docs.microsoft.com/windows/desktop/services/localservice-account).
## <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](https://technet.microsoft.com/library/cc731899.aspx).
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 Local Users and Groups. For more information about creating and managing local user accounts, see [Manage Local Users](https://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.
You cannot use Local Users and Groups on 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.
You use Active Directory Users and Computers to manage users and groups in Active Directory.loca
 
You can also manage local users by using NET.EXE USER and manage local groups by using NET.EXE LOCALGROUP, or by using a variety of PowerShell cmdlets and other scripting technologies.
### <a href="" id="sec-restrict-protect-accounts"></a>Restrict and protect local accounts with administrative rights
@ -199,7 +214,7 @@ UAC makes it possible for an account with administrative rights to be treated as
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 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 without 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 more information about UAC, see [User Account Control](/windows/access-protection/user-account-control/user-account-control-overview).
@ -270,6 +285,9 @@ The following table shows the Group Policy and registry settings that are used t
</tbody>
</table>
>[!NOTE]
>You can also enforce the default for LocalAccountTokenFilterPolicy by using the custom ADMX in Security Templates.
 
**To enforce local account restrictions for remote access**
@ -292,7 +310,7 @@ The following table shows the Group Policy and registry settings that are used t
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**.
1. Navigate to the Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\, and &gt; **Security Options**.
2. Double-click **User Account Control: Run all administrators in Admin Approval Mode** &gt; **Enabled** &gt; **OK**.
@ -374,8 +392,8 @@ The following table shows the Group Policy settings that are used to deny networ
<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>
<td><p>Local account and member of Administrators group</p>
</td>
</tr>
<tr class="odd">
<td><p>2</p></td>
@ -390,8 +408,8 @@ The following table shows the Group Policy settings that are used to deny networ
<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>
<td><p>Local account and member of Administrators group</p>
</td>
</tr>
</tbody>
</table>
@ -416,35 +434,19 @@ The following table shows the Group Policy settings that are used to deny networ
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**.
1. Navigate to the Computer Configuration\\Windows Settings\\Security Settings\\, and &gt; **User Rights Assignment**.
2. Double-click **Deny access to this computer from the network**, and &gt; **Define these policy settings**.
2. Double-click **Deny access to this computer from the network**.
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**.
3. Click **Add User or Group**, type **Local account and member of Administrators group**, and &gt; **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**.
2. Double-click **Deny log on through Remote Desktop Services**, and then select **Define these settings**.
2. Double-click **Deny log on through Remote Desktop Services**.
3. 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.
 
4. 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**.
3. Click **Add User or Group**, type type **Local account and member of Administrators group**, and &gt; **OK**.
8. Link the GPO to the first **Workstations** OU as follows:
@ -463,7 +465,6 @@ The following table shows the Group Policy settings that are used to deny networ
**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

18
windows/security/identity-protection/credential-guard/credential-guard-manage.md
View File

@ -12,7 +12,7 @@ ms.author: daniha
manager: dansimp
ms.collection: M365-identity-device-management
ms.topic: article
ms.date: 09/04/2018
ms.date: 03/01/2019
---
# Manage Windows Defender Credential Guard
@ -157,25 +157,19 @@ To disable Windows Defender Credential Guard, you can use the following set of p
> If you manually remove these registry settings, make sure to delete them all. If you don't remove them all, the device might go into BitLocker recovery.
3. Delete the Windows Defender Credential Guard EFI variables by using bcdedit. From an elevated command prompt, type the following commands:
``` syntax
mountvol X: /s
copy %WINDIR%\System32\SecConfig.efi X:\EFI\Microsoft\Boot\SecConfig.efi /Y
bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool" /application osloader
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "\EFI\Microsoft\Boot\SecConfig.efi"
bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO,DISABLE-VBS
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} device partition=X:
bcdedit /set hypervisorlaunchtype off
mountvol X: /d
```
2. Restart the PC.
3. Accept the prompt to disable Windows Defender Credential Guard.
4. Alternatively, you can disable the virtualization-based security features to turn off Windows Defender Credential Guard.
@ -191,7 +185,7 @@ For more info on virtualization-based security and Windows Defender Device Guard
You can also disable Windows Defender Credential Guard by using the [Windows Defender Device Guard and Windows Defender Credential Guard hardware readiness tool](https://www.microsoft.com/download/details.aspx?id=53337).
```
DG_Readiness_Tool_v3.5.ps1 -Disable -AutoReboot
DG_Readiness_Tool_v3.6.ps1 -Disable -AutoReboot
```
#### Disable Windows Defender Credential Guard for a virtual machine

4
windows/security/identity-protection/hello-for-business/hello-cert-trust-deploy-mfa.md
View File

@ -108,7 +108,7 @@ Sign in the domain controller with _domain administrator_ equivalent credentials
##### Add accounts to the Phonefactor Admins group
1. Open **Active Directory Users and Computers**.
2. In the navigation pane, expand the node with the organization’s Active Directory domain name. Select Users. In the content pane. Right-click the **Phonefactors Admin** security group and select **Properties**.
2. In the navigation pane, expand the node with the organization’s Active Directory domain name. Select Users. In the content pane. Right-click the **Phonefactor Admins** security group and select **Properties**.
3. Click the **Members** tab.
4. Click **Add**. Click **Object Types..** In the **Object Types** dialog box, select **Computers** and click **OK**. Enter the following user and/or computers accounts in the **Enter the object names to select** box and then click **OK**.
* The computer account for the primary MFA Server
@ -189,7 +189,7 @@ The User Portal and Mobile Application web services need to communicate with the
Adding the WebServices SDK user account to the Phonefactor Admins group provides the user account with the proper authorization needed to access the configuration data on the primary MFA server using the WebServices SDK.
1. Open **Active Directory Users and Computers**.
2. In the navigation pane, expand the node with the organization’s Active Directory domain name. Select **Users**. In the content pane. Right-click the **Phonefactors Admin** security group and select Properties.
2. In the navigation pane, expand the node with the organization’s Active Directory domain name. Select **Users**. In the content pane. Right-click the **Phonefactor Admins** security group and select Properties.
3. Click the Members tab.
4. Click **Add**. Click **Object Types..** Type the PFWSDK_<computerName> user name in the **Enter the object names to select** box and then click **OK**.
* The computer account for the primary MFA Server

4
windows/security/information-protection/kernel-dma-protection-for-thunderbolt.md
View File

@ -94,9 +94,11 @@ In-market systems, released with Windows 10 version 1709 or earlier, will not su
No, Kernel DMA Protection only protects against drive-by DMA attacks after the OS is loaded. It is the responsibility of the system firmware/BIOS to protect against attacks via the Thunderbolt™ 3 ports during boot.
### How can I check if a certain driver supports DMA-remapping?
DMA-remapping is supported for specific device drivers, and is not universally supported by all devices and drivers on a platform. To check if a specific driver is opted into DMA-remapping, check the values corresponding to the following Property GUID (highlighted in red in the image below) in the Details tab of a device in Device Manager. A value of 0 or 1 means that the device driver does not support DMA-remapping. A value of 2 means that the device driver supports DMA-remapping.
DMA-remapping is supported for specific device drivers, and is not universally supported by all devices and drivers on a platform. To check if a specific driver is opted into DMA-remapping, check the values corresponding to the DMA Remapping Policy property in the Details tab of a device in Device Manager*. A value of 0 or 1 means that the device driver does not support DMA-remapping. A value of 2 means that the device driver supports DMA-remapping.
Please check the driver instance for the device you are testing. Some drivers may have varying values depending on the location of the device (internal vs. external).
*For Windows 10 versions 1803 and 1809, the property field in Device Manager uses a GUID, as highlighted in the image below
![Kernel DMA protection user experience](images/device-details-tab.png)
### What should I do if the drivers for my Thunderbolt™ 3 peripherals do not support DMA-remapping?

4
windows/security/information-protection/windows-information-protection/create-wip-policy-using-intune-azure.md
View File

@ -12,7 +12,7 @@ manager: dansimp
audience: ITPro
ms.collection: M365-security-compliance
ms.topic: conceptual
ms.date: 02/26/2019
ms.date: 02/28/2019
---
# Create a Windows Information Protection (WIP) policy with MDM using the Azure portal for Microsoft Intune
@ -416,7 +416,7 @@ There are no default locations included with WIP, you must add each of your netw
<tr>
<td>Cloud Resources</td>
<td><strong>With proxy:</strong> contoso.sharepoint.com,contoso.internalproxy1.com|<br>contoso.visualstudio.com,contoso.internalproxy2.com<br><br><strong>Without proxy:</strong> contoso.sharepoint.com|contoso.visualstudio.com</td>
<td>Specify the cloud resources to be treated as corporate and protected by WIP.<br><br>For each cloud resource, you may also optionally specify a proxy server from your Internal proxy servers list to route traffic for this cloud resource. Be aware that all traffic routed through your Internal proxy servers is considered enterprise.<br><br>If you have multiple resources, you must separate them using the "|" delimiter. If you don’t use proxy servers, you must also include the "," delimiter just before the "|". For example: <code>URL &lt;,proxy&gt;|URL &lt;,proxy&gt;</code>.<br><br><strong>Important</strong><br>In some cases, such as when an app connects directly to a cloud resource through an IP address, Windows can’t tell whether it’s attempting to connect to an enterprise cloud resource or to a personal site. In this case, Windows blocks the connection by default. To stop Windows from automatically blocking these connections, you can add the <code>/&#42;AppCompat&#42;/</code> string to the setting. For example: <code>URL &lt;,proxy&gt;|URL &lt;,proxy&gt;|/&#42;AppCompat&#42;/</code>.<br><br>When using this string, we recommend that you also turn on [Azure Active Directory Conditional Access](https://docs.microsoft.com/azure/active-directory/active-directory-conditional-access), using the <strong>Domain joined or marked as compliant</strong> option, which blocks apps from accessing any enterprise cloud resources that are protected by conditional access.</td>
<td>Specify the cloud resources to be treated as corporate and protected by WIP.<br><br>For each cloud resource, you may also optionally specify a proxy server from your Internal proxy servers list to route traffic for this cloud resource. Be aware that all traffic routed through your Internal proxy servers is considered enterprise.<br><br>If you have multiple resources, you must separate them using the "|" delimiter. If you don’t use proxy servers, you must also include the "," delimiter just before the "|". For example: <code>URL &lt;,proxy&gt;|URL &lt;,proxy&gt;</code>.<p>Personal applications will be able to access Enterprise Cloud Resources if the resource in the Enterprise Cloud Resource Policy has a blank space or an invalid character, such as a trailing dot in the URL. <br><br><strong>Important</strong><br>In some cases, such as when an app connects directly to a cloud resource through an IP address, Windows can’t tell whether it’s attempting to connect to an enterprise cloud resource or to a personal site. In this case, Windows blocks the connection by default. To stop Windows from automatically blocking these connections, you can add the <code>/&#42;AppCompat&#42;/</code> string to the setting. For example: <code>URL &lt;,proxy&gt;|URL &lt;,proxy&gt;|/&#42;AppCompat&#42;/</code>.<br><br>When using this string, we recommend that you also turn on [Azure Active Directory Conditional Access](https://docs.microsoft.com/azure/active-directory/active-directory-conditional-access), using the <strong>Domain joined or marked as compliant</strong> option, which blocks apps from accessing any enterprise cloud resources that are protected by conditional access.</td>
</tr>
<tr>
<td>Protected domains</td>

2
windows/security/threat-protection/TOC.md
View File

@ -7,7 +7,7 @@
##### [Hardware-based isolation](windows-defender-atp/overview-hardware-based-isolation.md)
###### [Application isolation](windows-defender-application-guard/wd-app-guard-overview.md)
####### [System requirements](windows-defender-application-guard/reqs-wd-app-guard.md)
###### [System integrity](windows-defender-system-guard/how-hardware-based-root-of-trust-helps-protect-windows.md)
###### [System integrity](windows-defender-system-guard/system-guard-how-hardware-based-root-of-trust-helps-protect-windows.md)
##### [Application control](windows-defender-application-control/windows-defender-application-control.md)
##### [Exploit protection](windows-defender-exploit-guard/exploit-protection-exploit-guard.md)
##### [Network protection](windows-defender-exploit-guard/network-protection-exploit-guard.md)

8
windows/security/threat-protection/auditing/audit-security-group-management.md
View File

@ -8,7 +8,7 @@ ms.mktglfcycl: deploy
ms.sitesec: library
ms.localizationpriority: none
author: Mir0sh
ms.date: 04/19/2017
ms.date: 02/28/2019
---
# Audit Security Group Management
@ -32,9 +32,9 @@ This subcategory allows you to audit events generated by changes to security gro
| Computer Type | General Success | General Failure | Stronger Success | Stronger Failure | Comments |
|-------------------|-----------------|-----------------|------------------|------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Domain Controller | Yes | No | Yes | No | We recommend Success auditing of security groups, to see new group creation events, changes and deletion of critical groups. Also you will get information about new members of security groups, when a member was removed from a group and when security group membership was enumerated. <br> We recommend Failure auditing, to collect information about failed attempts to create, change, or delete new security groups.|
| Member Server | Yes | No | Yes | No | We recommend Success auditing of security groups, to see new group creation events, changes and deletion of critical groups. Also you will get information about new members of security groups, when a member was removed from a group and when security group membership was enumerated. <br> We recommend Failure auditing, to collect information about failed attempts to create, change, or delete new security groups.|
| Workstation | Yes | No | Yes | No | We recommend Success auditing of security groups, to see new group creation events, changes and deletion of critical groups. Also you will get information about new members of security groups, when a member was removed from a group and when security group membership was enumerated. <br> We recommend Failure auditing, to collect information about failed attempts to create, change, or delete new security groups.|
| Domain Controller | Yes | No | Yes | No | We recommend Success auditing of security groups, to see new group creation events, changes and deletion of critical groups. Also you will get information about new members of security groups, when a member was removed from a group and when security group membership was enumerated. <br> This subcategory doesn’t have Failure events, so there is no recommendation to enable Failure auditing for this subcategory.|
| Member Server | Yes | No | Yes | No | We recommend Success auditing of security groups, to see new group creation events, changes and deletion of critical groups. Also you will get information about new members of security groups, when a member was removed from a group and when security group membership was enumerated. <br> This subcategory doesn’t have Failure events, so there is no recommendation to enable Failure auditing for this subcategory.|
| Workstation | Yes | No | Yes | No | We recommend Success auditing of security groups, to see new group creation events, changes and deletion of critical groups. Also you will get information about new members of security groups, when a member was removed from a group and when security group membership was enumerated. <br> This subcategory doesn’t have Failure events, so there is no recommendation to enable Failure auditing for this subcategory.|
**Events List:**

6
windows/security/threat-protection/auditing/event-4769.md
View File

@ -80,12 +80,14 @@ You will typically see many Failure events with **Failure Code** “**0x20**”,
**Account Information:**
- **Account Name** \[Type = UnicodeString\]**:** the User Principal Name (UPN) of the account that requested the ticket. Computer account name ends with **$** character in UPN. This field typically has the following value format: user\_account\_name@FULL\_DOMAIN\_NAME.
- **Account Name** \[Type = UnicodeString\]**:** the user name of the account that requested the ticket in the User Principal Name (UPN) syntax. Computer account name ends with **$** character in the user name part. This field typically has the following value format: user\_account\_name@FULL\_DOMAIN\_NAME.
- User account example: dadmin@CONTOSO.LOCAL
- Computer account example: WIN81$@CONTOSO.LOCAL
> **Note** Although this field is in the UPN format, this is not the attribute value of "UserPrincipalName" of the user account. It is the "normalized" name or implicit UPN. It is built from the user SamAccountName and the Active Directory domain name.
This parameter in this event is optional and can be empty in some cases.
- **Account Domain** \[Type = UnicodeString\]**:** the name of the Kerberos Realm that **Account Name** belongs to. This can appear in a variety of formats, including the following:
@ -169,7 +171,7 @@ The most common values:
| 12 | Transited-policy-checked | KILE MUST NOT check for transited domains on servers or a KDC. Application servers MUST ignore the TRANSITED-POLICY-CHECKED flag. |
| 13 | Ok-as-delegate | The KDC MUST set the OK-AS-DELEGATE flag if the service account is trusted for delegation. |
| 14 | Request-anonymous | KILE not use this flag. |
| 15 | Name-canonicalize | In order to request referrals the Kerberos client MUST explicitly request the "canonicalize" KDC option for the AS-REQ or TGS-REQ. |
| 15 | Name-canonicalize | In order to request referrals the Kerberos client MUST explicitly request the “canonicalize” KDC option for the AS-REQ or TGS-REQ. |
| 16-25 | Unused | - |
| 26 | Disable-transited-check | By default the KDC will check the transited field of a TGT against the policy of the local realm before it will issue derivative tickets based on the TGT. If this flag is set in the request, checking of the transited field is disabled. Tickets issued without the performance of this check will be noted by the reset (0) value of the TRANSITED-POLICY-CHECKED flag, indicating to the application server that the transited field must be checked locally. KDCs are encouraged but not required to honor<br>the DISABLE-TRANSITED-CHECK option.<br>Should not be in use, because Transited-policy-checked flag is not supported by KILE. |
| 27 | Renewable-ok | The RENEWABLE-OK option indicates that a renewable ticket will be acceptable if a ticket with the requested life cannot otherwise be provided, in which case a renewable ticket may be issued with a renew-till equal to the requested end time. The value of the renew-till field may still be limited by local limits, or limits selected by the individual principal or server. |

4
windows/security/threat-protection/use-windows-event-forwarding-to-assist-in-intrusion-detection.md
View File

@ -7,7 +7,7 @@ ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: tedhardyMSFT
ms.date: 02/16/2018
ms.date: 02/28/2019
ms.localizationpriority: medium
---
@ -338,7 +338,7 @@ If your organizational audit policy enables additional auditing to meet its need
| Category | Subcategory | Audit settings |
|--------------------|---------------------------------|---------------------|
| Account Logon | Credential Validation | Success and Failure |
| Account Management | Security Group Management | Success and Failure |
| Account Management | Security Group Management | Success |
| Account Management | User Account Management | Success and Failure |
| Account Management | Computer Account Management | Success and Failure |
| Account Management | Other Account Management Events | Success and Failure |

5
windows/security/threat-protection/windows-defender-application-control/applocker/administer-applocker.md
View File

@ -12,7 +12,7 @@ manager: dansimp
audience: ITPro
ms.collection: M365-security-compliance
ms.topic: conceptual
ms.date: 09/21/2017
ms.date: 02/28/2019
---
# Administer AppLocker
@ -37,7 +37,6 @@ AppLocker helps administrators control how users can access and use files, such
| Topic | Description |
| - | - |
| [Administer AppLocker using Mobile Device Management (MDM)](administer-applocker-using-mdm.md) | This topic describes how to used MDM to manage AppLocker policies. |
| [Maintain AppLocker policies](maintain-applocker-policies.md) | This topic describes how to maintain rules within AppLocker policies. |
| [Edit an AppLocker policy](edit-an-applocker-policy.md) | This topic for IT professionals describes the steps required to modify an AppLocker policy. |
| [Test and update an AppLocker policy](test-and-update-an-applocker-policy.md) | This topic discusses the steps required to test an AppLocker policy prior to deployment. |
@ -71,5 +70,3 @@ You must have Edit Setting permission to edit a GPO. By default, members of the
## Using Windows PowerShell to administer AppLocker
For how-to info about administering AppLocker with Windows PowerShell, see [Use the AppLocker Windows PowerShell Cmdlets](use-the-applocker-windows-powershell-cmdlets.md). For reference info and examples how to administer AppLocker with Windows PowerShell, see the [AppLocker cmdlets](https://technet.microsoft.com/library/hh847210.aspx).
 
 

2
windows/security/threat-protection/windows-defender-atp/TOC.md
View File

@ -5,7 +5,7 @@
#### [Hardware-based isolation](overview-hardware-based-isolation.md)
##### [Application isolation](../windows-defender-application-guard/wd-app-guard-overview.md)
###### [System requirements](../windows-defender-application-guard/reqs-wd-app-guard.md)
##### [System integrity](../windows-defender-system-guard/how-hardware-based-root-of-trust-helps-protect-windows.md)
##### [System integrity](../windows-defender-system-guard/system-guard-how-hardware-based-root-of-trust-helps-protect-windows.md)
#### [Application control](../windows-defender-application-control/windows-defender-application-control.md)
#### [Exploit protection](../windows-defender-exploit-guard/exploit-protection-exploit-guard.md)
#### [Network protection](../windows-defender-exploit-guard/network-protection-exploit-guard.md)

5
windows/security/threat-protection/windows-defender-atp/overview-hardware-based-isolation.md
View File

@ -25,8 +25,5 @@ Hardware-based isolation helps protect system integrity in Windows 10 and is int
| Feature | Description |
|------------|-------------|
| [Windows Defender Application Guard](../windows-defender-application-guard/wd-app-guard-overview.md) | Application Guard protects your device from advanced attacks while keeping you productive. Using a unique hardware-based isolation approach, the goal is to isolate untrusted websites and PDF documents inside a lightweight container that is separated from the operating system via the native Windows Hypervisor. If an untrusted site or PDF document turns out to be malicious, it still remains contained within Application Guard’s secure container, keeping the desktop PC protected and the attacker away from your enterprise data. |
| [Windows Defender System Guard](how-hardware-based-containers-help-protect-windows.md) | System Guard protects and maintains the integrity of the system as it starts and after it's running, and validates system integrity by using attestation. |
| [Windows Defender System Guard](../windows-defender-system-guard/system-guard-how-hardware-based-root-of-trust-helps-protect-windows.md) | System Guard protects and maintains the integrity of the system as it starts and after it's running, and validates system integrity by using attestation. |

8
windows/security/threat-protection/windows-defender-system-guard/how-hardware-based-root-of-trust-helps-protect-windows.md
View File

@ -1,6 +1,6 @@
---
title: How a hardware-based root of trust helps protect Windows 10 (Windows 10)
description: Windows 10 uses a hardware-based root of trust to securely protect systems against firmware exploits.
title: Windows Defender System Guard How a hardware-based root of trust helps protect Windows 10 (Windows 10)
description: Windows Defender System Guard in Windows 10 uses a hardware-based root of trust to securely protect systems against firmware exploits.
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
search.appverid: met150
ms.prod: w10
@ -9,7 +9,7 @@ ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
author: justinha
ms.date: 02/14/2019
ms.date: 03/01/2019
---
@ -43,7 +43,7 @@ In addition, a bug fix for UEFI code can take a long time to design, build, rete
### Secure Launch—the Dynamic Root of Trust for Measurement (DRTM)
Windows Defender System Guard Secure Launch, first introduced in Windows 10 version 1809, aims to alleviate these issues by leveraging a technology known as the Dynamic Root of Trust for Measurement (DRTM).
[Windows Defender System Guard Secure Launch](system-guard-secure-launch-and-smm-protection.md), first introduced in Windows 10 version 1809, aims to alleviate these issues by leveraging a technology known as the Dynamic Root of Trust for Measurement (DRTM).
DRTM lets the system freely boot into untrusted code initially, but shortly after launches the system into a trusted state by taking control of all CPUs and forcing them down a well-known and measured code path.
This has the benefit of allowing untrusted early UEFI code to boot the system, but then being able to securely transition into a trusted and measured state.

83
windows/security/threat-protection/windows-defender-system-guard/system-guard-how-hardware-based-root-of-trust-helps-protect-windows.md Normal file
View File

@ -0,0 +1,83 @@
---
title: Windows Defender System Guard How a hardware-based root of trust helps protect Windows 10 (Windows 10)
description: Windows Defender System Guard in Windows 10 uses a hardware-based root of trust to securely protect systems against firmware exploits.
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
search.appverid: met150
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
author: justinha
ms.date: 03/01/2019
---
# Windows Defender System Guard: How a hardware-based root of trust helps protect Windows 10
In order to protect critical resources such as the Windows authentication stack, single sign-on tokens, the Windows Hello biometric stack, and the Virtual Trusted Platform Module, a system's firmware and hardware must be trustworthy.
Windows Defender System Guard reorganizes the existing Windows 10 system integrity features under one roof and sets up the next set of investments in Windows security. It's designed to make these security guarantees:
- Protect and maintain the integrity of the system as it starts up
- Validate that system integrity has truly been maintained through local and remote attestation
## Maintaining the integrity of the system as it starts
### Static Root of Trust for Measurement (SRTM)
With Windows 7, one of the means attackers would use to persist and evade detection was to install what is often referred to as a bootkit or rootkit on the system.
This malicious software would start before Windows started, or during the boot process itself, enabling it to start with the highest level of privilege.
With Windows 10 running on modern hardware (that is, Windows 8-certified or greater) a hardware-based root of trust helps ensure that no unauthorized firmware or software (such as a bootkit) can start before the Windows bootloader.
This hardware-based root of trust comes from the device’s Secure Boot feature, which is part of the Unified Extensible Firmware Interface (UEFI).
This technique of measuring the static early boot UEFI components is called the Static Root of Trust for Measurement (SRTM).
As there are thousands of PC vendors that produce numerous models with different UEFI BIOS versions, there becomes an incredibly large number of SRTM measurements upon bootup.
Two techniques exist to establish trust here—either maintain a list of known 'bad' SRTM measurements (also known as a blacklist), or a list of known 'good' SRTM measurements (also known as a whitelist).
Each option has a drawback:
- A list of known 'bad' SRTM measurements allows a hacker to change just 1 bit in a component to create an entirely new SRTM hash that needs to be listed. This means that the SRTM flow is inherently brittle - a minor change can invalidate the entire chain of trust.
- A list of known 'good' SRTM measurements requires each new BIOS/PC combination measurement to be carefully added, which is slow.
In addition, a bug fix for UEFI code can take a long time to design, build, retest, validate, and redeploy.
### Secure Launch—the Dynamic Root of Trust for Measurement (DRTM)
Windows Defender System Guard Secure Launch, first introduced in Windows 10 version 1809, aims to alleviate these issues by leveraging a technology known as the Dynamic Root of Trust for Measurement (DRTM).
DRTM lets the system freely boot into untrusted code initially, but shortly after launches the system into a trusted state by taking control of all CPUs and forcing them down a well-known and measured code path.
This has the benefit of allowing untrusted early UEFI code to boot the system, but then being able to securely transition into a trusted and measured state.
![System Guard Secure Launch](images/system-guard-secure-launch.png)
Secure Launch simplifies management of SRTM measurements because the launch code is now unrelated to a specific hardware configuration. This means the number of valid code measurements is small, and future updates can be deployed more widely and quickly.
### System Management Mode (SMM) protection
System Management Mode (SMM) is a special-purpose CPU mode in x86 microcontrollers that handles power management, hardware configuration, thermal monitoring, and anything else the manufacturer deems useful.
Whenever one of these system operations is requested, a non-maskable interrupt (SMI) is invoked at runtime, which executes SMM code installed by the BIOS.
SMM code executes in the highest privilege level and is invisible to the OS, which makes it an attractive target for malicious activity. Even if System Guard Secure Launch is used to late launch, SMM code can potentially access hypervisor memory and change the hypervisor.
To defend against this, two techniques are used:
1. Paging protection to prevent inappropriate access to code and data
2. SMM hardware supervision and attestation
Paging protection can be implemented to lock certain code tables to be read-only to prevent tampering.
This prevents access to any memory that has not been specifically assigned.
A hardware-enforced processor feature known as a supervisor SMI handler can monitor the SMM and make sure it does not access any part of the address space that it is not supposed to.
SMM protection is built on top of the Secure Launch technology and requires it to function.
In the future, Windows 10 will also measure this SMI Handler’s behavior and attest that no OS-owned memory has been tampered with.
## Validating platform integrity after Windows is running (run time)
While Windows Defender System Guard provides advanced protection that will help protect and maintain the integrity of the platform during boot and at run time, the reality is that we must apply an "assume breach" mentality to even our most sophisticated security technologies. We should be able to trust that the technologies are successfully doing their jobs, but we also need the ability to verify that they were successful in achieving their goals. When it comes to platform integrity, we can’t just trust the platform, which potentially could be compromised, to self-attest to its security state. So Windows Defender System Guard includes a series of technologies that enable remote analysis of the device’s integrity.
As Windows 10 boots, a series of integrity measurements are taken by Windows Defender System Guard using the device’s Trusted Platform Module 2.0 (TPM 2.0). System Guard Secure Launch will not support earlier TPM versions, such as TPM 1.2. This process and data are hardware-isolated away from Windows to help ensure that the measurement data is not subject to the type of tampering that could happen if the platform was compromised. From here, the measurements can be used to determine the integrity of the device’s firmware, hardware configuration state, and Windows boot-related components, just to name a few.
![Boot time integrity](images/windows-defender-system-guard-boot-time-integrity.png)
After the system boots, Windows Defender System Guard signs and seals these measurements using the TPM. Upon request, a management system like Intune or System Center Configuration Manager can acquire them for remote analysis. If Windows Defender System Guard indicates that the device lacks integrity, the management system can take a series of actions, such as denying the device access to resources.

4
windows/security/threat-protection/windows-defender-system-guard/system-guard-secure-launch-and-smm-protection.md
View File

@ -8,12 +8,12 @@ ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
author: justinha
ms.date: 02/14/2019
ms.date: 03/01/2019
---
# System Guard Secure Launch and SMM protection
This topic explains how to configure System Guard Secure Launch and System Management Mode (SMM) protection to improve the startup security of Windows 10 devices. The information below is presented from a client perspective.
This topic explains how to configure [System Guard Secure Launch and System Management Mode (SMM) protection](system-guard-how-hardware-based-root-of-trust-helps-protect-windows.md) to improve the startup security of Windows 10 devices. The information below is presented from a client perspective.
## How to enable System Guard Secure Launch