Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into split-ot-install

Author: yoninalmsft

articles/active-directory/cloud-sync/how-to-configure.md

@@ -43,6 +43,10 @@ To configure provisioning, follow these steps.
  7. Enter a **Notification email**. This email will be notified when provisioning isn't healthy.  It is recommended that you keep **Prevent accidental deletion** enabled and set the **Accidental deletion threshold** to a number that you wish to be notified about.  For more information, see [accidental deletes](#accidental-deletions) below.
  8. Move the selector to Enable, and select Save.
 
+ >[!NOTE]
+ >  During the configuration process the synchronization service account will be created with the format **ADToAADSyncServiceAccount@[TenantID].onmicrosoft.com** and you may get an error if multi-factor authentication is enabled for the synchronization service account, or other interactive authentication policies are accidentally enabled for the synchronization account. Removing multi-factor authentication or any interactive authentication policies for the synchronization service account should resolve the error and you can complete the configuration smoothly.
+
+
 ## Scope provisioning to specific users and groups
 You can scope the agent to synchronize specific users and groups by using on-premises Active Directory groups or organizational units. You can't configure groups and organizational units within a configuration. 
  >[!NOTE]

articles/active-directory/manage-apps/configure-authentication-for-federated-users-portal.md

@@ -8,7 +8,7 @@ ms.service: active-directory
 ms.subservice: app-mgmt
 ms.workload: infrastructure-services
 ms.topic: how-to
-ms.date: 02/09/2022
+ms.date: 01/02/2023
 ms.author: ludwignick
 ms.custom: seoapril2019, contperf-fy22q2
 ms.collection: M365-identity-device-management
@@ -19,7 +19,11 @@ zone_pivot_groups: home-realm-discovery
 
 # Configure sign-in behavior using Home Realm Discovery
 
-This article provides an introduction to configuring Azure Active Directory(Azure AD) authentication behavior for federated users using Home Realm Discovery (HRD) policy.  It covers using auto-acceleration to skip the username entry screen and automatically forward users to federated login endpoints. To learn more about HRD policy, see [Home Realm Discovery](home-realm-discovery-policy.md)
+This article provides an introduction to configuring Azure Active Directory (Azure AD) authentication behavior for federated users using Home Realm Discovery (HRD) policy. It covers using auto-acceleration sign-in to skip the username entry screen and automatically forward users to federated login endpoints. To learn more about HRD policy, check out the [Home Realm Discovery](home-realm-discovery-policy.md) article.
+
+## Auto-acceleration sign-in
+
+Some organizations configure domains in their Azure AD tenant to federate with another identity provider (IDP), such as AD FS for user authentication. When a user signs into an application, they're first presented with an Azure AD sign-in page. After they've typed their UPN, if they are in a federated domain they're then taken to the sign-in page of the IDP serving that domain. Under certain circumstances, administrators might want to direct users to the sign-in page when they're signing in to specific applications. As a result users can skip the initial Azure AD page. This process is referred to as "sign-in auto-acceleration." 
 
 For federated users with cloud-enabled credentials, such as SMS sign-in or FIDO keys, you should prevent sign-in auto-acceleration. See [Disable auto-acceleration sign-in](prevent-domain-hints-with-home-realm-discovery.md) to learn how to prevent domain hints with HRD. 
 
@@ -77,11 +81,11 @@ If nothing is returned, it means you have no policies created in your tenant.
 
 In this example, you create a policy that when it's assigned to an application either:
 
-- Auto-accelerates users to an federated identity provider sign-in screen when they are signing in to an application when there is a single domain in your tenant.
-- Auto-accelerates users to an federated identity provider sign-in screen if there is more than one federated domain in your tenant.
+- Auto-accelerates users to a federated identity provider sign-in screen when they're signing in to an application when there's a single domain in your tenant.
+- Auto-accelerates users to a federated identity provider sign-in screen if there's more than one federated domain in your tenant.
 - Enables non-interactive username/password sign-in directly to Azure AD for federated users for the applications the policy is assigned to.
 
-The following policy auto-accelerates users to an federated identity provider sign-in screen when they're signing in to an application when there's a single domain in your tenant.
+The following policy auto-accelerates users to a federated identity provider sign-in screen when they're signing in to an application when there's a single domain in your tenant.
 
 ::: zone pivot="powershell-hrd"
 
@@ -99,7 +103,7 @@ New-AzureADPolicy -Definition @("{`"HomeRealmDiscoveryPolicy`":{`"AccelerateToFe
 ```
 ::: zone-end
 
-The following policy auto-accelerates users to an federated identity provider sign-in screen when there is more than one federated domain in your tenant. If you have more than one federated domain that authenticates users for applications, you need to specify the domain to auto-accelerate.
+The following policy auto-accelerates users to a federated identity provider sign-in screen when there's more than one federated domain in your tenant. If you've more than one federated domain that authenticates users for applications, you need to specify the domain to auto-accelerate.
 
 ::: zone pivot="powershell-hrd"
 
@@ -147,15 +151,15 @@ To see your new policy and get its **ObjectID**, run the following command:
 Get-AzureADPolicy
 ```
 
-To apply the HRD policy after you have created it, you can assign it to multiple application service principals.
+To apply the HRD policy after you've created it, you can assign it to multiple application service principals.
 
 ## Locate the service principal to which to assign the policy
 
 You need the **ObjectID** of the service principals to which you want to assign the policy. There are several ways to find the **ObjectID** of service principals.
 
 You can use the [Azure portal](https://portal.azure.com), or you can query [Microsoft Graph](/graph/api/resources/serviceprincipal). You can also go to the [Graph Explorer Tool](https://developer.microsoft.com/graph/graph-explorer) and sign in to your Azure AD account to see all your organization's service principals.
 
-Because you are using PowerShell, you can use the following cmdlet to list the service principals and their IDs.
+Because you're using PowerShell, you can use the following cmdlet to list the service principals and their IDs.
 
 ```powershell
 Get-AzureADServicePrincipal
@@ -255,4 +259,5 @@ From the Microsoft Graph explorer window:
 
 ## Next steps
 
-[Prevent sign-in auto-acceleration](prevent-domain-hints-with-home-realm-discovery.md).
+- [Prevent sign-in auto-acceleration](prevent-domain-hints-with-home-realm-discovery.md)
+- [Home Realm Discovery for an application](./home-realm-discovery-policy.md)

articles/active-directory/manage-apps/home-realm-discovery-policy.md

@@ -8,14 +8,14 @@ ms.service: active-directory
 ms.subservice: app-mgmt
 ms.topic: conceptual
 ms.workload: identity
-ms.date: 08/24/2022
+ms.date: 01/02/2023
 ms.author: ludwignick
 ms.reviewer: sreyanth
 
 ---
 # Home Realm Discovery for an application
 
-Home Realm Discovery (HRD) is the process that allows Azure Active directory (Azure AD) to determine which identity provider ("IdP") a user needs to authenticate with at sign-in time.  When a user signs in to an Azure AD tenant to access a resource, or to the Azure AD common sign-in page, they type a user name (UPN). Azure AD uses that to discover where the user needs to sign in.
+Home Realm Discovery (HRD) is the process that allows Azure Active directory (Azure AD) to determine which identity provider (IDP) a user needs to authenticate with at sign-in time.  When a user signs in to an Azure AD tenant to access a resource, or to the Azure AD common sign-in page, they type a user name (UPN). Azure AD uses that to discover where the user needs to sign in.
 
 The user will be taken to one of the following identity providers to be authenticated:
 
@@ -54,13 +54,13 @@ For example, the application "largeapp.com" might enable their customers to acce
 
 Domain hint syntax varies depending on the protocol that's used, and it's typically configured in the application in the following ways:
 
-- For applications that use the**WS-Federation**:  whr=contoso.com in the query string.
+- For applications that use the **WS-Federation**:  `whr` query string parameter. For example, whr=contoso.com.
 
 - For applications that use the **SAML**:  Either a SAML authentication request that contains a domain hint or a query string whr=contoso.com.
 
-- For applications that use the **Open ID Connect**: A query string domain_hint=contoso.com.
+- For applications that use the **Open ID Connect**: `domain_hint`  query string parameter. For example, domain_hint=contoso.com.
 
-By default, Azure AD attempts to redirect sign-in to the IdP that's configured for a domain if **both** of the following are true:
+By default, Azure AD attempts to redirect sign-in to the IDP that's configured for a domain if **both** of the following are true:
 
 - A domain hint is included in the authentication request from the application **and**
 - The tenant is federated with that domain.

articles/active-directory/saas-apps/blinq-provisioning-tutorial.md

@@ -174,7 +174,8 @@ Once you've configured provisioning, use the following resources to monitor your
 * If the provisioning configuration seems to be in an unhealthy state, the application will go into quarantine. Learn more about quarantine states [here](../app-provisioning/application-provisioning-quarantine-status.md).  
 
 ## Change Logs
-05/25/2022 - **Schema Discovery** feature enabled on this app.
+* 05/25/2022 - **Schema Discovery** feature enabled on this app.
+* 12/22/2022 - The source attribute of **addresses[type eq "work"].formatted** ha been changed to **Join("", [streetAddress], IIF(IsPresent([city]),", ",""), [city], IIF(IsPresent([state]),", ",""), [state], IIF(IsPresent([postalCode])," ",""), [postalCode]) --> addresses[type eq "work"].formatted**.
 
 ## More resources
 

articles/active-directory/saas-apps/lucid-all-products-provisioning-tutorial.md

@@ -98,7 +98,7 @@ This section guides you through the steps to configure the Azure AD provisioning
 
 1. Select **Save**.
 
-1. Under the **Mappings** section, select **Synchronize Azure Active Directory Users to Lucid (All Products)**.
+1. Under the **Mappings** section, select **Provision Azure Active Directory Users**.
 
 1. Review the user attributes that are synchronized from Azure AD to Lucid (All Products) in the **Attribute-Mapping** section. The attributes selected as **Matching** properties are used to match the user accounts in Lucid (All Products) for update operations. If you choose to change the [matching target attribute](../app-provisioning/customize-application-attributes.md), you will need to ensure that the Lucid (All Products) API supports filtering users based on that attribute. Select the **Save** button to commit any changes.
 
@@ -116,7 +116,7 @@ This section guides you through the steps to configure the Azure AD provisioning
     |urn:ietf:params:scim:schemas:extension:lucid:2.0:User:productLicenses.LucidscaleCreator|String||
 
 
-1. Under the **Mappings** section, select **Synchronize Azure Active Directory Groups to Lucid (All Products)**.
+1. Under the **Mappings** section, select **Provision Azure Active Directory Groups**.
 
 1. Review the group attributes that are synchronized from Azure AD to Lucid (All Products) in the **Attribute-Mapping** section. The attributes selected as **Matching** properties are used to match the groups in Lucid (All Products) for update operations. Select the **Save** button to commit any changes.
 

articles/active-directory/saas-apps/tripwire-enterprise-tutorial.md

@@ -9,7 +9,7 @@ ms.service: active-directory
 ms.subservice: saas-app-tutorial
 ms.workload: identity
 ms.topic: how-to
-ms.date: 12/14/2022
+ms.date: 01/02/2023
 ms.author: jeedes
 
 ---
@@ -77,17 +77,13 @@ Complete the following steps to enable Azure AD single sign-on in the Azure port
 
     ![Screenshot shows the Certificate download link.](common/metadataxml.png "Certificate")
 
-1. On the **Set up Tripwire Enterprise** section, copy the appropriate URL(s) based on your requirement.
-
-	![Screenshot shows to copy configuration appropriate URL.](common/copy-configuration-urls.png "Metadata")
-
 ## Configure Tripwire Enterprise SSO
 
-To configure single sign-on on **Tripwire Enterprise** side, you need to send the downloaded **Federation Metadata XML** and appropriate copied URLs from Azure portal to [Tripwire Enterprise support team](mailto:support@tripwire.com). They set this setting to have the SAML SSO connection set properly on both sides.
+To configure single sign-on in Tripwire Enterprise, please see **Using Tripwire Enterprise with SAML Authentication** section in the Tripwire Enterprise Hardeing Guide, available for download on the [Tripwire Customer Center](https://tripwireinc.force.com/customers/home). If you require assistance, contact [Tripwire Enterprise support team](mailto:[email protected]).
 
 ### Create Tripwire Enterprise test user
 
-In this section, you create a user called Britta Simon in Tripwire Enterprise. Work with [Tripwire Enterprise support team](mailto:support@tripwire.com) to add the users in the Tripwire Enterprise platform. Users must be created and activated before you use single sign-on.
+To create a Tripwire Enterprise user, please see **Creating a User Account** section in the Tripwire Enterprise User Guide, available for download on the [Tripwire Customer Center](https://tripwireinc.force.com/customers/home). If you require assistance, contact [Tripwire Enterprise support team](mailto:[email protected]).
 
 ## Test SSO