Merge pull request #107802 from MicrosoftDocs/master

Merge master to live 4 AM

Author: ShannonLeavitt

articles/active-directory-b2c/restful-technical-profile.md

@@ -9,7 +9,7 @@ manager: celestedg
 ms.service: active-directory
 ms.workload: identity
 ms.topic: reference
-ms.date: 03/03/2020
+ms.date: 03/16/2020
 ms.author: mimart
 ms.subservice: B2C
 ---
@@ -215,19 +215,7 @@ If the type of authentication is set to `Bearer`, the **CryptographicKeys** elem
 
 ## Returning error message
 
-Your REST API may need to return an error message, such as 'The user was not found in the CRM system'. If an error occurs, the REST API should return an HTTP 409 error message (Conflict response status code) with following attributes:
-
-| Attribute | Required | Description |
-| --------- | -------- | ----------- |
-| version | Yes | 1.0.0 |
-| status | Yes | 409 |
-| code | No | An error code from the RESTful endpoint provider, which is displayed when `DebugMode` is enabled. |
-| requestId | No | A request identifier from the RESTful endpoint provider, which is displayed when `DebugMode` is enabled. |
-| userMessage | Yes | An error message that is shown to the user. |
-| developerMessage | No | The verbose description of the problem and how to fix it, which is displayed when `DebugMode` is enabled. |
-| moreInfo | No | A URI that points to additional information, which is displayed when `DebugMode` is enabled. |
-
-The following example shows a REST API that returns an error message formatted in JSON:
+Your REST API may need to return an error message, such as 'The user was not found in the CRM system'. If an error occurs, the REST API should return an HTTP 4xx error message, such as, 400 (bad request), or 409 (conflict) response status code. The response body contains error message formatted in JSON:
 
 ```JSON
 {
@@ -241,6 +229,17 @@ The following example shows a REST API that returns an error message formatted i
 }
 ```
 
+| Attribute | Required | Description |
+| --------- | -------- | ----------- |
+| version | Yes | Your REST API version. For example: 1.0.1 |
+| status | Yes | Must be 409 |
+| code | No | An error code from the RESTful endpoint provider, which is displayed when `DebugMode` is enabled. |
+| requestId | No | A request identifier from the RESTful endpoint provider, which is displayed when `DebugMode` is enabled. |
+| userMessage | Yes | An error message that is shown to the user. |
+| developerMessage | No | The verbose description of the problem and how to fix it, which is displayed when `DebugMode` is enabled. |
+| moreInfo | No | A URI that points to additional information, which is displayed when `DebugMode` is enabled. |
+
+
 The following example shows a C# class that returns an error message:
 
 ```csharp

articles/active-directory-b2c/self-asserted-technical-profile.md

@@ -9,7 +9,7 @@ manager: celestedg
 ms.service: active-directory
 ms.workload: identity
 ms.topic: reference
-ms.date: 02/17/2020
+ms.date: 03/16/2020
 ms.author: mimart
 ms.subservice: B2C
 ---
@@ -64,8 +64,8 @@ In the display claims collection, you can include a reference to a [DisplayContr
 
 The following example `TechnicalProfile` illustrates the use of display claims with display controls.
 
-* The first display claim makes a reference to the `emailVerificationControl` display control which collects and verifies the email address.
-* The fifth display claim makes a reference to the `phoneVerificationControl` display control which collects and verifies a phone number.
+* The first display claim makes a reference to the `emailVerificationControl` display control, which collects and verifies the email address.
+* The fifth display claim makes a reference to the `phoneVerificationControl` display control, which collects and verifies a phone number.
 * The other display claims are ClaimTypes to be collected from the user.
 
 ```XML
@@ -117,6 +117,8 @@ The `age` claim in the base policy is no longer presented on the screen to the u
 
 The **OutputClaims** element contains a list of claims to be returned to the next orchestration step. The **DefaultValue** attribute takes effect only if the claim has never been set. If it was set in a previous orchestration step, the default value does not take effect even if the user leaves the value empty. To force the use of a default value, set the **AlwaysUseDefaultValue** attribute to `true`.
 
+For security reasons, a password claim value (`UserInputType` set to `Password`) is available only to the self-asserted technical profile's validation technical profiles. You cannot use password claim in the next orchestration steps. 
+
 > [!NOTE]
 > In previous versions of the Identity Experience Framework (IEF), output claims were used to collect data from the user. To collect data from the user, use a **DisplayClaims** collection instead.
 
@@ -126,7 +128,7 @@ The **OutputClaimsTransformations** element may contain a collection of **Output
 
 In a self-asserted technical profile, the output claims collection returns the claims to the next orchestration step.
 
-You should use output claims when:
+Use output claims when:
 
 - **Claims are output by output claims transformation**.
 - **Setting a default value in an output claim** without collecting data from the user or returning the data from the validation technical profile. The `LocalAccountSignUpWithLogonEmail` self-asserted technical profile sets the **executed-SelfAsserted-Input** claim to `true`.
@@ -190,7 +192,7 @@ You can also call a REST API technical profile with your business logic, overwri
 | AllowGenerationOfClaimsWithNullValues| No| Allow to generate a claim with null value. For example, in a case user doesn't select a checkbox.|
 | ContentDefinitionReferenceId | Yes | The identifier of the [content definition](contentdefinitions.md) associated with this technical profile. |
 | EnforceEmailVerification | No | For sign-up or profile edit, enforces email verification. Possible values: `true` (default), or `false`. |
-| setting.retryLimit | No | Controls the number of times a user can try to provide the data that is checked against a validation technical profile . For example, a user tries to sign-up with an account that already exists and keeps trying until the limit reached.
+| setting.retryLimit | No | Controls the number of times a user can try to provide the data that is checked against a validation technical profile. For example, a user tries to sign-up with an account that already exists and keeps trying until the limit reached.
 | SignUpTarget <sup>1</sup>| No | The signup target exchange identifier. When the user clicks the sign-up button, Azure AD B2C executes the specified exchange identifier. |
 | setting.showCancelButton | No | Displays the cancel button. Possible values: `true` (default), or `false` |
 | setting.showContinueButton | No | Displays the continue button. Possible values: `true` (default), or `false` |

articles/active-directory-b2c/validation-technical-profile.md

@@ -9,7 +9,7 @@ manager: celestedg
 ms.service: active-directory
 ms.workload: identity
 ms.topic: reference
-ms.date: 09/10/2018
+ms.date: 03/16/2020
 ms.author: mimart
 ms.subservice: B2C
 ---
@@ -18,7 +18,7 @@ ms.subservice: B2C
 
 [!INCLUDE [active-directory-b2c-advanced-audience-warning](../../includes/active-directory-b2c-advanced-audience-warning.md)]
 
-A validation technical profile is an ordinary technical profile from any protocol, such as [Azure Active Directory](active-directory-technical-profile.md) or a [REST API](restful-technical-profile.md). The validation technical profile returns output claims or returns an HTTP 409 error message (Conflict response status code), with the following data:
+A validation technical profile is an ordinary technical profile from any protocol, such as [Azure Active Directory](active-directory-technical-profile.md) or a [REST API](restful-technical-profile.md). The validation technical profile returns output claims, or returns 4xx HTTP status code, with the following data. For more information, see [returning error message](restful-technical-profile.md#returning-error-message)
 
 ```JSON
 {
@@ -28,11 +28,11 @@ A validation technical profile is an ordinary technical profile from any protoco
 }
 ```
 
-Claims that are returned from a validation technical profile are added back to the claims bag. You can use those claims in the next validation technical profiles.
+The scope of the output claims of a validation technical profile is limited to the [self-asserted technical profile](self-asserted-technical-profile.md) that invokes the validation technical profile, and its validation technical profiles. If you want to use the output claims in the next orchestration step, add the output claims to the self-asserted technical profile that invokes the validation technical profile.
 
 Validation technical profiles are executed in the sequence that they appear in the **ValidationTechnicalProfiles** element. You can configure in a validation technical profile whether the execution of any subsequent validation technical profiles should continue if the validation technical profile raises an error or is successful.
 
-A validation technical profile can be conditionally executed based on preconditions defined in the **ValidationTechnicalProfile** element. For example, you can check whether a specific claims exists, or if a claim is equal or not to the specified value.
+A validation technical profile can be conditionally executed based on preconditions defined in the **ValidationTechnicalProfile** element. For example, you can check whether a specific claim exists, or if a claim is equal or not to the specified value.
 
 A self-asserted technical profile may define a validation technical profile to be used for validating some or all of its output claims. All of the input claims of the referenced technical profile must appear in the output claims of the referencing validation technical profile.
 

articles/active-directory/conditional-access/terms-of-use.md

@@ -245,7 +245,7 @@ The following procedure describes how to add a terms of use language.
 
 ## Per-device terms of use
 
-The **Require users to consent on every device** setting enables you to require end users to accept your terms of use on every device they are accessing from. The end user will be required to join their device in Azure AD. When the device is joined, the device ID is used to enforce the terms of use on each device.
+The **Require users to consent on every device** setting enables you to require end users to accept your terms of use on every device they are accessing from. The end user will be required to register their device in Azure AD. When the device is registered, the device ID is used to enforce the terms of use on each device.
 
 Here is a list of the supported platforms and software.
 

articles/active-directory/devices/howto-vm-sign-in-azure-ad-windows.md

@@ -174,7 +174,7 @@ After a few moments, the security principal is assigned the role at the selected
 
 The following example uses [az role assignment create](/cli/azure/role/assignment#az-role-assignment-create) to assign the Virtual Machine Administrator Login role to the VM for your current Azure user. The username of your active Azure account is obtained with [az account show](/cli/azure/account#az-account-show), and the scope is set to the VM created in a previous step with [az vm show](/cli/azure/vm#az-vm-show). The scope could also be assigned at a resource group or subscription level, and normal RBAC inheritance permissions apply. For more information, see [Role-Based Access Controls](../../virtual-machines/linux/login-using-aad.md).
 
-```   zureCLI
+```   AzureCLI
 username=$(az account show --query user.name --output tsv)
 vm=$(az vm show --resource-group myResourceGroup --name myVM --query id -o tsv)