Merge branch 'master' into patch-37

Author: rboucher

.openpublishing.publish.config.json

@@ -247,6 +247,36 @@
       "url": "https://github.com/Azure-Samples/cognitive-services-qnamaker-python",
       "branch": "master",
       "branch_mapping": {}
+    },
+    {
+      "path_to_root": "cognitive-services-dotnet-sdk-samples",
+      "url": "https://github.com/Azure-Samples/cognitive-services-dotnet-sdk-samples",
+      "branch": "master",
+      "branch_mapping": {}
+    },
+    {
+      "path_to_root": "cognitive-services-java-sdk-samples",
+      "url": "https://github.com/Azure-Samples/cognitive-services-java-sdk-samples",
+      "branch": "master",
+      "branch_mapping": {}
+    },
+    {
+      "path_to_root": "aml-sdk-samples",
+      "url": "https://github.com/Azure/MachineLearningNotebooks",
+      "branch": "sdk-codetest",
+      "branch_mapping": {}
+    },
+    {
+      "path_to_root": "cognitive-services-vision-csharp-sdk-quickstarts",
+      "url": "https://github.com/Azure-Samples/cognitive-services-vision-csharp-sdk-quickstarts",
+      "branch": "master",
+      "branch_mapping": {}
+    },
+    {
+      "path_to_root": "cognitive-face-csharp-sample",
+      "url": "https://github.com/Azure-Samples/Cognitive-Face-CSharp-sample",
+      "branch": "master",
+      "branch_mapping": {}
     }
   ],
   "branch_target_mapping": {

.openpublishing.redirection.json

@@ -27052,11 +27052,6 @@
             "redirect_url": "/azure/cloud-shell/overview",
             "redirect_document_id": false
         },
-        {
-            "source_path": "articles/dms/index.md",
-            "redirect_url": "/azure/dms/dms-overview",
-            "redirect_document_id": false
-        },
         {
             "source_path": "articles/guides/developer/index.md",
             "redirect_url": "/azure/guides/developer/azure-developer-guide",
@@ -30515,6 +30510,17 @@
             "source_path": "articles/iot-central/howto-create-application.md",
             "redirect_url": "/azure/iot-central/quick-deploy-iot-central",
             "redirect_document_id" : false
+        },
+        {
+            "source_path": "articles/media-services/latest/create-account-cli-quickstart.md",
+            "redirect_url": "/azure/media-services/latest/create-account-cli-how-to",
+            "redirect_document_id" : false
+        },
+	    {  
+            "source_path": "articles/backup/backup-mabs-upgrade-to-v2.md",
+            "redirect_url": "/azure/backup/backup-mabs-whats-new-mabs",
+            "redirect_document_id" : false
         }
+
     ]
 }

articles/active-directory-b2c/active-directory-b2c-configure-signup-self-asserted-custom.md

@@ -273,8 +273,8 @@ Verified email is enabled by default in the `<TechnicalProfile Id="LocalAccountS
 
 ## Next steps
 
-Add the new claim to the flows for social account logins by changing the TechnicalProfiles listed below. These are used by social/federated account logins to write and read the user data using the alternativeSecurityId as the locator.
-```xml
-<TechnicalProfile Id="AAD-UserWriteUsingAlternativeSecurityId">
-<TechnicalProfile Id="AAD-UserReadUsingAlternativeSecurityId">
-```
+If your policy supports social accounts, add the new claim to the flows for social account logins by changing the technical profiles listed below. These claims are used by social account logins to collect and write data from the user.
+
+1. Locate the technical profile **SelfAsserted-Social** and add the output claim. The order of the claims in **OutputClaims** controls the order that Azure AD B2C renders the claims on the screen. For example, `<OutputClaim ClaimTypeReferenceId="city" />`.
+2. Locate the technical profile **AAD-UserWriteUsingAlternativeSecurityId** and add the persist claim. For example, `<PersistedClaim ClaimTypeReferenceId="city" />`.
+3. Locate the technical profile **AAD-UserReadUsingAlternativeSecurityId** and add the output claim. For example, `<OutputClaim ClaimTypeReferenceId="city" />`.

articles/active-directory-b2c/active-directory-b2c-custom-setup-adfs2016-idp.md

@@ -8,7 +8,7 @@ manager: mtillman
 ms.service: active-directory
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 11/05/2018
+ms.date: 11/07/2018
 ms.author: davidmu
 ms.component: B2C
 ---
@@ -22,19 +22,19 @@ This article shows you how to enable sign-in for an ADFS user account by using [
 ## Prerequisites
 
 - Complete the steps in [Get started with custom policies in Azure Active Directory B2C](active-directory-b2c-get-started-custom.md).
-- Make sure that you have access to the certificate .pfx file with the private key that was issued by ADFS.
+- Make sure that you have access to a certificate .pfx file with a private key. You can generate your own signed certificate and upload it to Azure AD B2C. Azure AD B2C uses this certificate to sign the SAML request sent to your SAML identity provider.
 
 ## Create a policy key
 
-You need to store your ADFS certificate in your Azure AD B2C tenant.
+You need to store your certificate in your Azure AD B2C tenant.
 
 1. Sign in to the [Azure portal](https://portal.azure.com/).
 2. Make sure you're using the directory that contains your Azure AD B2C tenant by clicking the **Directory and subscription filter** in the top menu and choosing the directory that contains your tenant.
 3. Choose **All services** in the top-left corner of the Azure portal, and then search for and select **Azure AD B2C**.
 4. On the Overview page, select **Identity Experience Framework - PREVIEW**.
 5. Select **Policy Keys** and then select **Add**.
 6. For **Options**, choose `Upload`.
-7. Enter a **Name** for the policy key. For example, `ADFSSamlCert`. The prefix `B2C_1A_` is added automatically to the name of your key.
+7. Enter a **Name** for the policy key. For example, `SamlCert`. The prefix `B2C_1A_` is added automatically to the name of your key.
 8. Browse to and select your certificate .pfx file with the private key.
 9. Click **Create**.
 

articles/active-directory-b2c/active-directory-b2c-devquickstarts-graph-dotnet.md

@@ -62,8 +62,8 @@ You now have an application that has permission to create, read and update users
 > 
 > 
 
-## Configure delete permissions for your application
-Currently, the *Read and write directory data* permission does **NOT** include the ability to do any deletions such as deleting users. If you want to give your application the ability to delete users, you'll need to do these extra steps that involve PowerShell, otherwise, you can skip to the next section.
+## Configure delete or update password permissions for your application
+Currently, the *Read and write directory data* permission does **NOT** include the ability to delete users or update user passwords. If you want to give your application the ability to delete users or update passwords, you'll need to do these extra steps that involve PowerShell, otherwise, you can skip to the next section.
 
 First, if you don't already have it installed, install the [Azure AD PowerShell v1 module (MSOnline)](https://docs.microsoft.com/powershell/azure/active-directory/install-msonlinev1?view=azureadps-1.0):
 
@@ -80,15 +80,15 @@ After you install the PowerShell module connect to your Azure AD B2C tenant.
 Connect-MsolService
 ```
 
-Now we'll use the **Application ID** in the script below to assign the application the user account administrator role which will allow it to delete users. These roles have well-known identifiers, so all you need to do is input your **Application ID** in the script below.
+Now we'll use the **Application ID** in the script below to assign the application the user account administrator role. These roles have well-known identifiers, so all you need to do is input your **Application ID** in the script below.
 
 ```powershell
 $applicationId = "<YOUR_APPLICATION_ID>"
 $sp = Get-MsolServicePrincipal -AppPrincipalId $applicationId
 Add-MsolRoleMember -RoleObjectId fe930be7-5e62-47db-91af-98c3a49a38b1 -RoleMemberObjectId $sp.ObjectId -RoleMemberType servicePrincipal
 ```
 
-Your application now also has permissions to delete users from your B2C tenant.
+Your application now also has permissions to delete users or update passwords from your B2C tenant.
 
 ## Download, configure, and build the sample code
 First, download the sample code and get it running. Then we will take a closer look at it.  You can [download the sample code as a .zip file](https://github.com/AzureADQuickStarts/B2C-GraphAPI-DotNet/archive/master.zip). You can also clone it into a directory of your choice:

articles/active-directory-b2c/active-directory-b2c-reference-oauth-code.md

@@ -17,8 +17,6 @@ ms.component: B2C
 You can use the OAuth 2.0 authorization code grant in apps installed on a device to gain access to protected resources, such as web APIs. By using the Azure Active Directory B2C (Azure AD B2C) implementation of OAuth 2.0, you can add sign-up, sign-in,
 and other identity management tasks to your mobile and desktop apps. This article is language-independent. In the article, we describe how to send and receive HTTP messages without using any open-source libraries.
 
-<!-- TODO: Need link to libraries -->
-
 The OAuth 2.0 authorization code flow is described in [section 4.1 of the OAuth 2.0 specification](http://tools.ietf.org/html/rfc6749). You can use it for authentication and authorization in most [application types](active-directory-b2c-apps.md), including web applications and natively installed applications. You can use the OAuth 2.0 authorization code flow to securely acquire access tokens and refresh tokens for your applications, which can be used to access resources that are secured by an [authorization server](active-directory-b2c-reference-protocols.md).  The refresh token allows the client to acquire new access (and refresh) tokens once the access token expires, typically after one hour.
 
 This article focuses on the **public clients** OAuth 2.0 authorization code flow. A public client is any client application that cannot be trusted to securely maintain the integrity of a secret password. This includes mobile apps, desktop applications, and essentially any application that runs on a device and needs to get access tokens. 
@@ -77,7 +75,7 @@ client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
 | redirect_uri |Required |The redirect URI of your app, where authentication responses are sent and received by your app. It must exactly match one of the redirect URIs that you registered in the portal, except that it must be URL-encoded. |
 | scope |Required |A space-separated list of scopes. A single scope value indicates to Azure Active Directory (Azure AD) both of the permissions that are being requested. Using the client ID as the scope indicates that your app needs an access token that can be used against your own service or web API, represented by the same client ID.  The `offline_access` scope indicates that your app needs a refresh token for long-lived access to resources. You also can use the `openid` scope to request an ID token from Azure AD B2C. |
 | response_mode |Recommended |The method that you use to send the resulting authorization code back to your app. It can be `query`, `form_post`, or `fragment`. |
-| state |Recommended |A value included in the request that is returned in the token response. It can be a string of any content that you want to use. Usually, a randomly generated unique value is  used, to prevent cross-site request forgery attacks. The state also is used to encode information about the user's state in the app before the authentication request occurred. For example, the page the user was on, or the policy that was being executed. |
+| state |Recommended |A value included in the request that can be a string of any content that you want to use. Usually, a randomly generated unique value is  used, to prevent cross-site request forgery attacks. The state also is used to encode information about the user's state in the app before the authentication request occurred. For example, the page the user was on, or the policy that was being executed. |
 | p |Required |The policy that is executed. It's the name of a policy that is created in your Azure AD B2C directory. The policy name value should begin with **b2c\_1\_**. To learn more about policies, see [Azure AD B2C built-in policies](active-directory-b2c-reference-policies.md). |
 | prompt |Optional |The type of user interaction that is required. Currently, the only valid value is `login`, which forces the user to enter their credentials on that request. Single sign-on will not take effect. |
 

articles/active-directory-b2c/claimsschema.md

@@ -105,7 +105,7 @@ The **Mask** element contains the following attributes:
 | Type | Yes | The type of the claim mask. Possible values: `Simple` or `Regex`. The `Simple` value indicates that a simple text mask is applied to the leading portion of a string claim. The `Regex` value indicates that a regular expression is applied to the string claim as whole.  If the `Regex` value is specified, an optional attribute must also be defined with the regular expression to use. |
 | Regex | No | If **Type** is set to `Regex`, specify the regular expression to use.
 
-The follwing example configures a **PhoneNumber** claim with the `Simple` mask:
+The following example configures a **PhoneNumber** claim with the `Simple` mask:
 
 ```XML
 <ClaimType Id="PhoneNumber">
@@ -120,7 +120,7 @@ The Identity Experience Framework renders the phone number while hiding the firs
 
 ![Using claim type with mask](./media/claimsschema/mask.png)
 
-The follwing example configures a **AlternateEmail** claim with the `Regex` mask:
+The following example configures a **AlternateEmail** claim with the `Regex` mask:
 
 ```XML
 <ClaimType Id="AlternateEmail">

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

@@ -42,7 +42,7 @@ The **InputClaims** and **InputClaimsTransformations** elements are not required
 
 ## Output claims
 
-The **OutputClaims** element contains a list of claims returned by the OAuth2 identity provider. 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 the you set the `DefaultValue` attribute.
+The **OutputClaims** element contains a list of claims returned by the OAuth2 identity provider. 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.
 
 The **OutputClaimsTransformations** element may contain a collection of **OutputClaimsTransformation** elements that are used to modify the output claims or generate new ones.
 

articles/active-directory-b2c/technical-profiles-overview.md

@@ -34,8 +34,7 @@ A technical profile enables these types of scenarios:
 - [SAML2](saml-technical-profile.md) - Federation with any SAML protocol identity provider.
 - [Self-Asserted](self-asserted-technical-profile.md) - Interact with the user. For example, collect the user's credential to sign in, render the sign-up page, or password reset.
 - **WsFed** - Federation with any WsFed protocol identity provider. 
-- **Session management** - Handle different types of sessions. 
-- **User journey context provider**
+- [Session management](active-directory-b2c-reference-sso-custom.md) - Handle different types of sessions. 
 - **Application insights**
 
 ## Technical profile flow
@@ -52,7 +51,7 @@ All types of technical profiles share the same concept. You send input claims, r
     - Create or update the user account.
     - Sends and verifies the MFA text message.
 4. **ValidationTechnicalProfiles** - For a [self asserted technical profile](self-asserted-technical-profile.md), you can call an input [validation technical profile](validation-technical-profile.md). The validation technical profile validates the data profiled by the user and returns an error message or Ok, with or without output claims. For example, before Azure AD B2C creates a new account, it checks whether the user already exists in the directory services. You can call a REST API technical profile to add your own business logic.<p>The scope of the output claims of a validation technical profile is limited to the technical profile that invokes the validation technical profile and other validation technical profiles under same technical profile. If you want to use the output claims in the next orchestration step, you need to add the output claims to the technical profile that invokes the validation technical profile.
-5. **OutputClaims** - Claims are retuned back to the claims bag. You can use those claims in the next orchestrations step, or output claims transformations.
+5. **OutputClaims** - Claims are returned back to the claims bag. You can use those claims in the next orchestrations step, or output claims transformations.
 6. **OutputClaimsTransformations** - Input claims of every output [claims transformation](claimstransformations.md) are picked up from the claims bag. The output claims of the technical profile from the previous steps can be input claims of an output claims transformation. After execution, the output claims are put back in the claims bag. The output claims of an output claims transformation can also be input claims of a subsequent output claims transformation.
 7. **Single sign-on (SSO) session management** - [SSO session management](active-directory-b2c-reference-sso-custom.md) controls interaction with a user after the user has already authenticated. For example, the administrator can control whether the selection of identity providers is displayed, or whether local account details need to be entered again.
 

articles/active-directory-b2c/technicalprofiles.md

@@ -268,7 +268,7 @@ The **UseTechnicalProfileForSessionManagement** element contains the following a
 | ReferenceId | Yes | An identifier of a technical profile already defined in the policy file or parent policy file. |
 
 ### EnabledForUserJourneys
-The **ClaimsProviderSelections** in a user journey defines the list of claims provider selection options and their order. With the **EnabledForUserJourneys** element  you filter, which claims provider is avaible to the user. The **EnabledForUserJourneys** element contains one of the following values:
+The **ClaimsProviderSelections** in a user journey defines the list of claims provider selection options and their order. With the **EnabledForUserJourneys** element  you filter, which claims provider is available to the user. The **EnabledForUserJourneys** element contains one of the following values:
 
 - **Always**, execute the technical profile.
 - **Never**, skip the technical profile.