Merge pull request #301270 from MicrosoftDocs/main

6/12/2025 PM Publish

Author: Taojunshen

articles/active-directory-b2c/phone-based-mfa.md

@@ -82,7 +82,7 @@ You can use the workbook to understand phone-based MFA events and identify poten
 3. Mitigate fraudulent sign-ups by following the steps in the next section.
 
 
-## Mitigate fraudulent sign-ups
+## Mitigate fraudulent sign-ups for user flow
 
 Take the following actions to help mitigate fraudulent sign-ups.
 
@@ -97,12 +97,13 @@ Take the following actions to help mitigate fraudulent sign-ups.
    1. Sign in to the [Azure portal](https://portal.azure.com) as the [External ID User Flow Administrator](/entra/identity/role-based-access-control/permissions-reference#external-id-user-flow-administrator) of your Azure AD B2C tenant.
    1. If you have access to multiple tenants, select the **Settings** icon in the top menu to switch to your Azure AD B2C tenant from the **Directories + subscriptions** menu.
    1. Choose **All services** in the top-left corner of the Azure portal, search for and select **Azure AD B2C**.
-   1. Select the user flow, and then select **Languages**. Select the language for your organization's geographic location to open the language details panel. (For this example, we'll select **English en** for the United States). Select **Multifactor authentication page**, and then select **Download defaults (en)**.
+   1. Select the user flow, and then select **Languages**. Select the language for your organization's primary geographic location to open the language details panel. (For this example, we'll select **English en** for the United States). Select **Multifactor authentication page**, and then select **Download defaults (en)**.
 
       ![Upload new overrides to download defaults](media/phone-based-mfa/download-defaults.png)
 
    1. Open the JSON file that was downloaded in the previous step. In the file, search for `DEFAULT`, and replace the line with `"Value": "{\"DEFAULT\":\"Country/Region\",\"US\":\"United States\"}"`. Be sure to set `Overrides` to `true`.
 
+ To implement SMS blocking effectively, make sure the Overrides setting is enabled (set to true) only for your organization’s primary or default language. Do not enable Overrides for any secondary or non-primary languages, as this can cause unexpected SMS blocking. Since the countryList in the JSON file acts as an allow list, be sure to include all countries that should be permitted to send SMS in this list for the primary language configuration when Overrides is true.
    > [!NOTE]
    > You can customize the list of allowed country codes in the `countryList` element (see the [Phone factor authentication page example](localization-string-ids.md#phone-factor-authentication-page-example)).
 
@@ -111,6 +112,50 @@ Take the following actions to help mitigate fraudulent sign-ups.
 
       ![Country code drop-down](media/phone-based-mfa/country-code-drop-down.png)
 
+## Mitigate fraudulent sign-ups for custom policy
+
+To help prevent fraudulent sign-ups, remove any country codes that do not apply to your organization by following these steps:
+
+1. Locate the policy file that defines the `RelyingParty`. For example, in the [Starter Pack](https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack), this is usually the SignUpOrSignin.xml file.
+
+1. In the `BuildingBlocks` section of this policy file, add the following code. Make sure to include only the country codes relevant to your organization:
+
+   ```xml
+    <BuildingBlocks>
+
+      <ContentDefinitions>
+        <ContentDefinition Id="api.phonefactor">
+          <LoadUri>~/tenant/templates/AzureBlue/multifactor-1.0.0.cshtml</LoadUri>
+          <DataUri>urn:com:microsoft:aad:b2c:elements:contract:multifactor:1.2.20</DataUri>
+          <Metadata>
+            <Item Key="TemplateId">azureBlue</Item>
+          </Metadata>
+          <LocalizedResourcesReferences MergeBehavior="Prepend">
+            <!-- Add only primary business language here -->
+            <LocalizedResourcesReference Language="en" LocalizedResourcesReferenceId="api.phonefactor.en" />        
+          </LocalizedResourcesReferences>
+        </ContentDefinition>
+      </ContentDefinitions>
+
+      <Localization Enabled="true">
+        <SupportedLanguages DefaultLanguage="en" MergeBehavior="ReplaceAll">
+          <!-- Add only primary business language here -->
+          <SupportedLanguage>en</SupportedLanguage>
+        </SupportedLanguages>
+
+        <!-- Phone factor for primary business language -->
+        <LocalizedResources Id="api.phonefactor.en">
+          <LocalizedStrings>
+           <LocalizedString ElementType="UxElement" StringId="countryList">{"DEFAULT":"Country/Region","JP":"Japan","BG":"Bulgaria","US":"United States"}</LocalizedString>
+          </LocalizedStrings>
+        </LocalizedResources>
+      </Localization>
+
+     </BuildingBlocks>
+    ```
+   
+The countryList acts as an allow list. Only the countries you specify in this list (for example, Japan, Bulgaria, and the United States) are permitted to use MFA. All other countries are blocked.
+
 ## Related content
 
 - Learn about [Identity Protection and Conditional Access for Azure AD B2C](conditional-access-identity-protection-overview.md) 

articles/active-directory-b2c/security-architecture.md

@@ -55,7 +55,7 @@ The following table provides an overview of the different protection mechanisms
 |----|----|----|
 |Web Application Firewall (WAF)|WAF serves as the first layer of defense against malicious requests made to Azure AD B2C endpoints. It provides a centralized protection against common exploits and vulnerabilities such as DDoS, bots, OWASP Top 10, and so on. It's advised that you use WAF to ensure that malicious requests are stopped even before they reach Azure AD B2C endpoints. </br></br> To enable WAF, you must first [enable custom domains in Azure AD B2C using AFD](custom-domain.md?pivots=b2c-custom-policy).|<ul><li>[Configure Cloudflare WAF](./partner-cloudflare.md)</li></br><li>[Configure Akamai WAF](./partner-akamai.md)</li></ul>|
 |Azure Front Door (AFD)| AFD is a global, scalable entry-point that uses the Microsoft global edge network to create fast, secure, and widely scalable web applications. The key capabilities of AFD are:<ul><li>You can add or remove custom domains in a self-service fashion </li><li>Streamlined certificate management experience</li><li>You can bring your own certificate and get alert for certificate expiry with good rotation experience via [Azure Key Vault](https://azure.microsoft.com/products/key-vault/)</li><li>AFD-provisioned certificate for quicker provisioning and autorotation on expiry </li> </ul>|<ul><li> [Enable custom domains for Azure Active Directory B2C](./custom-domain.md)</li><ul>| 
-|Identity Verification & Proofing / Fraud Protection|Identity verification and proofing are critical for creating a trusted user experience and protecting against account takeover and fraudulent account creation. It also contributes to tenant hygiene by ensuring that user objects reflect the actual users, which align with business scenarios. </br></br>Azure AD B2C allows the integration of identity verification and proofing, and fraud protection from various software-vendor partners.| <ul><li> [Integrate with identity verification and proofing partners](./identity-verification-proofing.md)</li><li>[Configure Microsoft Dynamics 365 Fraud Protection](./partner-dynamics-365-fraud-protection.md)  </li><li> [Configure with Arkose Labs platform](./partner-arkose-labs.md)</li><li> [Mitigate fraudulent MFA usage](phone-based-mfa.md#mitigate-fraudulent-sign-ups)</li></ul>|
+|Identity Verification & Proofing / Fraud Protection|Identity verification and proofing are critical for creating a trusted user experience and protecting against account takeover and fraudulent account creation. It also contributes to tenant hygiene by ensuring that user objects reflect the actual users, which align with business scenarios. </br></br>Azure AD B2C allows the integration of identity verification and proofing, and fraud protection from various software-vendor partners.| <ul><li> [Integrate with identity verification and proofing partners](./identity-verification-proofing.md)</li><li>[Configure Microsoft Dynamics 365 Fraud Protection](./partner-dynamics-365-fraud-protection.md)  </li><li> [Configure with Arkose Labs platform](./partner-arkose-labs.md)</li><li> [Mitigate fraudulent MFA usage](phone-based-mfa.md#mitigate-fraudulent-sign-ups-for-user-flow)</li></ul>|
 |Identity Protection|Identity Protection provides ongoing risk detection. When a risk is detected during sign-in, you can configure Azure AD B2C conditional policy to allow the user to remediate the risk before proceeding with the sign-in. Administrators can also use identity protection reports to review risky users who are at risk and review detection details. The risk detections report includes information about each risk detection, such as its type and the location of the sign-in attempt, and more. Administrators can also confirm or deny that the user is compromised.|<ul><li>[Investigate risk with Identity Protection](./identity-protection-investigate-risk.md)</li><ul> | 
 |Conditional Access (CA)|When a user attempts to sign in, CA gathers various signals such as risks from identity protection, to make decisions and enforce organizational policies. CA can assist administrators to develop policies that are consistent with their organization's security posture. The policies can include the ability to completely block user access or provide access after the user has completed another authentication like MFA.|<ul><li>[Add Conditional Access policies to user flows](./conditional-access-user-flow.md)</li></ul>| 
 |Multifactor authentication|MFA adds a second layer of security to the sign-up and sign-in process and is an essential component of improving the security posture of user authentication in Azure AD B2C. The Authenticator app - TOTP is the recommended MFA method in Azure AD B2C. | <ul><li>[Enable multifactor authentication](./multi-factor-authentication.md)</li></ul> | 

articles/api-management/api-management-sample-send-request.md

@@ -59,7 +59,7 @@ There are certain tradeoffs when using a fire-and-forget style of request. If fo
 The `send-request` policy enables using an external service to perform complex processing functions and return data to the API management service that can be used for further policy processing.
 
 ### Authorizing reference tokens
-A major function of API Management is protecting backend resources. If the authorization server used by your API creates [JWT tokens](../active-directory/develop/security-tokens.md#json-web-tokens-and-claims) as part of its OAuth2 flow, as [Microsoft Entra ID](../active-directory/hybrid/whatis-hybrid-identity.md) does, then you can use the `validate-jwt` policy or `validate-azure-ad-token` policy to verify the validity of the token. Some authorization servers create what are called [reference tokens](https://leastprivilege.com/2015/11/25/reference-tokens-and-introspection/) that cannot be verified without making a callback to the authorization server.
+A major function of API Management is protecting backend resources. If the authorization server used by your API creates [JWTs](../active-directory/develop/security-tokens.md#json-web-tokens-and-claims) as part of its OAuth2 flow, as [Microsoft Entra ID](../active-directory/hybrid/whatis-hybrid-identity.md) does, then you can use the `validate-jwt` policy or `validate-azure-ad-token` policy to verify the validity of the token. Some authorization servers create what are called [reference tokens](https://leastprivilege.com/2015/11/25/reference-tokens-and-introspection/) that cannot be verified without making a callback to the authorization server.
 
 ### Standardized introspection
 In the past, there has been no standardized way of verifying a reference token with an authorization server. However a recently proposed standard [RFC 7662](https://tools.ietf.org/html/rfc7662) was published by the IETF that defines how a resource server can verify the validity of a token.

articles/api-management/validate-jwt-policy.md

@@ -115,15 +115,15 @@ The `validate-jwt` policy enforces existence and validity of a supported JSON we
 
 ### Usage notes
 
-* The `validate-jwt` policy requires that the `exp` registered claim is included in the JWT token, unless `require-expiration-time` attribute is specified and set to `false`.
+* The `validate-jwt` policy requires that the `exp` registered claim is included in the JWT, unless `require-expiration-time` attribute is specified and set to `false`.
 * The policy supports both symmetric and asymmetric signing algorithms: 
     * **Symmetric** - The following encryption algorithms are supported: A128CBC-HS256, A192CBC-HS384, A256CBC-HS512.
     	* If used in the policy, the key must be provided inline within the policy in the Base64-encoded form.
     * **Asymmetric** - The following encryption algorithms are supported: PS256, RS256, RS512, ES256. 
     	* If used in the policy, the key may be provided either via an OpenID configuration endpoint, or by providing the ID of an uploaded certificate (in PFX format) that contains the public key, or the modulus-exponent pair of the public key.
 * To configure the policy with one or more OpenID configuration endpoints for use with a self-hosted gateway, the OpenID configuration endpoints URLs must also be reachable by the cloud gateway.
 * You can use access restriction policies in different scopes for different purposes. For example, you can secure the whole API with Microsoft Entra authentication by applying the `validate-jwt` policy on the API level, or you can apply it on the API operation level and use `claims` for more granular control.
-* When using a custom header (`header-name`), the configured required scheme (`require-scheme`) will be ignored. To use a required scheme, JWT tokens must be provided in the `Authorization` header.
+* When using a custom header (`header-name`), the configured required scheme (`require-scheme`) will be ignored. To use a required scheme, JWTs must be provided in the `Authorization` header.
 
 ## Examples
 

articles/azure-netapp-files/azure-netapp-files-resource-limits.md

@@ -5,7 +5,7 @@ services: azure-netapp-files
 author: b-hchen
 ms.service: azure-netapp-files
 ms.topic: concept-article
-ms.date: 04/23/2025
+ms.date: 06/10/2025
 ms.author: anfdocs
 ---
 # Resource limits for Azure NetApp Files
@@ -49,7 +49,7 @@ The following table describes resource limits for Azure NetApp Files:
 |  Maximum size of protected volume  |  100 TiB  |  No  |
 |  Maximum number of volumes that can be backed up per subscription   |  500  |  No  |
 |  Maximum number of manual backups per volume per day |  5  |  No  |
-|  Maximum number of volumes supported for cool access per subscription per region |  10  |  Yes  |
+|  Maximum number of volumes supported for cool access per subscription per region |  500  |  Yes  |
 
 
 \* [!INCLUDE [Limitations for capacity pool minimum of 1 TiB](includes/2-tib-capacity-pool.md)]

articles/azure-netapp-files/includes/cool-access-options.md

@@ -0,0 +1,38 @@
+---
+author: b-ahibbard
+ms.service: azure-netapp-files
+ms.topic: include
+ms.date: 06/06/2025
+ms.author: anfdocs
+ms.custom: include file
+
+# manage-cool-access.md // 2 workflows
+---
+    
+* **Enable Cool Access**:
+
+    The coolness period defines the minimum number of days before data is transitioned to the cold tier. The default value is 31 days. The supported values are between 2 and 183 days.
+
+    >[!NOTE]
+    > The coolness period is calculated from the time of volume creation. If any existing volumes are enabled with cool access, the coolness period is applied retroactively on those volumes. If certain data blocks on the volumes have not been accessed for the number of days specified in the coolness period, those blocks move to the cool tier once the feature is enabled. Once the coolness period is reached, background jobs can take up to 48 hours to initiate the data transfer to the cool tier.
+
+* **Cool Access Retrieval Policy**:
+
+    This option specifies under which conditions data moves back to the hot tier. You can set this option to **Default**, **On-Read**, or **Never**.
+
+    If you don't set a value for the cool access retrieval policy, the retrieval policy is set to Default. The following table describes each policy's data retrieval behavior:
+
+    | Retrieval policy | Behavior |
+    | - | - | 
+    | Default | Cold data is returned to the hot tier when performing random reads. Data is served from the cool tier with sequential reads. | 
+    | On-read | On both sequential and random reads, cold data  is returned to the hot tier. |
+    | Never | Cold data is served directly from the cool tier. After data moves to the cool tier, it's not returned to the hot tier. |
+
+* **Cool Access Tiering policy**     
+
+    The tiering policy manages what data moves to the cool tier. You can tier all data or limit tiering to snapshots. Select one of the following policies: 
+
+    | Tiering policy | Description |
+    | - | - | 
+    | `Auto` | This policy encompasses both data in the active file system and snapshot copy data. |
+    | `SnapshotOnly` | This policy limits tiering to data in snapshots. All data blocks associated with files in the active file system remain in the hot tier. |