Merge pull request #190308 from MicrosoftDocs/main

3/02 AM Publish

Author: huypub

articles/active-directory-b2c/multi-factor-authentication.md

@@ -122,7 +122,7 @@ In Azure AD B2C, you can delete a user's TOTP authenticator app enrollment. Then
 1. In the left menu, select **Users**.
 1. Search for and select the user for which you want to delete TOTP authenticator app enrollment.
 1. In the left menu, select **Authentication methods**.
-1. Under **Usable authentication methods**, find **Software OATH token (Preview)**, and then select the 3-dot menu next to it. If you don't see this interface, select **Switch to the new user authentication methods experience! Click here to use it now** to switch to the new authentication methods experience.
+1. Under **Usable authentication methods**, find **Software OATH token (Preview)**, and then select the ellipsis menu next to it. If you don't see this interface, select the option to **"Switch to the new user authentication methods experience! Click here to use it now"** to switch to the new authentication methods experience.
 1. Select **Delete**, and then select **Yes** to confirm. 
 
 :::image type="content" source="media/multi-factor-authentication/authentication-methods.png" alt-text="User authentication methods":::
@@ -137,4 +137,4 @@ Learn how to [delete a user's Software OATH token authentication method](/graph/
 
 - Learn about the [TOTP display control](display-control-time-based-one-time-password.md) and [Azure AD MFA technical profile](multi-factor-auth-technical-profile.md)
 
-::: zone-end
+::: zone-end

articles/active-directory-b2c/partner-bindid.md

@@ -120,7 +120,7 @@ You should now see BindID as a new OIDC Identity provider listed within your B2C
 
 2. Select **New user flow**
 
-3. Select **Sign up and sign in** > **Version** **Reccomended** > **Create**.
+3. Select **Sign up and sign in** > **Version Recommended** > **Create**.
 
 4. Enter a **Name** for your policy.
 

articles/active-directory/fundamentals/whats-new.md

@@ -159,6 +159,7 @@ You can now automate creating, updating, and deleting user accounts for these ne
 - [Gong](../saas-apps/gong-provisioning-tutorial.md)
 - [LanSchool Air](../saas-apps/lanschool-air-provisioning-tutorial.md)
 - [ProdPad](../saas-apps/prodpad-provisioning-tutorial.md)
+
 For more information about how to better secure your organization by using automated user account provisioning, see [Automate user provisioning to SaaS applications with Azure AD](../app-provisioning/user-provisioning.md).
 
 

articles/active-directory/reports-monitoring/recommendation-integrate-third-party-apps.md

@@ -0,0 +1,61 @@
+---
+title: Azure Active Directory recommendation - Integrate third party apps with Azure AD | Microsoft Docs
+description: Learn why you should integrate third party apps with Azure AD
+services: active-directory
+documentationcenter: ''
+author: MarkusVi
+manager: karenhoran
+editor: ''
+
+ms.assetid: 9b88958d-94a2-4f4b-a18c-616f0617a24e
+ms.service: active-directory
+ms.topic: reference
+ms.tgt_pltfrm: na
+ms.workload: identity
+ms.subservice: report-monitor
+ms.date: 03/02/2022
+ms.author: markvi
+ms.reviewer: hafowler
+
+ms.collection: M365-identity-device-management
+---
+
+# Azure AD recommendation: Integrate your third party apps 
+
+[Azure AD recommendations](overview-recommendations.md) is a feature that provides you with personalized insights and actionable guidance to align your tenant with recommended best practices.
+
+This article covers the recommendation to integrate third party apps. 
+
+
+## Description
+
+As an Azure AD admin responsible for managing applications, you want to use the Azure AD security features with your third party apps. Integrating these apps into Azure AD enables:
+
+- You to use one unified method to manage access to your third party apps.
+- Your users to benefit from using single sign-on to access all your apps with a single password.
+
+
+## Logic 
+
+If Azure AD determines that none of your users are using Azure AD to authenticate to your third party apps, this recommendation shows up.
+
+## Value 
+
+Integrating third party apps with Azure AD allows you to use Azure AD's security features.
+The integration:
+- Improves the productivity of your users.
+
+- Lowers your app management cost.
+
+You can then add an extra security layer by using conditional access to control how your users can access your apps.
+
+## Action plan
+
+1. Review the configuration of your apps. 
+2. For each app that isn't integrated into Azure AD yet, verify whether an integration is possible.
+ 
+
+## Next steps
+
+- [Tutorials for integrating SaaS applications with Azure Active Directory](../saas-apps/tutorial-list.md)
+- [Azure AD reports overview](overview-reports.md)

articles/active-directory/reports-monitoring/toc.yml

@@ -114,3 +114,7 @@
     href: reports-faq.yml
   - name: Sign-in log schema
     href: reference-azure-monitor-sign-ins-log-schema.md
+  - name: Recommendations
+    items:
+    - name: Integrate your third party apps
+      href: recommendation-integrate-third-party-apps.md

articles/active-directory/verifiable-credentials/how-to-dnsbind.md

@@ -7,7 +7,7 @@ manager: karenhoran
 ms.service: active-directory
 ms.topic: how-to
 ms.subservice: verifiable-credentials
-ms.date: 04/01/2021
+ms.date: 02/22/2022
 ms.author: barclayn
 
 #Customer intent: Why are we doing this?
@@ -17,15 +17,9 @@ ms.author: barclayn
 
 > [!IMPORTANT]
 > Azure Active Directory Verifiable Credentials is currently in public preview.
-> This preview version is provided without a service level agreement, and it's not recommended for production workloads. Certain features might not be supported or might have constrained capabilities. 
+> This preview version is provided without a service level agreement, and it's not recommended for production workloads. Certain features might not be supported or might have constrained capabilities.
 > For more information, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
 
-In this article:
-> [!div class="checklist"]
-> * Why do we need to link our DID to our domain?
-> * How do we link DIDs and domains?
-> * How does the domain linking process work?
-> * How does the verify/unverified domain logic work?
 
 ## Prerequisites
 
@@ -35,16 +29,20 @@ To link your DID to your domain, you need to have completed the following.
 
 ## Why do we need to link our DID to our domain?
 
-A DID starts out as an identifier that is not anchored to existing systems. A DID is useful because a user or organization can own it and control it. If an entity interacting with the organization does not know 'who' the DID belongs to, then the DID is not as useful.
+A DID starts out as an identifier that isn't anchored to existing systems. A DID is useful because a user or organization can own it and control it. If an entity interacting with the organization doesn't know 'who' the DID belongs to, then the DID isn't as useful.
 
 Linking a DID to a domain solves the initial trust problem by allowing any entity to cryptographically verify the relationship between a DID and a Domain.
 
+## When do you need to update the domain in your DID?
+
+In the event where the domain associated with your company changes, you would also need to change the domain in your DID document that is also published in the ION network. You can update the domain in your DID directly from the Azure AD Verifiable Credential portal.
+
 ## How do we link DIDs and domains?
 
-We make a link between a domain and a DID by implementing an open standard written by the Decentralized Identity Foundation called [Well-Known DID configuration](https://identity.foundation/.well-known/resources/did-configuration/). The verifiable credentials service in Azure Active Directory (Azure AD) helps your organization make the link between the DID and domain by including the domain information that you provided in your DID, and generating the well-known config file:
+We follow the [Well-Known DID configuration](https://identity.foundation/.well-known/resources/did-configuration/) specification when creating the link. The verifiable credentials service links your DID and domain. The service includes the domain information that you provided in your DID, and generates the well-known config file:
 
 1. Azure AD uses the domain information you provide during organization setup to write a Service Endpoint within the DID Document. All parties who interact with your DID can see the domain your DID proclaims to be associated with.  
-
+  
     ```json
     "service": [
       {
@@ -71,25 +69,25 @@ We make a link between a domain and a DID by implementing an open standard writt
     }
     ```
 
-After you have the well-known configuration file, you need to make the file available using the domain name you specified when enabling your AAD for verifiable credentials.
+After you have the well-known configuration file, you need to make the file available using the domain name you specified when you enabled your Azure AD for verifiable credentials.
 
-* Host the well-known DID configuration file at the root of the domain.
-* Do not use redirects.
-* Use https to distribute the configuration file.
+- Host the well-known DID configuration file at the root of the domain.
+- Don't use redirects.
+- Use https to distribute the configuration file.
 
 >[!IMPORTANT]
 >Microsoft Authenticator does not honor redirects, the URL specified must be the final destination URL.
 
-## User experience 
+## User experience in the wallet
 
-When a user is going through an issuance flow or presenting a verifiable credential, they should know something about organization and its DID. If the domain our verifiable credential wallet, Microsoft Authenticator, validates a DID's relationship with the domain in the DID document and presents users with two different experiences depending on the outcome.
+When a user is going through an issuance flow or presenting a verifiable credential, they should know something about the organization and its DID. Microsoft Authenticator, validates a DID's relationship with the domain in the DID document and presents users with two different experiences depending on the outcome.
 
 ## Verified domain
 
 Before Microsoft Authenticator displays a **Verified** icon, a few things need to be true:
 
 * The DID signing the self-issued open ID (SIOP) request must have a Service endpoint for Linked Domain.
-* The root domain does not use a redirect and uses https.
+* The root domain doesn't use a redirect and uses https.
 * The domain listed in the DID Document has a resolvable well-known resource.
 * The well-known resource's verifiable credential is signed with the same DID that was used to sign the SIOP that Microsoft Authenticator used to kick start the flow.
 
@@ -99,19 +97,47 @@ If all of the previously mentioned are true, then Microsoft Authenticator displa
 
 ## Unverified domain
 
-If any of the above are not true, the Microsoft Authenticator will display a full page warning to the user that the domain is unverified, the user is in the middle of a risky transaction and they should proceed with caution. We have chosen to take this route because:
+If any of the above aren't true, Microsoft Authenticator displays a full page warning to the user indicating that the domain is unverified. The user is warned that they are in the middle of a potential risky transaction and they should proceed with caution. We have chosen to take this route because:
 
 * The DID is either not anchored to a domain.
-* The configuration was not set up properly.
-* The DID the user is interacting with is malicious and actually can't prove they own a domain (since they actually don't). Due to this last point, it is imperative that you link your DID to the domain the user is familiar with, to avoid propagating the warning message.
+* The configuration wasn't set up properly.
+* The DID that the user is interacting with could be malicious and actually can't prove that they own the domain linked. 
+
+It is of high importance that you link your DID to a domain recognizable to the user.
 
 ![unverified domain warning in the add credential screen](media/how-to-dnsbind/add-credential-not-verified-authenticated.png)
 
-## Distribute well-known config
+## How do you update the linked domain on your DID?
+
+1. Navigate to the Verifiable Credentials | Getting Started page.  
+1. On the left side of the page select **Domain**.
+1. In the Domain box, enter your new domain name.
+1. Select **Publish**.
+
+:::image type="content" source="media/how-to-dnsbind/publish-update-domain.png" alt-text="Choose the publish button so your changes become":::
+
+It might take up to two hours for your DID document to be updated in the [ION network](https://identity.foundation/ion) with the new domain information. No other changes to the domain are possible before the changes are published.
+
+>[!NOTE]
+>If your changes are successful you will need to [verify](#verified-domain) your newly added domain.
 
-1. Navigate to the Settings page in Verifiable Credentials and choose **Verify this domain**
 
-   ![Verify this domain in settings](media/how-to-dnsbind/settings-verify.png) 
+:::image type="content" source="media/how-to-dnsbind/verification.png" alt-text="You need to verify your domain once that the publishing process completes":::
+
+### Do I need to wait for my DID Doc to be updated to verify my newly added domains?
+
+Yes. You need to wait until the config.json file gets updated before you publish it using your domain's hosting location.  
+
+### How do I know when the linked domain update has successfully completed?
+
+Once the domain changes are publised to ION, the domain section inside the Azure AD Verifiable Credentials service will display `Published` as the status and you should be able to make new changes to the domain. 
+
+>[!IMPORTANT]
+> No changes to your domain are possible while publishing is in progress.
+
+## Distribute well-known config
+
+1. From the Azure portal, navigate to the Verifiable Credentials page. Select **Domain** and choose **Verify this domain**
 
 2. Download the did-configuration.json file shown in the image below.
 
@@ -132,4 +158,4 @@ Congratulations, you now have bootstrapped the web of trust with your DID!
 
 ## Next steps
 
-If during onboarding you enter the wrong domain information or if you decide to change it, you will need to [opt out](how-to-opt-out.md). At this time, we don't support updating your DID document. Opting out and opting back in will create a brand new DID.
+- [How to customize your Azure Active Directory Verifiable Credentials](credential-design.md)