Merge pull request #41 from MicrosoftDocs/master

merge

Author: yuemlu

.openpublishing.redirection.json

@@ -9,7 +9,7 @@ manager: celestedg
 ms.service: active-directory
 ms.workload: identity
 ms.topic: reference
-ms.date: 03/26/2020
+ms.date: 03/31/2020
 ms.author: mimart
 ms.subservice: B2C
 ---
@@ -20,12 +20,11 @@ ms.subservice: B2C
 
 Azure Active Directory B2C (Azure AD B2C) provides support for enrolling and verifying phone numbers. This technical profile:
 
-- Provides a user interface to interact with the user.
-- Uses content definition to control the look and feel.
-- Supports both phone calls and text messages to validate the phone number.
+- Provides a user interface to interact with the user to verify, or enroll a phone number.
+- Supports phone calls and text messages to validate the phone number.
 - Supports multiple phone numbers. The user can select one of the phone numbers to verify.  
-- If a phone number is provided, the phone factor user interface asks the user to verify the phone number. If not provided, it asks the user to enroll a new phone number.
-- Returns a claim indicating whether the user provided a new phone number. You can use this claim to decide whether the phone number should  be persisted to the Azure AD user profile.  
+- Returns a claim indicating whether the user provided a new phone number. You can use this claim to decide whether the phone number should  be persisted to the Azure AD B2C user profile.  
+- Uses a [content definition](contentdefinitions.md) to control the look and feel.
 
 ## Protocol
 
@@ -41,19 +40,25 @@ The following example shows a phone factor technical profile for enrollment and
 </TechnicalProfile>
 ```
 
-## Input claims
+## Input claims transformations
 
-The InputClaims element must contain following claims. You can also map the name of your claim to the name defined in the phone factor technical profile. 
+The InputClaimsTransformations element may contain a collection of input claims transformations that are used to modify the input claims, or generate new ones. The following input claims transformation generates a `UserId` claim that is used later in the input claims collection.
 
-```XML
-<InputClaims>
-  <!--A unique identifier of the user. The partner claim type must be set to `UserId`. -->
-  <InputClaim ClaimTypeReferenceId="userIdForMFA" PartnerClaimType="UserId" />
-  <!--A claim that contains the phone number. If the claim is empty, Azure AD B2C asks the user to enroll a new phone number. Otherwise, it asks the user to verify the phone number. -->
-  <InputClaim ClaimTypeReferenceId="strongAuthenticationPhoneNumber" />
-</InputClaims>
+```xml
+<InputClaimsTransformations>
+  <InputClaimsTransformation ReferenceId="CreateUserIdForMFA" />
+</InputClaimsTransformations>
 ```
 
+## Input claims
+
+The InputClaims element must contain the following claims. You can also map the name of your claim to the name defined in the phone factor technical profile. 
+
+|  Data type| Required | Description |
+| --------- | -------- | ----------- | 
+| string| Yes | A unique identifier for the user. The claim name, or PartnerClaimType must be set to `UserId`. This claim should not contain personal identifiable information.|
+| string| Yes | List of claim types. Each claim contains one phone number. If any of the input claims do not contain a phone number, the user will be asked to enroll and verify a new phone number. The validated phone number is returned as an output claim. If one of the input claims contain a phone number, the user is asked to verify it. If multiple input claims contain a phone number, the user is asked to choose and verify one of the phone numbers. |
+
 The following example demonstrates using multiple phone numbers. For more information, see [sample policy](https://github.com/azure-ad-b2c/samples/tree/master/policies/mfa-add-secondarymfa).
 
 ```XML
@@ -64,22 +69,16 @@ The following example demonstrates using multiple phone numbers. For more inform
 </InputClaims>
 ```
 
-The InputClaimsTransformations element may contain a collection of InputClaimsTransformation elements that are used to modify the input claims or generate new ones before presenting them to the phone factor page.
-
 ## Output claims
 
 The OutputClaims element contains a list of claims returned by the phone factor technical profile.
 
-```xml
-<OutputClaims>
-  <!-- The verified phone number. The partner claim type must be set to `Verified.OfficePhone`. -->
-  <OutputClaim ClaimTypeReferenceId="Verified.strongAuthenticationPhoneNumber" PartnerClaimType="Verified.OfficePhone" />
-  <!-- Indicates whether the new phone number has been entered by the user. The partner claim type must be set to `newPhoneNumberEntered`. -->
-  <OutputClaim ClaimTypeReferenceId="newPhoneNumberEntered" PartnerClaimType="newPhoneNumberEntered" />
-</OutputClaims>
-```
+|  Data type| Required | Description |
+|  -------- | ----------- |----------- |
+| boolean | Yes | Indicates whether the new phone number has been entered by the user. The claim name, or PartnerClaimType must be set to `newPhoneNumberEntered`|
+| string| Yes | The verified phone number. The claim name, or PartnerClaimType must be set to `Verified.OfficePhone`.|
 
-The OutputClaimsTransformations element may contain a collection of OutputClaimsTransformation elements that are used to modify the output claims or generate new ones.
+The OutputClaimsTransformations element may contain a collection of OutputClaimsTransformation elements that are used to modify the output claims, or generate new ones.
 
 ## Cryptographic keys
 
@@ -91,7 +90,9 @@ The **CryptographicKeys** element is not used.
 | Attribute | Required | Description |
 | --------- | -------- | ----------- |
 | ContentDefinitionReferenceId | Yes | The identifier of the [content definition](contentdefinitions.md) associated with this technical profile. |
-| ManualPhoneNumberEntryAllowed| No | Specify whether or not a user is allowed to manually enter a phone number. Possible values: `true` or `false` (default).|
+| ManualPhoneNumberEntryAllowed| No | Specify whether or not a user is allowed to manually enter a phone number. Possible values: `true`, or `false` (default).|
+| setting.authenticationMode | No | The method to validate the phone number. Possible values: `sms`, `phone`, or `mixed` (default).|
+| setting.autodial| No| Specify whether the technical profile should auto dial or auto send an SMS. Possible values: `true`, or `false` (default). Auto dial requires the `setting.authenticationMode` metadata be set to `sms`, or `phone`. The input claims collection must have a single phone number. |
 
 ### UI elements
 
@@ -100,4 +101,3 @@ The phone factor authentication page user interface elements can be [localized](
 ## Next steps
 
 - Check the [social and local accounts with MFA](https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/tree/master/SocialAndLocalAccountsWithMfa) starter pack.
-

articles/active-directory-b2c/phone-factor-technical-profile.md

@@ -9,7 +9,7 @@ manager: celestedg
 ms.service: active-directory
 ms.workload: identity
 ms.topic: reference
-ms.date: 02/13/2020
+ms.date: 03/30/2020
 ms.author: mimart
 ms.subservice: B2C
 ---
@@ -86,11 +86,32 @@ The **Name** attribute of the Protocol element needs to be set to `SAML2`.
 
 The **OutputClaims** element contains a list of claims returned by the SAML identity provider under the `AttributeStatement` section. You may need to map the name of the claim defined in your policy to the name defined in the identity provider. You can also include claims that aren't returned by the identity provider as long as you set the `DefaultValue` attribute.
 
-To read the SAML assertion **NamedId** in **Subject** as a normalized claim, set the claim **PartnerClaimType** to `assertionSubjectName`. Make sure the **NameId** is the first value in assertion XML. When you define more than one assertion, Azure AD B2C picks the subject value from the last assertion.
+### Subject name output claim
+
+To read the SAML assertion **NameId** in the **Subject** as a normalized claim, set the claim **PartnerClaimType** to value of the `SPNameQualifier` attribute. If the `SPNameQualifier`attribute is not presented, set the claim **PartnerClaimType** to value of the `NameQualifier` attribute. 
 
-The **OutputClaimsTransformations** element may contain a collection of **OutputClaimsTransformation** elements that are used to modify the output claims or generate new ones.
 
-The following example shows the claims returned by the Facebook identity provider:
+SAML assertion: 
+
+```XML
+<saml:Subject>
+  <saml:NameID SPNameQualifier="http://your-idp.com/unique-identifier" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">[email protected]</saml:NameID>
+	<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
+	  <SubjectConfirmationData InResponseTo="_cd37c3f2-6875-4308-a9db-ce2cf187f4d1" NotOnOrAfter="2020-02-15T16:23:23.137Z" Recipient="https://your-tenant.b2clogin.com/your-tenant.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" />
+    </SubjectConfirmation>
+  </saml:SubjectConfirmation>
+</saml:Subject>
+```
+
+Output claim:
+
+```XML
+<OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="http://your-idp.com/unique-identifier" />
+```
+
+If both `SPNameQualifier` or `NameQualifier` attributes are not presented in the SAML assertion, set the claim **PartnerClaimType** to `assertionSubjectName`. Make sure the **NameId** is the first value in assertion XML. When you define more than one assertion, Azure AD B2C picks the subject value from the last assertion.
+
+The following example shows the claims returned by a SAML identity provider:
 
 - The **issuerUserId** claim is mapped to the **assertionSubjectName** claim.
 - The **first_name** claim is mapped to the **givenName** claim.
@@ -115,6 +136,8 @@ The technical profile also returns claims that aren't returned by the identity p
 </OutputClaims>
 ```
 
+The **OutputClaimsTransformations** element may contain a collection of **OutputClaimsTransformation** elements that are used to modify the output claims or generate new ones.
+
 ## Metadata
 
 | Attribute | Required | Description |

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

@@ -93,6 +93,8 @@
           href: security-audit-events.md
         - name: Analyze audit events with Azure Monitor Workbooks
           href: use-azure-monitor-workbooks.md
+        - name: Secure remote access to VMs
+          href: secure-remote-vm-access.md
     - name: Domain-join VMs
       items:
         - name: Windows Server VM from template
@@ -149,7 +151,5 @@
       href: https://azure.microsoft.com/pricing/details/active-directory-ds/
     - name: Azure AD feedback forum
       href: https://feedback.azure.com/forums/169401-azure-active-directory
-    - name: Contact us
-      href: contact-us.md
     - name: Use Azure AD Domain Services in Azure CSP subscriptions
       href: csp.md

articles/active-directory-domain-services/TOC.yml

@@ -9,7 +9,7 @@ ms.service: active-directory
 ms.subservice: domain-services
 ms.workload: identity
 ms.topic: overview
-ms.date: 01/22/2020
+ms.date: 03/30/2020
 ms.author: iainfou
 
 #Customer intent: As an IT administrator or decision maker, I want to understand the differences between Active Directory Domain Services (AD DS), Azure AD, and Azure AD DS so I can choose the most appropriate identity solution for my organization.

articles/active-directory-domain-services/compare-identity-solutions.md

@@ -9,7 +9,7 @@ ms.service: active-directory
 ms.subservice: domain-services
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 11/19/2019
+ms.date: 03/30/2020
 ms.author: iainfou
 ---
 
@@ -106,11 +106,11 @@ The outbound forest trust for Azure AD Domain Services is created in the Azure p
 
 Many inter-domain and inter-forest transactions depend on domain or forest trusts in order to complete various tasks. This section describes the processes and interactions that occur as resources are accessed across trusts and authentication referrals are evaluated.
 
-### Overview of Authentication Referral Processing
+### Overview of authentication referral processing
 
 When a request for authentication is referred to a domain, the domain controller in that domain must determine whether a trust relationship exists with the domain from which the request comes. The direction of the trust and whether the trust is transitive or nontransitive must also be determined before it authenticates the user to access resources in the domain. The authentication process that occurs between trusted domains varies according to the authentication protocol in use. The Kerberos V5 and NTLM protocols process referrals for authentication to a domain differently
 
-### Kerberos V5 Referral Processing
+### Kerberos V5 referral processing
 
 The Kerberos V5 authentication protocol is dependent on the Net Logon service on domain controllers for client authentication and authorization information. The Kerberos protocol connects to an online Key Distribution Center (KDC) and the Active Directory account store for session tickets.
 
@@ -126,7 +126,7 @@ If the client uses Kerberos V5 for authentication, it requests a ticket to the s
     * If yes, send the client a referral to the next domain on the trust path.
     * If no, send the client a logon-denied message.
 
-### NTLM Referral Processing
+### NTLM referral processing
 
 The NTLM authentication protocol is dependent on the Net Logon service on domain controllers for client authentication and authorization information. This protocol authenticates clients that do not use Kerberos authentication. NTLM uses trusts to pass authentication requests between domains.
 
@@ -142,7 +142,7 @@ If the account does not exist in the database, the domain controller determines
     * If yes, pass the authentication request on to the next domain in the trust path. This domain controller repeats the process by checking the user's credentials against its own security accounts database.
     * If no, send the client a logon-denied message.
 
-### Kerberos-Based Processing of Authentication Requests Over Forest Trusts
+### Kerberos-based processing of authentication requests over forest trusts
 
 When two forests are connected by a forest trust, authentication requests made using the Kerberos V5 or NTLM protocols can be routed between forests to provide access to resources in both forests.
 

articles/active-directory-domain-services/concepts-forest-trust.md

@@ -9,7 +9,7 @@ ms.service: active-directory
 ms.subservice: domain-services
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 11/19/2019
+ms.date: 03/30/2020
 ms.author: iainfou
 ---
 

articles/active-directory-domain-services/concepts-resource-forest.md

@@ -10,7 +10,7 @@ ms.service: active-directory
 ms.subservice: domain-services
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 11/26/2019
+ms.date: 03/30/2020
 ms.author: iainfou
 
 ---
@@ -27,7 +27,7 @@ This article shows you how to create a gMSA in an Azure AD DS managed domain usi
 To complete this article, you need the following resources and privileges:
 
 * An active Azure subscription.
-    * If you don’t have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).
+    * If you don't have an Azure subscription, [create an account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).
 * An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.
     * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].
 * An Azure Active Directory Domain Services managed domain enabled and configured in your Azure AD tenant.