Deny policy

Question

I have this den policy [

 "parameters": {
      "effect": {
        "type": "String",
        "metadata": {
          "displayName": "Effect",
          "description": "The effect determines what happens when the policy rule is evaluated to match"
        },
        "allowedValues": [
          "Disabled",
          "Deny",
          "Audit"
        ],
        "defaultValue": "Deny"
      },
      "minimalTlsVersion": {
        "type": "String",
        "metadata": {
          "displayName": "Minimal TLS version",
          "description": "The minimal TLS version that is allowed. App Service apps with a lower TLS version will be non-compliant."
        },
        "allowedValues": [
          "1.2",
          "1.3"
        ],
        "defaultValue": "1.2"
      }
    },
    "policyRule": {
      "if": {
        "allOf": [
          {
            "field": "type",
            "equals": "Microsoft.Web/sites/config"
          },
          {
            "field": "kind",
            "notContains": "functionapp"
          },
          {
          "anyOf": [
            {
              "field": "Microsoft.Web/sites/config/web.minTlsVersion",
              "exists": "false"
            },
           {
            "field": "Microsoft.Web/sites/config/web.minTlsVersion",
            "less": "[parameters('minimalTlsVersion')]"
          }
        ]
        }
      ]
      },

      "then": {
        "effect": "[parameters('effect')]"
      }
    }
  }

] yet i am able to change my minTls value to 1.0 without the deny policy preventing me.

Answer 1

Hi @moti jirata

It looks like your custom deny policy for enforcing a minimum TLS version on App Service is not actually firing, so you are still able to drop your minTlsVersion down to 1.0. Here are the most common reasons this happens and

what you can check or tweak:

1. Policy target type / operation mismatch • Your “if” block is scoped to the resource type “Microsoft.Web/sites/config” but when you update TLS via the portal or CLI you’re often hitting “Microsoft.Web/sites/write” on the parent resource. • The policy never actually evaluates because it only watches the child‐resource type. → Try adding or changing your “if” to also catch calls against type == 'Microsoft.Web/sites' and then inspect the nested property alias.

Property alias is incorrect • The built-in App Service TLS policy uses the alias Microsoft.Web/sites/config/minTlsVersion (no “web.” prefix) or the ARM path siteConfig.minTlsVersion. • If your policy is checking Microsoft.Web/sites/config/web.minTlsVersion, it won’t match. → Update your rule to use the correct alias:

"field": "Microsoft.Web/sites/config/minTlsVersion"

Enforcement delay or disabled assignment • New or updated policy assignments can take up to one hour before the deny effect kicks in. • Make sure your assignment’s Enforcement is set to Enabled and your effect is Deny. → In the Azure portal, go to Policy → Assignments → select your assignment → Properties.

Exemption or higher-priority policy • Check for any policy exemptions at the resource or resource-group level that might override your deny. → In the portal view your assignment, scroll to “Exemptions” and remove/reset as needed.

No policy evaluation errors in Activity Log • If your policy did trigger, you’d see a RequestDisallowedByPolicy with a 403 in the Activity Log. → Look under Azure Monitor → Activity Log, filter for “Failed” and your resource name.

What to try next

1. Update your JSON rule to something like:

"if": {
  "allOf": [
    {
      "anyOf": [
        {
          "field": "type",
          "equals": "Microsoft.Web/sites/config"
        },
        {
          "field": "type",
          "equals": "Microsoft.Web/sites"
        }
      ]
    },
    {
      "field": "kind",
      "notContains": "functionapp"
    },
    {
      "anyOf": [
        {
          "field": "Microsoft.Web/sites/config/minTlsVersion",
          "exists": false
        },
        {
          "field": "Microsoft.Web/sites/config/minTlsVersion",
          "less": "[parameters('minimalTlsVersion')]"
        }
      ]
    }
  ]
},
"then": {
  "effect": "[parameters('effect')]"
}

1. Wait ~1-hour after re-assignment and then try again.
2. Verify there’s no exemption in place.
3. Attempt the update again and watch for a 403 in the Activity Log.

Kindly review the following documents for your reference:

Please refer to the following documents

List of built-in policy definitions - Azure Policy | Microsoft Learn

Request disallowed by policy error - Azure Resource Manager | Microsoft Learn

If you find the answer helpful, please click "upvote" and accept it. This will help others in the community with similar questions easily find the solution.

Answer 2

Hello moti jirata

Greetings! Thanks for raising this question in Q&A forum.

Great question! Your policy definition looks structurally correct, but there are a few common reasons why a Deny policy like this doesn't actually block a change to minTlsVersion 1.0. Let me explain each one clearly and walk you through how to fix it.

Reason 1: The Effect Parameter May Be Overridden at Assignment

Your policy uses "effect": "[parameters('effect')]" which means the actual effect is determined at the time of assignment, not hardcoded in the definition. If the policy was assigned with the effect set to Audit or Disabled instead of Deny, it will not block anything it will only log non-compliance. Go to Azure Portal → Policy → Assignments, find your assignment, click on it, and check what value the effect parameter is set to. Make sure it is set to Deny.

Reason 2: Enforcement Mode May Be Set to DoNotEnforce

Even if the effect is set to Deny, the assignment has an enforcementMode setting. If this is set to DoNotEnforce, the policy will evaluate and report non-compliance but will NOT block any requests. Go to your policy assignment in the portal, click Edit assignment, scroll down to Enforcement mode, and make sure it is set to Enabled (not DoNotEnforce).

Reason 3: The Policy Scope May Not Cover Your App Service Resource

A Deny policy only applies to resources within the scope it is assigned to. If the policy is assigned at a resource group or subscription that does not contain your App Service, it won't apply. Confirm that your App Service is inside the subscription or resource group where the policy assignment is scoped.

Reason 4: The Field Path for minTlsVersion May Not Match Exactly

The condition in your policy checks Microsoft.Web/sites/config/web.minTlsVersion. However, Azure Policy evaluates Microsoft.Web/sites/config resources and their nested properties. It is worth double-checking by using the Azure Resource Explorer at https://resources.azure.com navigate to your App Service → config → web and confirm the exact property path returned. If the property is exposed differently (for example, as minTlsVersion directly under properties rather than under web), the condition won't match and the Deny won't fire.

Reason 5: The kind Condition May Be Excluding Your Resource

Your policy has "field": "kind", "notContains": "functionapp". Make sure your App Service is not of a kind that unexpectedly matches or mismatches this condition. For a standard Web App, the kind field is typically just app, so this should be fine but it is worth verifying by checking the resource in Azure Resource Explorer.

Step to Quickly Validate the Policy is Working

To confirm the policy is evaluating correctly, go to Azure Portal → Policy → Compliance, find your policy assignment, and check the compliance state of your App Service. If it shows as Non-compliant, the policy is evaluating it correctly but may not be blocking due to enforcement mode or effect setting. If it shows as Compliant or Not started, there may be a scope or condition match issue.

Once you set effect = Deny and enforcementMode = Enabled on the assignment, any attempt to set minTlsVersion to 1.0 on a Web App (non-function app) will be blocked with a 403 Forbidden response at request time.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.

Answer 3

The policy definition is structurally valid, but there are a few common reasons why a deny policy like this does not block changing minTlsVersion to 1.0:

1. Effect must be set to Deny at assignment time
   The policy definition parameterizes the effect:

      "then": {
        "effect": "[parameters('effect')]"
      }
   

   and the effect parameter has allowed values Disabled, Deny, Audit with default Deny.
   However, at policy assignment, the effect parameter can be overridden. If the assignment sets effect = Audit or effect = Disabled, the policy will not block changes; it will only log (Audit) or do nothing (Disabled). To enforce denial, ensure the assignment uses effect = Deny and that enforcementMode is not set to doNotEnforce.
2. Deny effect behavior
   With effect deny, Azure Policy prevents non-compliant create/update requests and returns 403 (Forbidden) before the request reaches the resource provider. Existing resources that are already non-compliant are only marked non-compliant; they are not automatically changed. If minTlsVersion is already 1.0 and the policy is assigned later, the resource will be evaluated as non-compliant, but the policy will only block future updates that keep or worsen non-compliance. The deny effect itself is working at request time, not retroactively changing the resource.
3. Condition logic must match the actual resource properties
   The if block uses:

      {
        "field": "Microsoft.Web/sites/config/web.minTlsVersion",
        "exists": "false"
      }
   

   and

      {
        "field": "Microsoft.Web/sites/config/web.minTlsVersion",
        "less": "[parameters('minimalTlsVersion')]"
      }
   

   For the deny to trigger, the evaluated minTlsVersion must either be missing (exists: false) or numerically less than the parameter value (1.2 or 1.3). If the resource provider exposes the property differently than expected (for example, a different field path or a string comparison that does not evaluate as less), the condition may not match and the deny will not fire.
4. Mode and evaluation
   The policy definition must have a valid mode (for example, all or indexed) and the policy must be assigned at the correct scope (subscription, resource group, etc.) that includes the App Service resource. If the policy is not assigned at the scope where the site resides, or if the mode prevents evaluation of this resource type, the deny will not apply.

To ensure the deny policy works as intended:

• Confirm the policy assignment parameter effect is set to Deny and not overridden to Audit or Disabled.
• Verify enforcementMode is not doNotEnforce while testing.
• Confirm the policy is assigned at a scope that includes the target Microsoft.Web/sites/config resource.
• Validate that the field path for web.minTlsVersion matches the actual property exposed by the resource provider.

---

References:

• Azure Policy definitions effect basics
• Azure Policy definitions deny effect
• Azure Policy pattern: parameters
• Azure Policy definition structure policy rule
• Tutorial: Create a custom policy definition