fixed the conflict

Author: SnehaSudhirG

.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-domain-services/policy-reference.md

@@ -1,7 +1,7 @@
 ---
 title: Built-in policy definitions for Azure Active Directory Domain Services
 description: Lists Azure Policy built-in policy definitions for Azure Active Directory Domain Services. These built-in policy definitions provide common approaches to managing your Azure resources.
-ms.date: 08/08/2023
+ms.date: 08/25/2023
 ms.service: active-directory
 ms.subservice: domain-services
 author: justinha

articles/active-directory/app-provisioning/on-premises-sap-connector-configure.md

@@ -1,20 +1,20 @@
 ---
-title: Azure AD Provisioning to SAP ERP Central Component (SAP ECC) 7.0
-description: This document describes how to configure Azure AD to provision users into SAP ECC 7.
+title: Azure AD Provisioning into SAP ERP Central Component (SAP ECC, formerly SAP R/3) with NetWeaver AS ABAP 7.0 or later.
+description: This document describes how to configure Azure AD to provision users into SAP ERP Central Component (SAP ECC, formerly SAP R/3) with NetWeaver AS ABAP 7.0 or later.
 services: active-directory
 author: billmath
 manager: amycolannino
 ms.service: active-directory
 ms.subservice: app-provisioning
 ms.topic: how-to
 ms.workload: identity
-ms.date: 06/30/2023
+ms.date: 08/25/2023
 ms.author: billmath
 ms.reviewer: arvinh
 ---
 
-# Configuring Azure AD to provision users into SAP ECC 7.0
-The following documentation provides configuration and tutorial information demonstrating how to provision users from Azure AD into SAP ERP Central Component (SAP ECC) 7.0. If you are using other versions such as SAP R/3, you can still use the guides provided in the [download center](https://www.microsoft.com/download/details.aspx?id=51495) as a reference to build your own template and configure provisioning.   
+# Configuring Azure AD to provision users into SAP ECC with NetWeaver AS ABAP 7.0 or later
+The following documentation provides configuration and tutorial information demonstrating how to provision users from Azure AD into SAP ERP Central Component (SAP ECC, formerly SAP R/3) with NetWeaver 7.0 or later. If you are using other versions such as SAP R/3, you can still use the guides provided in the [download center](https://www.microsoft.com/download/details.aspx?id=51495) as a reference to build your own template and configure provisioning.   
 
 
 [!INCLUDE [app-provisioning-sap.md](../../../includes/app-provisioning-sap.md)]

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).