Azure deny Policy

moti jirata 25 Reputation points

I am trying to create a deny policy for web apps where the users must have minTls above 1.2 and another policy where the webapp should only accept ['FTPSOnly,Disabled']. But when i assign it it doesnt work and co-polite points out that Microsoft.Web/sites/config - child resource, Deny doesn't work reliably. So i was wondering it is possible to have a Deny police if the its not a top-level resource, such as httpsonly?

  1. Bharath Y P 9,730 Reputation points Microsoft External Staff Moderator

    Just checking if the information shared was helpful. If so, please consider accepting the answer and giving it an upvote.

    If you have any further questions or need additional clarification, feel free to reach out. Thanks!

  2. Bharath Y P 9,730 Reputation points Microsoft External Staff Moderator

    Just checking if the information shared was helpful. If so, please consider accepting the answer and giving it an upvote.

    If you have any further questions or need additional clarification, feel free to reach out. Thanks!


Sign in to comment

3 answers

  1. Bharath Y P 9,730 Reputation points Microsoft External Staff Moderator

    Hello Moti, you’ve hit a known quirk in Azure Policy – the Deny effect doesn’t reliably fire on true “child” resource types like Microsoft.Web/sites/config. You have two main options:

    1. Target the top-level resource (Microsoft.Web/sites) and inspect the nested properties
    2. Use a built-in policy / modify effect if you can’t get a pure Deny

    1) Deny on the parent with nested fields

    Instead of writing your rule against type “Microsoft.Web/sites/config”, scope it to “Microsoft.Web/sites” and then check siteConfig properties. For example, a combined deny for min TLS and HTTPS-only would look like:

    
    {
    
     "mode": "Indexed",
    
     "policyRule": {
    
     "if": {
    
     "allOf": [
    
     {
    
     "field": "type",
    
     "equals": "Microsoft.Web/sites"
    
     },
    
     {
    
     "anyOf": [
    
     {
    
     "field": "Microsoft.Web/sites/config/minTlsVersion",
    
     "notEquals": "1.2"
    
     },
    
     {
    
     "field": "Microsoft.Web/sites/config/ftpsState",
    
     "notIn": [ "FtpsOnly", "Disabled" ]
    
     },
    
     {
    
     "field": "Microsoft.Web/sites/config/httpsOnly",
    
     "equals": false
    
     }
    
     ]
    
     }
    
     ]
    
     },
    
     "then": {
    
     "effect": "deny"
    
     }
    
     }
    
    }
    
    

    Aliases you’ll leverage here are:

    • Microsoft.Web/sites/config/minTlsVersion
    • Microsoft.Web/sites/config/ftpsState
    • Microsoft.Web/sites/config/httpsOnly

    Because you’re checking them on the parent resource, Deny will fire reliably at create/update time.

    2) Use built-in policies or a Modify effect

    If you don’t strictly need Deny, consider:

    • The built-in policy “Configure minimum TLS version for Web Apps” (you can change its effect to Deny or Modify)

    • The built-in policy “Configure FTPS state for Web Apps”

    • A Modify (or DeployIfNotExists) policy to automatically flip settings you care about

    These built-ins already handle the right aliases and parent scoping for you.

    Follow-up questions

    1. Can you share the exact JSON you used for your custom policy definition?
    2. At what scope did you assign it – subscription, resource group or management group?
    3. Did you test on a brand-new web app deployment or an existing one?
    4. Are you seeing any errors in the Activity Log or CLI/PowerShell output when you deploy?

    Hope this helps you lock in TLS ≥1.2 and FTPSOnly/Disabled on your Web Apps!

    Reference documentation

    • Azure Policy definition structure & effects:

    • Policy alias reference (Web Apps):

    • Create and assign policies programmatically:

    Hope this helps. If the information was useful, please consider accepting the answer and upvoting. Feel free to reach out if you need any further assistance. Thank you.

    0 comments No comments

    Sign in to comment
  2. moti jirata 25 Reputation points

    Then when using AuditIfNotExists why do we use an existancecondition in the then field/block?

    0 comments No comments

    Sign in to comment
  3. AI answer

    Azure Policy deny effects work on both top-level and child resources, including Microsoft.Web/sites/config, as long as the policy definition is authored correctly and the effect is supported for that resource type.

    Key points from the provided context about deny:

    • A policy definition has a condition (if) and an effect (then). The effect can be Deny among others.
    • When a deny effect is used, any create or update request that matches the condition is blocked before it reaches the resource provider and returns 403 (Forbidden).
    • Existing resources that match a deny policy are marked non-compliant during evaluation.

    From the custom policy example in the context (for storage accounts and HTTPS-only):

    • The policy uses mode: "all" and a Deny effect to block storage accounts that don’t have supportsHttpsTrafficOnly set to true.
    • The same pattern applies to other resource types and child resources, as long as the alias used in the if condition correctly targets the property (for example, Microsoft.Web/sites/config properties such as minTlsVersion, httpsOnly, or ftpsState).

    So, it is possible to have a deny policy for non–top-level resources like Microsoft.Web/sites/config (for minTlsVersion, httpsOnly, ftpsState, etc.). If a tool warns that “Deny doesn’t work reliably” for that child resource, the issue is likely with how the policy is authored or evaluated (for example, incorrect alias, mode, or effect wiring), not with a general limitation of Azure Policy deny on child resources.

    For safe rollout of such deny policies, the recommended approach is:

    1. Start with the effect set to Audit (or via an effectType parameter defaulting to Deny but temporarily set to Audit) and validate compliance.
    2. Use resource selectors and assignment overrides to gradually move from Audit to Deny and expand to more regions/tiers, as shown in the safe deployment guidance.

    This same pattern can be applied to:

    • A policy that denies web apps where minTlsVersion is below 1.2.
    • A policy that denies web apps whose FTPS setting is not in ['FtpsOnly', 'Disabled'].

    Once the correct aliases and conditions are used, and the effect is Deny, Azure Policy will block non-compliant updates even for child resources.


    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.
Sign in to answer

Your answer