Merging changes synced from https://github.com/MicrosoftDocs/azure-docs-pr (branch live)

Author: Learn Build Service GitHub App

articles/active-directory/app-provisioning/application-provisioning-configuration-api.md

@@ -60,7 +60,7 @@ Content-type: application/json
 {
   "value": [
   {
-  	"id": "8b1025e4-1dd2-430b-a150-2ef79cd700f5",
+    "id": "8b1025e4-1dd2-430b-a150-2ef79cd700f5",
         "displayName": "AWS Single-Account Access",
         "homePageUrl": "http://aws.amazon.com/",
         "supportedSingleSignOnModes": [

articles/active-directory/app-provisioning/application-provisioning-when-will-provisioning-finish-specific-user.md

@@ -85,7 +85,7 @@ Summary of factors that influence the time it takes to complete an **initial cyc
 
 - Whether users in scope for provisioning are matched to existing users in the target application, or need to be created for the first time. Sync jobs for which all users are created for the first time take about *twice as long* as sync jobs for which all users are matched to existing users.
 
-- Number of errors in the [provisioning logs](check-status-user-account-provisioning.md). Performance is slower if there are many errors and the provisioning service has gone into a quarantine state.	
+- Number of errors in the [provisioning logs](check-status-user-account-provisioning.md). Performance is slower if there are many errors and the provisioning service has gone into a quarantine state.
 
 - Request rate limits and throttling implemented by the target system. Some target systems implement request rate limits and throttling, which can impact performance during large sync operations. Under these conditions, an app that receives too many requests too fast might slow its response rate or close the connection. To improve performance, the connector needs to adjust by not sending the app requests faster than the app can process them. Provisioning connectors built by Microsoft make this adjustment. 
 

articles/active-directory/app-provisioning/inbound-provisioning-api-grant-access.md

@@ -55,10 +55,11 @@ This section describes how you can assign the necessary permissions to a managed
 
       [![Screenshot of managed identity name.](media/inbound-provisioning-api-grant-access/managed-identity-name.png)](media/inbound-provisioning-api-grant-access/managed-identity-name.png#lightbox) 
 
-1. Run the following PowerShell script to assign permissions to your managed identity. 
+1. Run the following PowerShell script to assign permissions to your managed identity.
+
       ```powershell
       Install-Module Microsoft.Graph -Scope CurrentUser
-     
+
       Connect-MgGraph -Scopes "Application.Read.All","AppRoleAssignment.ReadWrite.All,RoleManagement.ReadWrite.Directory"
       Select-MgProfile Beta
       $graphApp = Get-MgServicePrincipal -Filter "AppId eq '00000003-0000-0000-c000-000000000000'"
@@ -75,7 +76,7 @@ This section describes how you can assign the necessary permissions to a managed
       $managedID = Get-MgServicePrincipal -Filter "DisplayName eq 'CSV2SCIMBulkUpload'"
       New-MgServicePrincipalAppRoleAssignment -PrincipalId $managedID.Id -ServicePrincipalId $managedID.Id -ResourceId $graphApp.Id -AppRoleId $AppRole.Id
       ```
-1. To confirm that the permission was applied, find the managed identity service principal under **Enterprise Applications** in Azure AD. Remove the **Application type** filter to see all service principals. 
+1. To confirm that the permission was applied, find the managed identity service principal under **Enterprise Applications** in Azure AD. Remove the **Application type** filter to see all service principals.
       [![Screenshot of managed identity principal.](media/inbound-provisioning-api-grant-access/managed-identity-principal.png)](media/inbound-provisioning-api-grant-access/managed-identity-principal.png#lightbox) 
 1. Click on the **Permissions** blade under **Security**. Ensure the permission is set. 
       [![Screenshot of managed identity permissions.](media/inbound-provisioning-api-grant-access/managed-identity-permissions.png)](media/inbound-provisioning-api-grant-access/managed-identity-permissions.png#lightbox) 

articles/active-directory/app-provisioning/inbound-provisioning-api-powershell.md

@@ -82,8 +82,8 @@ The PowerShell sample script published in the [Microsoft Entra ID inbound provis
      - Test-ScriptCommands.ps1 (sample usage commands)
      - UseClientCertificate.ps1 (script to generate self-signed certificate and upload it as service principal credential for use in OAuth flow)
      - `Sample1` (folder with more examples of how CSV file columns can be mapped to SCIM standard attributes. If you get different CSV files for employees, contractors, interns, you can create a separate AttributeMapping.psd1 file for each entity.)
-1. Download and install the latest version of PowerShell. 
-1. Run the command to enable execution of remote signed scripts: 
+1. Download and install the latest version of PowerShell.
+1. Run the command to enable execution of remote signed scripts:
     ```powershell
     set-executionpolicy remotesigned
     ```

articles/active-directory/app-provisioning/plan-auto-user-provisioning.md

@@ -110,13 +110,13 @@ In this example, the users and or groups are created in a cloud HR application l
 
 ![Picture 2](./media/plan-auto-user-provisioning/workdayprovisioning.png)
 
-1.	**HR team** performs the transactions in the cloud HR app tenant.
-2.	**Azure AD provisioning service** runs the scheduled cycles from the cloud HR app tenant and identifies changes that need to be processed for sync with AD.
-3.	**Azure AD provisioning service** invokes the Azure AD Connect provisioning agent with a request payload containing AD account create/update/enable/disable operations.
-4.	**Azure AD Connect provisioning agent** uses a service account to manage AD account data.
-5.	**Azure AD Connect** runs delta sync to pull updates in AD.
-6.	**AD** updates are synced with Azure AD. 
-7.	**Azure AD provisioning service** writebacks email attribute and username from Azure AD to the cloud HR app tenant.
+1. **HR team** performs the transactions in the cloud HR app tenant.
+2. **Azure AD provisioning service** runs the scheduled cycles from the cloud HR app tenant and identifies changes that need to be processed for sync with AD.
+3. **Azure AD provisioning service** invokes the Azure AD Connect provisioning agent with a request payload containing AD account create/update/enable/disable operations.
+4. **Azure AD Connect provisioning agent** uses a service account to manage AD account data.
+5. **Azure AD Connect** runs delta sync to pull updates in AD.
+6. **AD** updates are synced with Azure AD. 
+7. **Azure AD provisioning service** writebacks email attribute and username from Azure AD to the cloud HR app tenant.
 
 ## Plan the deployment project
 

articles/active-directory/app-provisioning/user-provisioning-sync-attributes-for-mapping.md

@@ -49,7 +49,7 @@ Once schema extensions are created, these extension attributes are automatically
 When you've more than 1000 service principals, you may find extensions missing in the source attribute list. If an attribute you've created doesn't automatically appear, then verify the attribute was created and add it manually to your schema. To verify it was created, use Microsoft Graph and [Graph Explorer](/graph/graph-explorer/graph-explorer-overview). To add it manually to your schema, see [Editing the list of supported attributes](customize-application-attributes.md#editing-the-list-of-supported-attributes).
 
 ### Create an extension attribute for cloud only users using Microsoft Graph
-You can extend the schema of Azure AD users using [Microsoft Graph](/graph/overview). 
+You can extend the schema of Azure AD users using [Microsoft Graph](/graph/overview).
 
 First, list the apps in your tenant to get the ID of the app you're working on. To learn more, see [List extensionProperties](/graph/api/application-list-extensionproperty).
 
@@ -67,7 +67,7 @@ Content-type: application/json
     "name": "extensionName",
     "dataType": "string",
     "targetObjects": [
-    	"User"
+      "User"
     ]
 }
 ```
@@ -89,10 +89,10 @@ GET https://graph.microsoft.com/v1.0/users/{id}?$select=displayName,extension_in
 
 
 ### Create an extension attribute on a cloud only user using PowerShell
-Create a custom extension using PowerShell and assign a value to a user. 
+Create a custom extension using PowerShell and assign a value to a user.
 
 ```
-#Connect to your Azure AD tenant   
+#Connect to your Azure AD tenant
 Connect-AzureAD
 
 #Create an application (you can instead use an existing application if you would like)
@@ -123,7 +123,7 @@ Cloud sync will automatically discover your extensions in on-premises Active Dir
 4. Select the configuration you wish to add the extension attribute and mapping.
 5. Under **Manage attributes** select **click to edit mappings**.
 6. Click **Add attribute mapping**.  The attributes will automatically be discovered.
-7. The new attributes will be available in the drop-down under **source attribute**.  
+7. The new attributes will be available in the drop-down under **source attribute**.
 8. Fill in the type of mapping you want and click **Apply**.
    [![Custom attribute mapping](media/user-provisioning-sync-attributes-for-mapping/schema-1.png)](media/user-provisioning-sync-attributes-for-mapping/schema-1.png#lightbox)
 
@@ -142,11 +142,11 @@ If users who will access the applications originate in on-premises Active Direct
 1. Open the Azure AD Connect wizard, choose Tasks, and then choose **Customize synchronization options**.
 
    ![Azure Active Directory Connect wizard Additional tasks page](./media/user-provisioning-sync-attributes-for-mapping/active-directory-connect-customize.png)
- 
-2. Sign in as an Azure AD Global Administrator. 
+
+2. Sign in as an Azure AD Global Administrator.
 
 3. On the **Optional Features** page, select **Directory extension attribute sync**.
- 
+
    ![Azure Active Directory Connect wizard Optional features page](./media/user-provisioning-sync-attributes-for-mapping/active-directory-connect-directory-extension-attribute-sync.png)
 
 4. Select the attribute(s) you want to extend to Azure AD.
@@ -156,13 +156,13 @@ If users who will access the applications originate in on-premises Active Direct
    ![Screenshot that shows the "Directory extensions" selection page](./media/user-provisioning-sync-attributes-for-mapping/active-directory-connect-directory-extensions.png)
 
 5. Finish the Azure AD Connect wizard and allow a full synchronization cycle to run. When the cycle is complete, the schema is extended and the new values are synchronized between your on-premises AD and Azure AD.
- 
+
 6. In the Azure portal, while you’re [editing user attribute mappings](customize-application-attributes.md), the **Source attribute** list will now contain the added attribute in the format `<attributename> (extension_<appID>_<attributename>)`, where appID is the identifier of a placeholder application in your tenant. Select the attribute and map it to the target application for provisioning.
 
    ![Azure Active Directory Connect wizard Directory extensions selection page](./media/user-provisioning-sync-attributes-for-mapping/attribute-mapping-extensions.png)
 
 > [!NOTE]
-> The ability to provision reference attributes from on-premises AD, such as **managedby** or **DN/DistinguishedName**, is not supported today. You can request this feature on [User Voice](https://feedback.azure.com/d365community/forum/22920db1-ad25-ec11-b6e6-000d3a4f0789). 
+> The ability to provision reference attributes from on-premises AD, such as **managedby** or **DN/DistinguishedName**, is not supported today. You can request this feature on [User Voice](https://feedback.azure.com/d365community/forum/22920db1-ad25-ec11-b6e6-000d3a4f0789).
 
 
 ## Next steps

articles/active-directory/app-provisioning/user-provisioning.md

@@ -15,7 +15,7 @@ ms.reviewer: arvinh
 # What is app provisioning in Azure Active Directory?
 
 In Azure Active Directory (Azure AD), the term *app provisioning* refers to automatically creating user identities and roles for applications.
-	
+
 ![Diagram that shows provisioning scenarios.](../governance/media/what-is-provisioning/provisioning.png)
 
 Azure AD application provisioning refers to automatically creating user identities and roles in the applications that users need access to. In addition to creating user identities, automatic provisioning includes the maintenance and removal of user identities as status or roles change. Common scenarios include provisioning an Azure AD user into SaaS applications like [Dropbox](../../active-directory/saas-apps/dropboxforbusiness-provisioning-tutorial.md), [Salesforce](../../active-directory/saas-apps/salesforce-provisioning-tutorial.md), [ServiceNow](../../active-directory/saas-apps/servicenow-provisioning-tutorial.md), and many more.

articles/active-directory/app-proxy/application-proxy-azure-front-door.md

@@ -36,14 +36,14 @@ This article guides you through the steps to securely expose a web application o
 ### Application Proxy Configuration
 
 Follow these steps to configure Application Proxy for Front Door: 
-1.	Install connector for the location that your app instances will be in (For example US West).  For the connector group assign the connector to the right region (For example North America).
-2.	Set up your app instance with Application Proxy as follows:
+1. Install connector for the location that your app instances will be in (For example US West).  For the connector group assign the connector to the right region (For example North America).
+2. Set up your app instance with Application Proxy as follows:
     - Set the Internal URL to the address users access the app from the internal network, for example contoso.org
     - Set the External URL to the domain address you want the users to access the app from. For this you must configure a custom domain for our application here, for example, contoso.org. Reference: [Custom domains in Azure Active Directory Application Proxy][appproxy-custom-domain]
     - Assign the application to the appropriate connector group (For example: North America)
     - Note down the URL generated by Application Proxy to access the application. For example, contoso.msappproxy.net 
     - For the application configure a CNAME Entry in your DNS provider which points the external URL to the Front Door’s endpoint, for example ‘contoso.org’ to contoso.msappproxy.net 
-3.	In the Front Door service, utilize the URL generated for the app by Application Proxy as a backend for the backend pool. For example, contoso.msappproxy.net 
+3. In the Front Door service, utilize the URL generated for the app by Application Proxy as a backend for the backend pool. For example, contoso.msappproxy.net 
 
 #### Sample Application Proxy Configuration
 The following table shows a sample Application Proxy configuration. The sample scenario uses the sample application domain www.contoso.org as the External URL. 
@@ -67,15 +67,15 @@ The configuration steps that follow refer to the following definitions:
 - Origin host header: This represented the host header value being sent to the backend for each request. For example, contoso.org. For more information refer here: [Origins and origin groups – Azure Front Door][front-door-origin]
 
 Follow these steps to configure the Front Door Service (Standard): 
-1.	Create a Front Door (Standard) with the configuration below: 
+1. Create a Front Door (Standard) with the configuration below: 
     - Add an Endpoint name for generating the Front Door’s default domain i.e. azurefd.net. For example, contoso-nam that generated the Endpoint hostname contoso-nam.azurefd.net 
     - Add an Origin Type for the type of backend resource. For example Custom here for the Application Proxy resource
     - Add an Origin host name to represent the backend host name. For example, contoso.msappproxy.net 
     - Optional: Enable Caching for the routing rule for Front Door to cache your static content. 
-2.	Verify if the deployment is complete and the Front Door Service is ready
-3.	To give your Front Door service a user-friendly domain host name URL, create a CNAME record with your DNS provider for your Application Proxy External URL that points to Front Door’s domain host name (generated by the Front Door service). For example, contoso.org points to contoso.azurefd.net Reference: [How to add a custom domain - Azure Front Door][front-door-custom-domain]
-4.	As per the reference, on the Front Door Service Dashboard navigate to Front Door Manager and add a Domain with the Custom Hostname. For example, contoso.org 
-5.	Navigate to the Origin groups in the Front Door Service Dashboard, select the origin name and validate the Origin host header matches the domain of the backend. For example here the Origin host header should be: contoso.org 
+2. Verify if the deployment is complete and the Front Door Service is ready
+3. To give your Front Door service a user-friendly domain host name URL, create a CNAME record with your DNS provider for your Application Proxy External URL that points to Front Door’s domain host name (generated by the Front Door service). For example, contoso.org points to contoso.azurefd.net Reference: [How to add a custom domain - Azure Front Door][front-door-custom-domain]
+4. As per the reference, on the Front Door Service Dashboard navigate to Front Door Manager and add a Domain with the Custom Hostname. For example, contoso.org 
+5. Navigate to the Origin groups in the Front Door Service Dashboard, select the origin name and validate the Origin host header matches the domain of the backend. For example here the Origin host header should be: contoso.org 
 
 |     | Configuration | Additional Information |
 |---- | ----------------------- | ---------------------- |

articles/active-directory/app-proxy/application-proxy-configure-complex-application.md

@@ -16,9 +16,9 @@ ms.reviewer: dhruvinshah
 # Understanding Azure Active Directory Application Proxy Complex application scenario (Preview)
 
 When applications are made up of multiple individual web application using different domain suffixes or different ports or paths in the URL, the individual web application instances must be published in separate Azure AD Application Proxy apps and the following problems might arise:
-1.	Pre-authentication- The client must separately acquire an access token or cookie for each Azure AD Application Proxy app. This might lead to additional redirects to login.microsoftonline.com and CORS issues.
-2.	CORS issues- Cross-origin resource sharing calls (OPTIONS request) might be triggered to validate if the caller web app is allowed to access the URL of the targeted web app. These will be blocked by the Azure AD Application Proxy Cloud service, since these requests cannot contain authentication information.
-3.	Poor app management- Multiple enterprise apps are created to enable access to a private app adding friction to the app management experience.
+1. Pre-authentication- The client must separately acquire an access token or cookie for each Azure AD Application Proxy app. This might lead to additional redirects to login.microsoftonline.com and CORS issues.
+2. CORS issues- Cross-origin resource sharing calls (OPTIONS request) might be triggered to validate if the caller web app is allowed to access the URL of the targeted web app. These will be blocked by the Azure AD Application Proxy Cloud service, since these requests cannot contain authentication information.
+3. Poor app management- Multiple enterprise apps are created to enable access to a private app adding friction to the app management experience.
 
 The following figure shows an example for complex application domain structure.