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

Author: Learn Build Service GitHub App

.openpublishing.redirection.json

@@ -2373,6 +2373,11 @@
             "redirect_url": "/azure/web-application-firewall/afds/waf-front-door-geo-filtering",
             "redirect_document_id": false
         },
+        {
+            "source_path_from_root": "/articles/web-application-firewall/scripts/waf-custom-rules-powershell.md",
+            "redirect_url": "/azure/web-application-firewall/ag/configure-waf-custom-rules",
+            "redirect_document_id": false
+        },
         {
             "source_path_from_root": "/articles/frontdoor/standard-premium/edge-locations.md",
             "redirect_url": "/azure/frontdoor/edge-locations-by-region",
@@ -24241,6 +24246,11 @@
             "source_path_from_root": "/articles/bastion/bastion-connect-vm-rdp-linux.md",
             "redirect_url": "/azure/bastion/bastion-connect-vm-ssh-linux",
             "redirect_document_id": false
+        },
+        {
+            "source_path_from_root": "/articles/reliability/reliability-postgre-flexible.md",
+            "redirect_url": "/azure/reliability/reliability-postgresql-flexible-server",
+            "redirect_document_id": false
         }
     ]
 }

articles/active-directory/architecture/multi-tenant-common-considerations.md

@@ -8,7 +8,7 @@ ms.service: active-directory
 ms.workload: identity
 ms.subservice: fundamentals
 ms.topic: conceptual
-ms.date: 04/19/2023
+ms.date: 08/21/2023
 ms.author: jricketts
 ms.custom: it-pro, seodec18, has-azure-ad-ps-ref
 ms.collection: M365-identity-device-management
@@ -129,20 +129,44 @@ Additionally, while you can use the following Conditional Access conditions, be
 - **Sign-in risk and user risk.** User behavior in their home tenant determines, in part, the sign-in risk and user risk. The home tenant stores the data and risk score. If resource tenant policies block an external user, a resource tenant admin might not be able to enable access. [Identity Protection and B2B users](../identity-protection/concept-identity-protection-b2b.md) explains how Identity Protection detects compromised credentials for Azure AD users.
 - **Locations.** The named location definitions in the resource tenant determine the scope of the policy. The scope of the policy doesn't evaluate trusted locations managed in the home tenant. If your organization wants to share trusted locations across tenants, define the locations in each tenant where you define the resources and Conditional Access policies.
 
-## Other access control considerations
+## Securing your multi-tenant environment
+Review the [security checklist](/azure/security/fundamentals/steps-secure-identity) and [best practices](/azure/security/fundamentals/operational-best-practices) for guidance on securing your tenant. Ensure these best practices are followed and review them with any tenants that you collaborate closely with.
 
+### Conditional access
 The following are considerations for configuring access control.
 
 - Define [access control policies](../external-identities/authentication-conditional-access.md) to control access to resources.
 - Design Conditional Access policies with external users in mind.
 - Create policies specifically for external users.
-- If your organization is using the [**all users** dynamic group](../external-identities/use-dynamic-groups.md) condition in your existing Conditional Access policy, this policy affects external users because they are in scope of **all users**.
 - Create dedicated Conditional Access policies for external accounts.
 
-### Require user assignment
+### Monitoring your multi-tenant environment
+- Monitor for changes to cross-tenant access policies using the [audit logs UI](../reports-monitoring/concept-audit-logs.md), [API](/graph/api/resources/azure-ad-auditlog-overview), or [Azure Monitor integration](../reports-monitoring/tutorial-configure-log-analytics-workspace.md) (for proactive alerts). The audit events use the categories "CrossTenantAccessSettings" and "CrossTenantIdentitySyncSettings." By monitoring for audit events under these categories, you can identify any cross-tenant access policy changes in your tenant and take action. When creating alerts in Azure Monitor, you can create a query such as the one below to identify any cross-tenant access policy changes.   
+
+```
+AuditLogs
+| where Category contains "CrossTenant"
+```
+
+- Monitor application access in your tenant using the [cross-tenant access activity](../reports-monitoring/workbook-cross-tenant-access-activity.md) dashboard. This allows you to see who is accessing resources in your tenant and where those users are coming from. 
+
+
+### Dynamic groups
+
+If your organization is using the [**all users** dynamic group](../external-identities/use-dynamic-groups.md) condition in your existing Conditional Access policy, this policy affects external users because they are in scope of **all users**.
+
+### Require user assignment for applications
 
 If an application has the **User assignment required?** property set to **No**, external users can access the application. Application admins must understand access control impacts, especially if the application contains sensitive information. [Restrict your Azure AD app to a set of users in an Azure AD tenant](../develop/howto-restrict-your-app-to-a-set-of-users.md) explains how registered applications in an Azure Active Directory (Azure AD) tenant are, by default, available to all users of the tenant who successfully authenticate.
 
+### Privileged Identity Management
+Minimize persistent administrator access by enabling [privileged identity management](/azure/security/fundamentals/steps-secure-identity#implement-privilege-access-management). 
+
+### Restricted Management Units
+When you're using security groups to control who is in scope for cross-tenant synchronization, you will want to limit who can make changes to the security group. Minimize the number of owners of the security groups assigned to the cross-tenant synchronization job and include the groups in a [restricted management unit](../roles/admin-units-restricted-management.md). This will limit the number of people that can add or remove group members and provision accounts across tenants. 
+
+## Other access control considerations
+
 ### Terms and conditions
 
 [Azure AD terms of use](../conditional-access/terms-of-use.md) provides a simple method that organizations can use to present information to end users. You can use terms of use to require external users to approve terms of use before accessing your resources.

articles/active-directory/authentication/concept-authentication-strengths.md

@@ -6,12 +6,12 @@ services: multi-factor-authentication
 ms.service: active-directory
 ms.subservice: authentication
 ms.topic: conceptual
-ms.date: 06/02/2023
+ms.date: 08/23/2023
 
 ms.author: justinha
 author: justinha
 manager: amycolannino
-ms.reviewer: michmcla, inbarckms
+ms.reviewer: inbarckms
 
 ms.collection: M365-identity-device-management
 ---
@@ -225,22 +225,31 @@ An authentication strength Conditional Access policy works together with [MFA tr
 
 ## Limitations
 
-- **Conditional Access policies are only evaluated after the initial authentication** -  As a result, authentication strength doesn't restrict a user's initial authentication. Suppose you are using the built-in phishing-resistant MFA strength. A user can still type in their password, but they will be required to use a phishing-resistant method such as FIDO2 security key before they can continue.
+- **Conditional Access policies are only evaluated after the initial authentication** - As a result, authentication strength doesn't restrict a user's initial authentication. Suppose you are using the built-in phishing-resistant MFA strength. A user can still type in their password, but they will be required to use a phishing-resistant method such as FIDO2 security key before they can continue.
 
 - **Require multifactor authentication and Require authentication strength can't be used together in the same Conditional Access policy** - These two Conditional Access grant controls can't be used together because the built-in authentication strength **Multifactor authentication** is equivalent to the **Require multifactor authentication** grant control.
 
 - **Authentication methods that aren't currently supported by authentication strength** - The **Email one-time pass (Guest)** authentication method isn't included in the available combinations.
 
 - **Windows Hello for Business** – If the user signed in with Windows Hello for Business as their primary authentication method, it can be used to satisfy an authentication strength requirement that includes Windows Hello for Business. But if the user signed in with another method like password as their primary authenticating method, and the authentication strength requires Windows Hello for Business, they get prompted to sign in with Windows Hello for Business. 
 
+
+## Known isssues
+
+The following known issues are currently being addressed:
+
+- **Sign-in frequency** - If both sign-in frequency and authentication strength requirements apply to a sign-in, and the user has previously signed in using a method that meets the authentication strength requirements, the sign-in frequency requirement doesn't apply. [Sign-in frequency](concepts-azure-multi-factor-authentication-prompts-session-lifetime.md) allows you to set the time interval for re-authentication of users based on their credentials, but it isn't fully integrated with authentication strength yet. It works independently and doesn't currently impact the actual sign-in procedure. Therefore, you may notice that some sign-ins using expired credentials don't prompt re-authentication and the sign-in process proceeds successfully.
+
+- **FIDO2 security key Advanced options** - Advanced options aren't supported for external users with a home tenant that is located in a different Microsoft cloud than the resource tenant.
+
 ## FAQ
 
 ### Should I use authentication strength or the Authentication methods policy?
 Authentication strength is based on the Authentication methods policy. The Authentication methods policy helps to scope and configure authentication methods to be used across Azure AD by specific users and groups. Authentication strength allows another restriction of methods for specific scenarios, such as sensitive resource access, user risk, location, and more.
 
 For example, the administrator of Contoso wants to allow their users to use Microsoft Authenticator with either push notifications or passwordless authentication mode. The administrator goes to the Microsoft Authenticator settings in the Authentication method policy, scopes the policy for the relevant users and set the **Authentication mode** to **Any**. 
 
-Then for Contoso’s most sensitive resource, the administrator wants to restrict the access to only passwordless authentication methods. The administrator creates a new Conditional Access policy, using the built-in **Passwordless MFA strength**. 
+Then for Contoso's most sensitive resource, the administrator wants to restrict the access to only passwordless authentication methods. The administrator creates a new Conditional Access policy, using the built-in **Passwordless MFA strength**. 
 
 As a result, users in Contoso can access most of the resources in the tenant using password + push notification from the Microsoft Authenticator OR only using Microsoft Authenticator (phone sign-in). However, when the users in the tenant access the sensitive application, they must use Microsoft Authenticator (phone sign-in).
 

articles/active-directory/conditional-access/concept-conditional-access-cloud-apps.md

@@ -8,7 +8,7 @@ ms.subservice: conditional-access
 ms.custom: has-azure-ad-ps-ref
 ms.topic: conceptual
 
-ms.date: 06/27/2023
+ms.date: 08/25/2023
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
@@ -19,14 +19,14 @@ ms.collection: M365-identity-device-management
 ---
 # Conditional Access: Target resources
 
-Target resources (formerly Cloud apps, actions, and authentication context) are key signals in a Conditional Access policy. Conditional Access policies allow administrators to assign controls to specific applications, actions, or authentication context.
+Target resources (formerly Cloud apps, actions, and authentication context) are key signals in a Conditional Access policy. Conditional Access policies allow administrators to assign controls to specific applications, services, actions, or authentication context.
 
-- Administrators can choose from the list of applications that include built-in Microsoft applications and any [Azure AD integrated applications](../manage-apps/what-is-application-management.md) including gallery, non-gallery, and applications published through [Application Proxy](../app-proxy/what-is-application-proxy.md).
+- Administrators can choose from the list of applications or services that include built-in Microsoft applications and any [Azure AD integrated applications](../manage-apps/what-is-application-management.md) including gallery, non-gallery, and applications published through [Application Proxy](../app-proxy/what-is-application-proxy.md).
 - Administrators may choose to define policy not based on a cloud application but on a [user action](#user-actions) like **Register security information** or **Register or join devices**, allowing Conditional Access to enforce controls around those actions.
 - Administrators can target [traffic forwarding profiles](#traffic-forwarding-profiles) from Global Secure Access for enhanced functionality.
 - Administrators can use [authentication context](#authentication-context) to provide an extra layer of security in applications. 
 
-![Define a Conditional Access policy and specify cloud apps](./media/concept-conditional-access-cloud-apps/conditional-access-cloud-apps-or-actions.png)
+:::image type="content" source="media/concept-conditional-access-cloud-apps/conditional-access-cloud-apps-or-actions.png" alt-text="Screenshot displaying a Conditional Access policy and the target resources panel." lightbox="media/concept-conditional-access-cloud-apps/conditional-access-cloud-apps-or-actions.png":::
 
 ## Microsoft cloud applications
 
@@ -83,32 +83,6 @@ Targeting this group of applications helps to avoid issues that may arise becaus
 
 Administrators can exclude the entire Office 365 suite or specific Office 365 cloud apps from the Conditional Access policy.
 
-The following key applications are affected by the Office 365 cloud app:
-
-- Exchange Online
-- Microsoft 365 Search Service
-- Microsoft Forms
-- Microsoft Planner (ProjectWorkManagement)
-- Microsoft Stream
-- Microsoft Teams
-- Microsoft To-Do
-- Microsoft Flow
-- Microsoft Office 365 Portal
-- Microsoft Office client application
-- Microsoft To-Do WebApp
-- Microsoft Whiteboard Services
-- Office Delve
-- Office Online
-- OneDrive
-- Power Apps
-- Power Automate
-- Security & compliance portal
-- SharePoint Online
-- Skype for Business Online
-- Skype and Teams Tenant Admin API
-- Sway
-- Yammer
-
 A complete list of all services included can be found in the article [Apps included in Conditional Access Office 365 app suite](reference-office-365-application-contents.md).
 
 ### Microsoft Azure Management
@@ -130,11 +104,11 @@ Because the policy is applied to the Azure management portal and API, services,
 - Azure Data Factory portal 
 - Azure Event Hubs 
 - Azure Service Bus 
-- [Azure SQL Database](/azure/azure-sql/database/conditional-access-configure)
+- Azure SQL Database
 - SQL Managed Instance 
 - Azure Synapse 
 - Visual Studio subscriptions administrator portal 
-- [Microsoft IoT Central](https://apps.azureiotcentral.com/)
+- Microsoft IoT Central
 
 > [!NOTE]
 > The Microsoft Azure Management application applies to [Azure PowerShell](/powershell/azure/what-is-azure-powershell), which calls the [Azure Resource Manager API](../../azure-resource-manager/management/overview.md). It does not apply to [Azure AD PowerShell](/powershell/azure/active-directory/overview), which calls the [Microsoft Graph API](/graph/overview).
@@ -148,13 +122,15 @@ For more information on how to set up a sample policy for Microsoft Azure Manage
 
 When a Conditional Access policy targets the Microsoft Admin Portals cloud app, the policy is enforced for tokens issued to application IDs of the following Microsoft administrative portals:
 
-- Microsoft 365 Admin Center
-- Exchange admin center
 - Azure portal
+- Exchange admin center
+- Microsoft 365 admin center
+- Microsoft 365 Defender portal
 - Microsoft Entra admin center
-- Security and Microsoft Purview compliance portal
+- Microsoft Intune admin center
+- Microsoft Purview compliance portal
 
-Other Microsoft admin portals will be added over time.
+We're continually adding more administrative portals to the list.
 
 > [!IMPORTANT]
 > Microsoft Admin Portals (preview) is not currently supported in Government clouds.
@@ -223,7 +199,7 @@ For example, an organization may keep files in SharePoint sites like the lunch m
 
 Authentication contexts are managed under **Azure Active Directory** > **Security** > **Conditional Access** > **Authentication context**.
 
-![Manage authentication context](./media/concept-conditional-access-cloud-apps/conditional-access-authentication-context-get-started.png)
+:::image type="content" source="media/concept-conditional-access-cloud-apps/conditional-access-authentication-context-get-started.png" alt-text="Screenshot showing the management of authentication contexts." lightbox="media/concept-conditional-access-cloud-apps/conditional-access-authentication-context-get-started.png":::
 
 Create new authentication context definitions by selecting **New authentication context**. Organizations are limited to a total of 25 authentication context definitions. Configure the following attributes:
 
@@ -236,7 +212,7 @@ Create new authentication context definitions by selecting **New authentication
 
 Administrators can select published authentication contexts in their Conditional Access policies under **Assignments** > **Cloud apps or actions** and selecting **Authentication context** from the **Select what this policy applies to** menu.
 
-:::image type="content" source="media/concept-conditional-access-cloud-apps/conditional-access-authentication-context-in-policy.png" alt-text="Adding a Conditional Access authentication context to a policy":::
+:::image type="content" source="media/concept-conditional-access-cloud-apps/conditional-access-authentication-context-in-policy.png" alt-text="Screenshot showing how to add a Conditional Access authentication context to a policy":::
 
 #### Delete an authentication context 
 

articles/active-directory/conditional-access/media/concept-conditional-access-cloud-apps/conditional-access-cloud-apps-or-actions.png

@@ -13,7 +13,7 @@ ms.author: henrymbugua
 ms.reviewer: madansr7
 # Customer intent: As an application developer, I want to learn how to protect properties of my application instance of being modified.
 ---
-# How to configure app instance property lock for your applications (Preview)
+# How to configure app instance property lock for your applications
 
 Application instance lock is a feature in Azure Active Directory (Azure AD) that allows sensitive properties of a multi-tenant application object to be locked for modification after the application is provisioned in another tenant. 
 This feature provides application developers with the ability to lock certain properties if the application doesn't support scenarios that require configuring those properties.  
@@ -27,6 +27,9 @@ The following property usage scenarios are considered as sensitive:
 - Credentials (`keyCredentials`, `passwordCredentials`) where usage type is `Verify`. In this scenario, your application supports an OIDC client credentials flow.
 - `TokenEncryptionKeyId` which specifies the keyId of a public key from the keyCredentials collection. When configured, Azure AD encrypts all the tokens it emits by using the key to which this property points. The application code that receives the encrypted token must use the matching private key to decrypt the token before it can be used for the signed-in user.
 
+> [!NOTE]
+> App instance lock is enabled by default for all new applications created using the Microsoft Entra admin center. 
+
 ## Configure an app instance lock
 
 [!INCLUDE [portal updates](~/articles/active-directory/includes/portal-update.md)]