Merge pull request #115859 from MicrosoftDocs/master

5/20 AM Publish

Author: huypub

articles/active-directory/app-provisioning/how-provisioning-works.md

@@ -9,7 +9,7 @@ ms.service: active-directory
 ms.subservice: app-provisioning
 ms.topic: conceptual
 ms.workload: identity
-ms.date: 12/10/2019
+ms.date: 05/20/2020
 ms.author: mimart
 ms.reviewer: arvinh
 ---
@@ -59,7 +59,7 @@ When you configure provisioning to a SaaS application, one of the types of attri
 
 For outbound provisioning from Azure AD to a SaaS application, relying on [user or group assignments](../manage-apps/assign-user-or-group-access-portal.md) is the most common way to determine which users are in scope for provisioning. Because user assignments are also used for enabling single sign-on, the same method can be used for managing both access and provisioning. Assignment-based scoping doesn't apply to inbound provisioning scenarios such as Workday and Successfactors.
 
-* **Groups.** With an Azure AD Premium license plan, you can use groups to assign access to a SaaS application. Then, when the provisioning scope is set to **Sync only assigned users and groups**, the Azure AD provisioning service will provision or de-provision users based on whether they're members of a group that's assigned to the application. The group object itself isn't provisioned unless the application supports group objects. Ensure that groups assigned to your application have the property "SecurityEnabled" set to "False".
+* **Groups.** With an Azure AD Premium license plan, you can use groups to assign access to a SaaS application. Then, when the provisioning scope is set to **Sync only assigned users and groups**, the Azure AD provisioning service will provision or de-provision users based on whether they're members of a group that's assigned to the application. The group object itself isn't provisioned unless the application supports group objects. Ensure that groups assigned to your application have the property "SecurityEnabled" set to "True".
 
 * **Dynamic groups.** The Azure AD user provisioning service can read and provision users in [dynamic groups](../users-groups-roles/groups-create-rule.md). Keep these caveats and recommendations in mind:
 

articles/active-directory/b2b/facebook-federation.md

@@ -20,6 +20,7 @@ ms.collection: M365-identity-device-management
 # Add Facebook as an identity provider for External Identities
 
 You can add Facebook to your self-service sign-up user flows (Preview) so that users can sign in to your applications using their own Facebook accounts. To allow users to sign in using Facebook, you'll first need to [enable self-service sign-up](self-service-sign-up-user-flow.md) for your tenant. After you add Facebook as an identity provider, set up a user flow for the application and select Facebook as one of the sign-in options.
+
 > [!NOTE]
 > Users can only use their Facebook accounts to sign up through apps using self-service sign-up and user flows. Users cannot be invited and redeem their invitation using a Facebook account.
 

articles/active-directory/b2b/identity-providers.md

@@ -20,16 +20,30 @@ ms.collection: M365-identity-device-management
 
 An *identity provider* creates, maintains, and manages identity information while providing authentication services to applications. When sharing your apps and resources with external users, Azure AD is the default identity provider for sharing. This means when you invite external users who already have an Azure AD or Microsoft account, they can automatically sign in without further configuration on your part.
 
-However, you can enable users to sign in with various identity providers. For example, you can set up federation with social identity providers that are supported by Azure AD, including Google and Facebook. You can also federate with any external identity provider that supports the SAML or WS-Fed protocols. With external identity provider federation, you can offer external users the ability to sign in to your apps with their existing social or enterprise accounts.
+However, you can enable users to sign in with various identity providers.
+
+- **Google**: Google federation allows external users to redeem invitations from you by signing in to your apps with their own Gmail accounts. Google federation can also be used in your self-service sign-up user flows.
+   > [!NOTE]
+   > In the current self-service sign-up preview, if a user flow is associated with an app and you send a user an invitation to that app, the user won't be able to use a Gmail account to redeem the invitation. As a workaround, the user can go through the self-service sign-up process. Or, they can redeem the invitation by accessing a different app or by using their My Apps portal at https://myapps.microsoft.com.
+
+- **Facebook**: When building an app, you can configure self-service sign-up and enable Facebook federation so that users can sign up for your app using their own Facebook accounts. Facebook can only be used for self-service sign-up user flows and isn't available as a sign-in option when users are redeeming  invitations from you.
+
+- **Direct federation**: You can also set up direct federation with any external identity provider that supports the SAML or WS-Fed protocols. Direct federation allows external users to redeem invitations from you by signing in to your apps with their existing social or enterprise accounts. 
+   > [!NOTE]
+   > Direct federation identity providers can't be used in your self-service sign-up user flows.
+
 
 ## How it works
 
-Azure AD External Identities is preconfigured for federation with Google and Facebook. To set up these identity providers in your Azure AD tenant, you'll create an application at each identity provider and configure credentials. You'll obtain a client or app ID and a client or app secret, which you can then add to your Azure AD tenant.
+The Azure AD External Identities self-service sign up feature allows users to sign up with their Azure AD, Google, or Facebook account. To set up social identity providers in your Azure AD tenant, you'll create an application at each identity provider and configure credentials. You'll obtain a client or app ID and a client or app secret, which you can then add to your Azure AD tenant.
 
 Once you've added an identity provider to your Azure AD tenant:
 
 - When you invite an external user to apps or resources in your organization, the external user can sign in using their own account with that identity provider.
-- When you enable [self-service sign-up](self-service-sign-up-overview.md) for your apps, external users can sign up for your apps using their own accounts with the identity providers you've added. 
+- When you enable [self-service sign-up](self-service-sign-up-overview.md) for your apps, external users can sign up for your apps using their own accounts with the identity providers you've added.
+
+> [!NOTE]
+> Azure AD is enabled by default for self-service sign-up, so users always have the option of signing up using an Azure AD account.
 
 When redeeming your invitation or signing up for your app, the external user has the option to sign in and authenticate with the social identity provider:
 

articles/active-directory/b2b/self-service-sign-up-overview.md

@@ -22,17 +22,20 @@ ms.collection: M365-identity-device-management
 | Self-service sign-up is a public preview feature 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/).|
 |     |
 
-When sharing applications with external users, you might not always know in advance who will need access to an application. As an alternative to sending invitations directly to individuals, you can allow external users to sign up for specific applications themselves by enabling self-service sign-up. You can create a personalized sign-up experience by customizing the self-service sign-up user flow. For example, you can provide options for Azure AD or social identity providers and collect information about the user.
+When sharing an application with external users, you might not always know in advance who will need access to the application. As an alternative to sending invitations directly to individuals, you can allow external users to sign up for specific applications themselves by enabling self-service sign-up. You can create a personalized sign-up experience by customizing the self-service sign-up user flow. For example, you can provide options to sign up with Azure AD or social identity providers and collect information about the user during the sign-up process.
+
+> [!NOTE]
+> You can associate user flows with apps built by your organization. User flows can't be used for Microsoft apps, like SharePoint or Teams.
 
 ## User flow for self-service sign-up
 
-A self-service sign-up user flow creates a sign-up experience for your external users through the application you want to share. The user flow can be associated with one or more of your applications. First you'll enable self-service sign-up for your tenant and federate with any identity providers you want to allow external users to use for sign-in. Then you'll create and customize the sign-up user flow and assign your applications to it.
+A self-service sign-up user flow creates a sign-up experience for your external users through the application you want to share. The user flow can be associated with one or more of your applications. First you'll enable self-service sign-up for your tenant and federate with the identity providers you want to allow external users to use for sign-in. Then you'll create and customize the sign-up user flow and assign your applications to it.
 You can configure user flow settings to control how the user signs up for the application:
 
 - Account types used for sign-in, such as social accounts like Facebook, or Azure AD accounts
 - Attributes to be collected from the user signing up, such as first name, postal code, or country of residency
 
-When a user wants to sign in to your application, whether it's a web, mobile, desktop, or single-page application (SPA), the application initiates an authorization request to the user flow-provided endpoint. The user flow defines and controls the user's experience. When they complete a sign-up user flow, Azure AD generates a token, then redirects the user back to your application. Multiple applications can use the same user flow.
+When a user wants to sign in to your application, whether it's a web, mobile, desktop, or single-page application (SPA), the application initiates an authorization request to the user flow-provided endpoint. The user flow defines and controls the user's experience. When the user completes the sign-up user flow, Azure AD generates a token and redirects the user back to your application. Upon completion of sign-up, a guest account is provisioned for the user in the directory. Multiple applications can use the same user flow.
 
 ## Example of self-service sign-up
 
@@ -45,7 +48,7 @@ They use the email of their choice to sign up.
 
 ![Example showing selection of Facebook for sign-in](media/self-service-sign-up-overview/example-sign-in-with-facebook.png)
 
-Azure AD creates a relationship with Woodgrove using the partner's Facebook account, and creates a new account.
+Azure AD creates a relationship with Woodgrove using the partner's Facebook account, and creates a new guest account for the user after they sign up.
 
 Woodgrove wants to know more about the user, like name, business name, business registration code, phone number.
 

articles/active-directory/b2b/self-service-sign-up-user-flow.md

@@ -22,17 +22,23 @@ ms.collection: M365-identity-device-management
 | Self-service sign-up is a public preview feature 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/).|
 |     |
 
-Associating your user flow with an application allows you to enable sign-up on that app. You can choose more than one application to be associated with the user flow. Once you associate the user flow with one or more applications, users who visit that app will be able to sign up using the options configured in the user flow.
+You can create user flows for apps that are built by your organization. Associating your user flow with an application allows you to enable sign-up on that app. You can choose more than one application to be associated with the user flow. Once you associate the user flow with one or more applications, users who visit that app will be able to sign up and gain a guest account using the options configured in the user flow.
+
+> [!NOTE]
+> You can associate user flows with apps built by your organization. User flows can't be used for Microsoft apps, like SharePoint or Teams.
 
 ## Before you begin
 
 ### Add social identity providers (optional)
 
 Azure AD is the default identity provider for self-service sign-up. This means that users are able to sign up by default with an Azure AD account. Social identity providers can also be included in these sign-up flows to support Google and Facebook accounts.
 
-- [Add Google to your list of social identity providers](google-federation.md)
 - [Add Facebook to your list of social identity providers](facebook-federation.md)
- 
+- [Add Google to your list of social identity providers](google-federation.md)
+
+> [!NOTE]
+> In the current preview, if a self-service sign-up user flow is associated with an app and you send a user an invitation to that app, the user won't be able to use a Gmail account to redeem the invitation. As a workaround, the user can go through the self-service sign-up process. Or, they can redeem the invitation by accessing a different app or by using their My Apps portal at https://myapps.microsoft.com.
+
 ### Define custom attributes (optional)
 
 User attributes are values collected from the user during self-service sign-up. Azure AD comes with a built-in set of attributes, but you can create custom attributes for use in your user flow. You can also read and write these attributes by using the Microsoft Graph API. See [Define custom attributes for user flows](user-flow-add-custom-attributes.md).

articles/active-directory/hybrid/how-to-connect-sync-endpoint-api-v2.md

@@ -8,7 +8,7 @@ editor: ''
 ms.service: active-directory
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 05/19/2020
+ms.date: 05/20/2020
 ms.subservice: hybrid
 ms.author: billmath
 ms.collection: M365-identity-device-management
@@ -27,6 +27,9 @@ Microsoft has deployed a new endpoint (API) for Azure AD Connect that improves t
 ## Pre-requisites  
 In order to use the new V2 endpoint, you will need to use [Azure AD Connect version 1.5.30.0](https://www.microsoft.com/download/details.aspx?id=47594) or later and follow the deployment steps provided below to enable the V2 endpoint for your Azure AD Connect server.   
 
+>[!NOTE]
+>Currently, this public preview is only available in the Azure global cloud and not available for [national clouds](https://docs.microsoft.com/azure/active-directory/develop/authentication-national-cloud).
+
 ### Public preview limitations  
 While this release has undergone extensive testing, you may still encounter issues. One of the goals of this public preview release is to find and fix any such issues.  
 

articles/active-directory/manage-apps/configure-user-consent.md

@@ -44,7 +44,7 @@ To configure user consent settings through the Azure portal:
 1. Under **User consent for applications**, select which consent setting you'd like to configure for all users.
 1. Select **Save** to save your settings.
 
-![User consent settings](./media/configure-user-consent/configure-consent-setting-for-all-users.png)
+![User consent settings](./media/configure-user-consent/setting-for-all-users.png)
 
 > [!TIP]
 > Consider [enabling the admin consent workflow](configure-admin-consent-workflow.md) to allow users to request an administrator's review and approval of an application that the user is not allowed to consent to--for example, when user consent has been disabled or when an application is requesting permissions that the user is not allowed to grant.
@@ -97,7 +97,7 @@ Permission classifications allow you to identify the impact that different permi
 
 In this example, we've classified the minimum set of permission required for single sign-on:
 
-![Permission classifications](./media/configure-user-consent/configure-permission-classifications.png)
+![Permission classifications](./media/configure-user-consent/permission-classifications.png)
 
 > [!TIP]
 > For the Microsoft Graph API, the minimum permissions needed to do basic single sign on are `openid`, `profile`, `User.Read` and `offline_access`. With these permissions an app can read the profile details of the signed-in user and can maintain this access even when the user is no longer using the app.
@@ -187,7 +187,7 @@ You can configure which users are allowed to consent to apps accessing their gro
 
 In this example, all group owners are allowed to consent to apps accessing their groups' data:
 
-![Permission classifications](./media/configure-user-consent/configure-group-owner-consent.png)
+![Permission classifications](./media/configure-user-consent/group-owner-consent.png)
 
 ### Configure group owner consent using PowerShell