Merge pull request #47742 from MicrosoftDocs/master

7/30 AM Publish

Author: huypub

.openpublishing.redirection.json

@@ -26489,6 +26489,11 @@
         "source_path": "articles/china/china-get-started-service-availability.md",
         "redirect_url": "https://www.azure.cn/home/features/products-by-region",
         "redirect_document_id": true
+        },
+        {
+            "source_path": "articles/cognitive-services/video-indexer/video-indexer-output-json.md",
+            "redirect_url": "/azure/cognitive-services/video-indexer/video-indexer-output-json-v2",
+            "redirect_document_id": true
         }
     ]
 }

articles/active-directory/authentication/concept-authentication-methods.md

@@ -39,6 +39,20 @@ Microsoft highly recommends Administrators enable users to select more than the
 | Mobile app notification and Mobile app code as methods for Azure AD self-service password reset are public preview features of Azure Active Directory. For more information about previews, see  [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/)|
 |     |
 
+## Converged user registration (preview)
+
+Until now, users were required to register authentication methods for MFA and SSPR in two different portals. Many users were confused by the fact that similar methods were used in both MFA and SSPR and would not register in both portals. This led to some users being unable to use either MFA or SSPR when needed, leading to a helpdesk call, and an upset user.
+
+To enable your users to register authentication methods for both Azure Multi-Factor Authentication and self-service password reset, using the same portal, complete the following steps:
+
+1. Sign in to the Azure portal as a global administrator.
+1. Browse to **Azure Active Directory**, **User settings**, **Manage settings for access panel preview features**.
+1. Under **Users can use preview features for registering and managing security info**, you can choose to enable for a **Selected** group of users or for **All** users.
+
+Users can now use [https://aka.ms/setupsecurityinfo](https://aka.ms/setupsecurityinfo) to register for MFA and SSPR.
+
+![Preview Converged user registration - Add security info to your account for use with MFA and SSPR](media/concept-authentication-methods/concept-add-methods.png)
+
 ## Password
 
 Your Azure AD password is considered an authentication method. It is the one method that **cannot be disabled**.

articles/active-directory/b2b/compare-with-b2c.md

@@ -28,7 +28,7 @@ Identities supported: Employees with work or school accounts, partners with work
 Which directory the partner users are in: Partner users from the external organization are managed in the same directory as employees, but annotated specially. They can be managed the same way as employees, can be added to the same groups, and so on  | Which directory the customer user entities are in: In the application directory. Managed separately from the organization’s employee and partner directory (if any.
 Single sign-on (SSO) to all Azure AD-connected apps is supported. For example, you can provide access to Office 365 or on-premises apps, and to other SaaS apps such as Salesforce or Workday.  |  SSO to customer owned apps within the Azure AD B2C tenants is supported. SSO to Office 365 or to other Microsoft and non-Microsoft SaaS apps is not supported.
 Partner lifecycle: Managed by the host/inviting organization.  | Customer lifecycle: Self-serve or managed by the application.
-Security policy and compliance: Managed by the host/inviting organization.  | Security policy and compliance: Managed by the application.
+Security policy and compliance: Managed by the host/inviting organization (for example, with [conditional access policies](https://docs.microsoft.com/azure/active-directory/b2b/conditional-access)).  | Security policy and compliance: Managed by the application.
 Branding: Host/inviting organization’s brand is used.  |	Branding: Managed by application. Typically tends to be product branded, with the organization fading into the background.
 More info: [Blog post](https://blogs.technet.microsoft.com/enterprisemobility/2017/02/01/azure-ad-b2b-new-updates-make-cross-business-collab-easy/), [Documentation](what-is-b2b.md)  | More info: [Product page](https://azure.microsoft.com/services/active-directory-b2c/), [Documentation](https://docs.microsoft.com/azure/active-directory-b2c/)
 

articles/active-directory/b2b/media/use-dynamic-groups/exclude-guest-users.png

@@ -14,9 +14,9 @@ ms.devlang: na
 ms.topic: article
 ms.tgt_pltfrm: na
 ms.workload: identity
-ms.date: 04/24/2018
+ms.date: 07/26/2018
 ms.author: celested
-ms.reviewer: jmprieur
+ms.reviewer: jmprieur, andret, nacanuma, hirsin
 ms.custom: aaddev
 ---
 
@@ -168,7 +168,7 @@ In this scenario, when the user signs in, the JavaScript front end uses [Active
 1. The user signs in on the sign-in page.
 1. If authentication is successful, Azure AD creates an ID token and returns it as a URL fragment (#) to the application’s Reply URL. For a production application, this Reply URL should be HTTPS. The returned token includes claims about the user and Azure AD that are required by the application to validate the token.
 1. The JavaScript client code running in the browser extracts the token from the response to use in securing calls to the application’s web API back end.
-1. The browser calls the application’s web API back end with the access token in the authorization header.
+1. The browser calls the application’s web API back end with the ID token in the authorization header. The Azure AD authentication service issues an ID token that can be used as a bearer token if the resource is the same as the client ID (in this case, this is true as the web API is the app's own backend). 
 
 #### Code samples