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

Author: roygara

articles/active-directory-domain-services/network-considerations.md

@@ -9,7 +9,7 @@ ms.service: active-directory
 ms.subservice: domain-services
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 03/14/2023
+ms.date: 07/31/2023
 ms.author: justinha
 ms.reviewer: xyuan
 
@@ -49,6 +49,16 @@ A managed domain connects to a subnet in an Azure virtual network. Design this s
 * A managed domain requires 3-5 IP addresses. Make sure that your subnet IP address range can provide this number of addresses.
     * Restricting the available IP addresses can prevent the managed domain from maintaining two domain controllers.
 
+  >[!NOTE]
+  >You shouldn't use public IP addresses for virtual networks and their subnets due to the following issues:
+  >
+  >- **Scarcity of the IP address**: IPv4 public IP addresses are limited, and their demand often exceeds the available supply. Also, there are potentially overlapping IPs with public endpoints.
+  >- **Security risks**: Using public IPs for virtual networks exposes your devices directly to the internet, increasing the risk of unauthorized access and potential attacks. Without proper security measures, your devices may become vulnerable to various threats.
+  >
+  >- **Complexity**: Managing a virtual network with public IPs can be more complex than using private IPs, as it requires dealing with external IP ranges and ensuring proper network segmentation and security.
+  >
+  >It is strongly recommended to use private IP addresses. If you use a public IP, ensure you are the owner/dedicated user of the chosen IPs in the public range you chose.
+
 The following example diagram outlines a valid design where the managed domain has its own subnet, there's a gateway subnet for external connectivity, and application workloads are in a connected subnet within the virtual network:
 
 ![Recommended subnet design](./media/active-directory-domain-services-design-guide/vnet-subnet-design.png)

articles/active-directory-domain-services/tutorial-create-instance.md

@@ -8,7 +8,7 @@ ms.service: active-directory
 ms.subservice: domain-services
 ms.workload: identity
 ms.topic: tutorial
-ms.date: 01/29/2023
+ms.date: 07/31/2023
 ms.author: justinha
 
 #Customer intent: As an identity administrator, I want to create an Azure Active Directory Domain Services managed domain so that I can synchronize identity information with my Azure Active Directory tenant and provide Domain Services connectivity to virtual machines and applications in Azure.
@@ -106,6 +106,16 @@ To quickly create a managed domain, you can select **Review + create** to accept
 * Creates a subnet named *aadds-subnet* using the IP address range of *10.0.2.0/24*.
 * Synchronizes *All* users from Azure AD into the managed domain.
 
+>[!NOTE]
+>You shouldn't use public IP addresses for virtual networks and their subnets due to the following issues:
+>
+>- **Scarcity of the IP address**: IPv4 public IP addresses are limited, and their demand often exceeds the available supply. Also, there are potentially overlapping IPs with public endpoints.
+>- **Security risks**: Using public IPs for virtual networks exposes your devices directly to the internet, increasing the risk of unauthorized access and potential attacks. Without proper security measures, your devices may become vulnerable to various threats.
+>
+>- **Complexity**: Managing a virtual network with public IPs can be more complex than using private IPs, as it requires dealing with external IP ranges and ensuring proper network segmentation and security.
+>
+>It is strongly recommended to use private IP addresses. If you use a public IP, ensure you are the owner/dedicated user of the chosen IPs in the public range you chose.
+
 Select **Review + create** to accept these default configuration options.
 
 ## Deploy the managed domain

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.