resolving conflict

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

@@ -193,7 +193,7 @@ The DSMA 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 DSMA is disabled by default on the desktop SKUs (full windows SKUs) and WS 2016 with the Desktop. 
 
-The DSMA has a well-known RID of 503. The security identifier (SID) of the DSMA will thus have a well-known SID in the following format: S-1-5-21-<ComputerIdentifier>-503 
+The DSMA has a well-known RID of 503. The security identifier (SID) of the DSMA will thus have a well-known SID in the following format: S-1-5-21-\<ComputerIdentifier>-503 
 
 The DSMA is a member of the well-known group **System Managed Accounts Group**, which has a well-known SID of S-1-5-32-581. 
 

windows/security/identity-protection/access-control/security-identifiers.md

@@ -283,6 +283,14 @@ The following table describes changes in SID implementation in the Windows opera
 | 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. |
 
+## Capability SIDs
+
+Capability Security Identifiers (SIDs) are used to uniquely and immutably identify capabilities. Capabilities represent an unforgeable token of authority that grants access to resources (Examples: documents, camera, locations etc...) to Universal Windows Applications. An App that “has” a capability is granted access to the resource the capability is associated with, and one that “does not have” a capability is denied access to the resource.
+
+All Capability SIDs that the operating system is aware of are stored in the Windows Registry in the path `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities'. Any Capability SID added to Windows by first or third-party applications will be added to this location.
+
+All Capability SIDs are prefixed by S-1-15-3
+
 ## See also
 
 - [Access Control Overview](access-control.md)

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

@@ -182,7 +182,7 @@ The User Portal and Mobile Application web services need to communicate with the
 
 1. Open **Active Directory Users and Computers**.
 2. In the navigation pane, expand the node with the organization’s Active Directory domain name.  Right-click the **Users** container, select **New**, and select **User**.
-3. In the **New Object – User** dialog box, type **PFWSDK_<computerName>** in the **First name** and **User logon name** boxes, where *<computer>* is the name of the primary MFA server running the Web Services SDK.  Click **Next**.
+3. In the **New Object – User** dialog box, type **PFWSDK_\<computerName>** in the **First name** and **User logon name** boxes, where *\<computer>* is the name of the primary MFA server running the Web Services SDK.  Click **Next**.
 4. Type a strong password and confirm it in the respective boxes.  Clear **User must change password at next logon**. Click **Next**.  Click **Finish** to create the user account.
 
 #### Add the MFA SDK user account to the Phonefactor Admins group
@@ -192,7 +192,7 @@ Adding the WebServices SDK user account to the Phonefactor Admins group provides
 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 **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**.   
+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
     * The Webservices SDK user account
     *  Group or user account that will manage the User Portal server.
@@ -507,7 +507,7 @@ Sign in the primary AD FS server with _local administrator_ equivalent credentia
 
 Sign in the primary AD FS server with _local administrator_ equivalent credentials.
 
-Edit the **Register-MultiFactorAuthenticationAdfsAdapter.ps1** script adding `-ConfigurationFilePath <path>` to the end of the `Register-AdfsAuthenticationProvider` command where **<path>** is the full path to the **MultiFactorAuthenticationAdfsAdapter.config** file.
+Edit the **Register-MultiFactorAuthenticationAdfsAdapter.ps1** script adding `-ConfigurationFilePath <path>` to the end of the `Register-AdfsAuthenticationProvider` command where **\<path>** is the full path to the **MultiFactorAuthenticationAdfsAdapter.config** file.
 
 ### Run the AD FS Adapter PowerShell cmdlet
 

windows/security/identity-protection/hello-for-business/hello-key-trust-deploy-mfa.md

@@ -182,7 +182,7 @@ The User Portal and Mobile Application web services need to communicate with the
 
 1. Open **Active Directory Users and Computers**.
 2. In the navigation pane, expand the node with the organization’s Active Directory domain name.  Right-click the **Users** container, select **New**, and select **User**.
-3. In the **New Object – User** dialog box, type **PFWSDK_<computerName>** in the **First name** and **User logon name** boxes, where *<computer>* is the name of the primary MFA server running the Web Services SDK.  Click **Next**.
+3. In the **New Object – User** dialog box, type **PFWSDK_\<computerName>** in the **First name** and **User logon name** boxes, where *\<computer>* is the name of the primary MFA server running the Web Services SDK.  Click **Next**.
 4. Type a strong password and confirm it in the respective boxes.  Clear **User must change password at next logon**. Click **Next**.  Click **Finish** to create the user account.
 
 #### Add the MFA SDK user account to the Phonefactor Admins group
@@ -192,7 +192,7 @@ Adding the WebServices SDK user account to the Phonefactor Admins group provides
 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.
 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**.   
+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
     * The Webservices SDK user account
     *  Group or user account that will manage the User Portal server.
@@ -507,7 +507,7 @@ Sign in the primary AD FS server with _local administrator_ equivalent credentia
 
 Sign in the primary AD FS server with _local administrator_ equivalent credentials.
 
-Edit the **Register-MultiFactorAuthenticationAdfsAdapter.ps1** script adding `-ConfigurationFilePath <path>` to the end of the `Register-AdfsAuthenticationProvider` command where **<path>** is the full path to the **MultiFactorAuthenticationAdfsAdapter.config** file.
+Edit the **Register-MultiFactorAuthenticationAdfsAdapter.ps1** script adding `-ConfigurationFilePath <path>` to the end of the `Register-AdfsAuthenticationProvider` command where **\<path>** is the full path to the **MultiFactorAuthenticationAdfsAdapter.config** file.
 
 ### Run the AD FS Adapter PowerShell cmdlet