Merge pull request #243188 from MicrosoftDocs/main

6/27/2023 PM Publish

articles/active-directory/authentication/how-to-mfa-authenticator-lite.md

@@ -25,11 +25,11 @@ Microsoft Authenticator Lite is another surface for Azure Active Directory (Azur
 Users receive a notification in Outlook mobile to approve or deny sign-in, or they can copy a TOTP to use during sign-in. 
 
 >[!NOTE]
->This is an important security enhancement for users authenticating via telecom transports. This feature is currently in the state ‘Microsoft managed’. Until June 26, leaving the feature set to ‘Microsoft managed’ will have no impact on your users and the feature will remain turned off unless you explicitly change the state to enabled. The Microsoft managed value of this feature will be changed from ‘disabled’ to ‘enabled’ on June 26. We have made some changes to the feature configuration, so if you made an update before GA (5/17), please validate that the feature is in the correct state for your tenant prior to June 26. If you do not wish for this feature to be enabled on June 26, move the state to ‘disabled’ or set users to include and exclude groups. 
+>This is an important security enhancement for users authenticating via telecom transports. On June 26, the Microsoft managed value of this feature changed from ‘disabled’ to ‘enabled’. If you no longer wish for this feature to be enabled, move the state from 'default' to‘disabled’ or set users to include and exclude groups. 
 
 ## Prerequisites
 
-- Your organization needs to enable Microsoft Authenticator (second factor) push notifications for some users or groups by using the Authentication methods policy. You can edit the Authentication methods policy by using the Azure portal or Microsoft Graph API.
+- Your organization needs to enable Microsoft Authenticator (second factor) push notifications for some users or groups by using the modern Authentication methods policy. You can edit the Authentication methods policy by using the Azure portal or Microsoft Graph API.
 
   >[!TIP]
   >We recommend that you also enable [system-preferred multifactor authentication (MFA)](concept-system-preferred-multifactor-authentication.md) when you enable Authenticator Lite. With system-preferred MFA enabled, users try to sign-in with Authenticator Lite before they try less secure telephony methods like SMS or voice call. 
@@ -45,23 +45,23 @@ Users receive a notification in Outlook mobile to approve or deny sign-in, or th
 
 ## Enable Authenticator Lite
 
-By default, Authenticator Lite is [Microsoft managed](concept-authentication-default-enablement.md#microsoft-managed-settings). Until June 26, leaving the feature set to ‘Microsoft managed’ will have no impact on your users and the feature will remain turned off unless you explicitly change the state to enabled. The Microsoft managed value of this feature will be changed from ‘disabled’ to ‘enabled’ on June 26. We have made some changes to the feature configuration, so if you made an update before GA (5/17), please validate that the feature is in the correct state for your tenant prior to June 26. If you do not wish for this feature to be enabled on June 26, move the state to ‘disabled’ or set users to include and exclude groups. 
+By default, Authenticator Lite is [Microsoft managed](concept-authentication-default-enablement.md#microsoft-managed-settings). On June 26, the Microsoft managed value of this feature changed from ‘disabled’ to ‘enabled’
 
-### Enablement Authenticator Lite in Azure portal UX
+### Disabling Authenticator Lite in Azure portal UX
 
-To enable Authenticator Lite in the Azure portal, complete the following steps:
+To disable Authenticator Lite in the Azure portal, complete the following steps:
 
   1. In the Azure portal, click Azure Active Directory > Security > Authentication methods > Microsoft Authenticator.
      In the Entra admin center, on the sidebar select Azure Active Directory > Protect & Secure > Authentication methods > Microsoft Authenticator.
 
-  2. On the Enable and Target tab, click Yes and All users to enable the policy for everyone or add selected users and groups. Set the Authentication mode for these users/groups to Any or Push.
+  2. On the Enable and Target tab, click Yes and All users to enable the Authenticator policy for everyone or add selected users and groups. Set the Authentication mode for these users/groups to Any or Push.
 
   Only users who are enabled for Microsoft Authenticator here can be enabled to use Authenticator Lite for sign-in, or excluded from it. Users who aren't enabled for Microsoft Authenticator can't see the feature. Users who have Microsoft Authenticator downloaded on the same device Outlook is downloaded on will not be prompted to register for Authenticator Lite in Outlook.
 
 <img width="1112" alt="Entra portal Authenticator settings" src="https://user-images.githubusercontent.com/108090297/228603771-52c5933c-f95e-4f19-82db-eda2ba640b94.png">
 
 
-  3. On the Configure tab, for **Microsoft Authenticator on companion applications**, change Status to Enabled, choose who to include or exclude from Authenticator Lite, and click Save.
+  3. On the Configure tab, for **Microsoft Authenticator on companion applications**, change Status to Disabled, and click Save.
 
 <img width="664" alt="Authenticator Lite configuration settings" src="https://user-images.githubusercontent.com/108090297/228603364-53f2581f-a4e0-42ee-8016-79b23e5eff6c.png">
 
@@ -163,6 +163,8 @@ Authenticator Lite enforces number matching in every authentication. If your ten
 To learn more about verification notifications, see [Microsoft Authenticator authentication method](concept-authentication-authenticator-app.md).
 
 ## Common questions
+### Are users on the legacy policy eligible for Authenticator Lite? 
+No, only those users configured for Authenticator app via the modern authentication methods policy are eligible for this experience. If your tenant is currently on the legacy policy and you are interested in this feature, please migrate your users to the modern auth policy.
 
 ### Does Authenticator Lite work as a broker app?
 No, Authenticator Lite is only available for push notifications and TOTP. 
@@ -186,8 +188,8 @@ Users that have Microsoft Authenticator on their device can't register Authentic
 ### SSPR Notifications
 TOTP codes from Outlook will work for SSPR, but the push notification will not work and will return an error.
 
-### Authentication Strengths
-If you have a configured authentication strength for MFA push, Authenticator Lite will not be allowed. This is a known issue that we are working to resolve.
+### Logs are showing additional conditional access evaluations
+The conditional access policies are evaluated each time a user opens their Outlook app, in order to determine whether the user is eligible to register for Authenticator Lite. These checks may appear in logs. 
 
 
 ## Next steps

articles/active-directory/external-identities/customers/overview-customers-ciam.md

@@ -8,7 +8,7 @@ ms.service: active-directory
 ms.workload: identity
 ms.subservice: ciam
 ms.topic: overview
-ms.date: 06/20/2023
+ms.date: 06/27/2023
 ms.author: mimart
 ms.custom: it-pro
 
@@ -96,6 +96,20 @@ Azure AD for customers represents the convergence of business-to-consumer (B2C)
 
 Learn more about the [security and governance](concept-security-customers.md) features that are available in a customer tenant.
 
+## About Azure AD B2C
+
+If you're a new customer, you might be wondering which solution is a better fit, [Azure AD B2C](../../../active-directory-b2c/index.yml) or Microsoft Entra External ID (preview). Opt for the current Azure AD B2C product if:
+
+- You have an immediate need to deploy a production ready build for customer-facing apps.
+
+   > [!NOTE]
+   > Keep in mind that the next generation Microsoft Entra External ID platform represents the future of CIAM for Microsoft, and rapid innovation, new features and capabilities will be focused on this platform. By choosing the next generation platform from the start, you will receive the benefits of rapid innovation and a future-proof architecture.
+
+Opt for the next generation Microsoft Entra External ID platform if:
+
+- You’re starting fresh building identities into apps or you're in the early stages of product discovery.
+- The benefits of rapid innovation, new features and capabilities are a priority.
+
 ## Next steps
 
 - Learn more about [planning for Azure AD for customers](concept-planning-your-solution.md).

articles/active-directory/external-identities/tenant-restrictions-v2.md

@@ -243,15 +243,15 @@ Suppose you use tenant restrictions to block access by default, but you want to
 
    :::image type="content" source="media/tenant-restrictions-v2/tenant-restrictions-external-users-organizational.png" alt-text="Screenshot showing selecting the external users allow access selections.":::
 
-1. Under **Applies to**, choose either **All <your tenant> users and groups** or **Select <your tenant> users and groups**. If you choose **Select <your tenant> users and groups**, perform these steps for each user or group you want to add:
+1. Under **Applies to**, choose either **All <organization> users and groups** or **Select <organization> users and groups**. If you choose **Select <organization> users and groups**, perform these steps for each user or group you want to add:
 
       - Select **Add external users and groups**.
       - In the **Select** pane, type the user name or group name in the search box.
       - Select the user or group in the search results.
       - If you want to add more, select **Add** and repeat these steps. When you're done selecting the users and groups you want to add, select **Submit**.
 
    > [!NOTE]
-   > For our Microsoft Accounts example, we select **All Contoso users and groups**.
+   > For our Microsoft Accounts example, we select **All Microsoft Accounts users and groups**.
 
    :::image type="content" source="media/tenant-restrictions-v2/tenant-restrictions-external-users-organizational-applies-to.png" alt-text="Screenshot showing selecting the external users and groups selections.":::
 

articles/active-directory/hybrid/connect/concept-azure-ad-connect-sync-user-and-contacts.md

@@ -20,16 +20,21 @@ ms.collection: M365-identity-device-management
 # Azure AD Connect sync: Understanding Users, Groups, and Contacts
 There are several different reasons why you would have multiple Active Directory forests and there are several different deployment topologies. Common models include an account-resource deployment and GAL sync’ed forests after a merger & acquisition. But even if there are pure models, hybrid models are common as well. The default configuration in Azure AD Connect sync doesn't assume any particular model but depending on how user matching was selected in the installation guide, different behaviors can be observed.
 
-In this topic, we'll go through how the default configuration behaves in certain topologies. We will go through the configuration and the Synchronization Rules Editor can be used to look at the configuration.
+In this topic, we go through how the default configuration behaves in certain topologies. We go through the configuration and the Synchronization Rules Editor can be used to look at the configuration.
 
 There are a few general rules the configuration assumes:
 * Regardless of which order we import from the source Active Directories, the end result should always be the same.
 * An active account will always contribute sign-in information, including **userPrincipalName** and **sourceAnchor**.
-* A disabled account will contribute userPrincipalName and sourceAnchor, unless it's a linked mailbox, if there's no active account to be found.
-* An account with a linked mailbox will never be used for userPrincipalName and sourceAnchor. It is assumed that an active account will be found later.
+* A disabled account contributes userPrincipalName and sourceAnchor, unless it's a linked mailbox, if there's no active account to be found.
+* An account with a linked mailbox will never be used for userPrincipalName and sourceAnchor. It's assumed that an active account will be found later.
 * A contact object might be provisioned to Azure AD as a contact or as a user. You don’t really know until all source Active Directory forests have been processed.
 
 ## Groups
+> [!NOTE]
+> Keep in mind that when you add a user from another forest to the group, there is an anchor created in the Active Directory where the groups exists inside a specific OU. This anchor is a Foreign security principal and is stored inside the OU ‘ForeignSecurityPrincipals’. If you don't synchronize this OU the users where removed from the group membership.
+> 
+> 
+
 Important points to be aware of when synchronizing groups from Active Directory to Azure AD:
 
 * Azure AD Connect excludes built-in security groups from directory synchronization.
@@ -51,19 +56,19 @@ Important points to be aware of when synchronizing groups from Active Directory
       * An Active Directory group whose proxyAddress attribute has values *{"X500:/0=contoso.com/ou=users/cn=testgroup", "smtp:johndoe\@contoso.com"}* will also be mail-enabled in Azure AD.
 
 ## Contacts
-Having contacts representing a user in a different forest is common after a merger & acquisition where a GALSync solution is bridging two or more Exchange forests. The contact object is always joining from the connector space to the metaverse using the mail attribute. If there's already a contact object or user object with the same mail address, the objects are joined together. This is configured in the rule **In from AD – Contact Join**. There is also a rule named **In from AD – Contact Common** with an attribute flow to the metaverse attribute **sourceObjectType** with the constant **Contact**. This rule has very low precedence so if any user object is joined to the same metaverse object, then the rule **In from AD – User Common** will contribute the value User to this attribute. With this rule, this attribute will have the value Contact if no user has been joined and the value User if at least one user has been found.
+Having contacts representing a user in a different forest is common after a merger & acquisition where a GALSync solution is bridging two or more Exchange forests. The contact object is always joining from the connector space to the metaverse using the mail attribute. If there's already a contact object or user object with the same mail address, the objects are joined together. This is configured in the rule **In from AD – Contact Join**. There is also a rule named **In from AD – Contact Common** with an attribute flow to the metaverse attribute **sourceObjectType** with the constant **Contact**. This rule has low precedence so if any user object is joined to the same metaverse object, then the rule **In from AD – User Common** will contribute the value User to this attribute. With this rule, this attribute has the value Contact if no user has been joined and the value User if at least one user has been found.
 
 For provisioning an object to Azure AD, the outbound rule **Out to AAD – Contact Join** will create a contact object if the metaverse attribute **sourceObjectType** is set to **Contact**. If this attribute is set to **User**, then the rule **Out to AAD – User Join** will create a user object instead.
 It is possible that an object is promoted from Contact to User when more source Active Directories are imported and synchronized.
 
-For example, in a GALSync topology we'll find contact objects for everyone in the second forest when we import the first forest. This will stage new contact objects in the Azure AD Connector. When we later import and synchronize the second forest, we'll find the real users and join them to the existing metaverse objects. We will then delete the contact object in Azure AD and create a new user object instead.
+For example, in a GALSync topology we find contact objects for everyone in the second forest when we import the first forest. This stages new contact objects in the Azure AD Connector. When we later import and synchronize the second forest, we find the real users and join them to the existing metaverse objects. We will then delete the contact object in Azure AD and create a new user object instead.
 
-If you have a topology where users are represented as contacts, make sure you select to match users on the mail attribute in the installation guide. If you select another option, then you will have an order-dependent configuration. Contact objects will always join on the mail attribute, but user objects will only join on the mail attribute if this option was selected in the installation guide. You could then end up with two different objects in the metaverse with the same mail attribute if the contact object was imported before the user object. During export to Azure AD, an error will be thrown. This behavior is by design and would indicate bad data or that the topology was not correctly identified during the installation.
+If you have a topology where users are represented as contacts, make sure you select to match users on the mail attribute in the installation guide. If you select another option, then you have an order-dependent configuration. Contact objects will always join on the mail attribute, but user objects will only join on the mail attribute if this option was selected in the installation guide. You could then end up with two different objects in the metaverse with the same mail attribute if the contact object was imported before the user object. During export to Azure AD, an error is shown. This behavior is by design and would indicate bad data or that the topology was not correctly identified during the installation.
 
 ## Disabled accounts
 Disabled accounts are synchronized as well to Azure AD. Disabled accounts are common to represent resources in Exchange, for example conference rooms. The exception is users with a linked mailbox; as previously mentioned, these will never provision an account to Azure AD.
 
-The assumption is that if a disabled user account is found, then we won't find another active account later and the object is provisioned to Azure AD with the userPrincipalName and sourceAnchor found. In case another active account will join to the same metaverse object, then its userPrincipalName and sourceAnchor will be used.
+The assumption is that if a disabled user account is found, then we won't find another active account later and the object is provisioned to Azure AD with the userPrincipalName and sourceAnchor found. In case another active account join to the same metaverse object, then its userPrincipalName and sourceAnchor will be used.
 
 ## Changing sourceAnchor
 When an object has been exported to Azure AD then it's not allowed to change the sourceAnchor anymore. When the object has been exported the metaverse attribute **cloudSourceAnchor** is set with the **sourceAnchor** value accepted by Azure AD. If **sourceAnchor** is changed and not match **cloudSourceAnchor**, the rule **Out to AAD – User Join** will throw the error **sourceAnchor attribute has changed**. In this case, the configuration or data must be corrected so the same sourceAnchor is present in the metaverse again before the object can be synchronized again.

articles/active-directory/privileged-identity-management/azure-pim-resource-rbac.md

@@ -3,7 +3,7 @@ title: View audit report for Azure resource roles in Privileged Identity Managem
 description: View activity and audit history for Azure resource roles in Azure AD Privileged Identity Management (PIM).
 services: active-directory
 documentationcenter: ''
-author: amsliu
+author: billmath
 manager: amycolannino
 editor: ''
 
@@ -12,7 +12,7 @@ ms.subservice: pim
 ms.topic: how-to
 ms.workload: identity
 ms.date: 06/24/2022
-ms.author: amsliu
+ms.author: billmath
 ms.reviewer: shaunliu
 ms.collection: M365-identity-device-management
 ---

articles/active-directory/privileged-identity-management/concept-pim-for-groups.md

@@ -3,7 +3,7 @@ title: Privileged Identity Management (PIM) for Groups
 description: How to manage Azure AD Privileged Identity Management (PIM) for Groups.
 services: active-directory
 documentationcenter: ''
-author: amsliu
+author: billmath
 manager: amycolannino
 ms.assetid: 
 ms.service: active-directory
@@ -12,7 +12,7 @@ ms.topic: overview
 ms.tgt_pltfrm: na
 ms.workload: identity
 ms.date: 6/7/2023
-ms.author: amsliu
+ms.author: billmath
 ms.custom: pim 
 ms.collection: M365-identity-device-management