Walkthrough: Integrating with Azure AD for user-based firewall policies.

Alright, let's start by acknowledging the elephant in the room: most of you are about to configure this integration and, in doing so, will blindly provision the 'recommended' VM size from the Azure Marketplace, committing to a ~$2,000/month compute bill before you've even written your first policy. A moment of silence for your CFO's spreadsheet, please.

Integrating FortiGate with Azure AD for user-based policies is fundamentally about tying a costly network egress point (the firewall) to an identity provider. The technical steps are well-documented, but the cost implications—where the real engineering happens—are conspicuously absent from Fortinet's guides. Let's walk through it, but with the ledger open.

First, the architecture. You'll be deploying:
* A FortiGate VM (inevitably an over-provisioned F-series in Azure).
* The FortiGate as a SAML SP, Azure AD as the IdP.
* FSSO (Fortinet Single Sign-On) agents or the LDAP connector to poll group memberships.
* Firewall policies referencing `sso-auth-user-group`.

The configuration snippets you'll find everywhere look like this:

```
config user saml
edit "AzureAD"
set entity-id "https://fortigate.yourdomain.com"
set single-sign-on-url "https://fortigate.yourdomain.com/saml/sso"
set idp-entity-id "https://sts.windows.net//"
set idp-single-sign-on-url "https://login.microsoftonline.com//saml2"
set idp-single-cert "Azure_AD_Certificate"
next
end
```

And for the policy:
```
config firewall policy
edit 0
set name "Allow-Engineering-AzureAD"
set srcintf "port1"
set dstintf "port2"
set srcaddr "all"
set dstaddr "eng-subnet"
set action accept
set schedule "always"
set service "HTTP" "HTTPS" "SSH"
set groups "AzureAD_Engineering_Group" <-- The magic line
set logtraffic all
next
end
```

Simple, right? Now, let's talk about the bill. The moment you tie firewall access to Azure AD groups, you create a dynamic, user-driven traffic pattern. This exposes the first major cost sink: **egress**. Your beautifully crafted policy for the 'Marketing' group to access a cloud service will now funnel all their video streams and file downloads through a FortiGate VM, incurring Azure's egress charges. Without tight application control and caching policies, you're just building a very expensive tube.

Second, the FSSO/LDAP polling agents. They require constant connectivity and, if placed in an Azure VM for redundancy (as many guides suggest), you've just added another ~$150/month per node for what is essentially a glorified cron job. The math rarely justifies it versus using the built-in SAML group claims, but the 'high availability' slide in the architecture deck always wins.

Third, and most egregious, is the sizing. Fortinet's Azure VM sizing guide is based on throughput and session counts for *all* traffic. If you're only using user-based policies for a subset of north-south traffic (say, only for remote user VPN), you do **not** need an `F4s_v2` or larger. You can often get away with a much smaller SKU for the policy engine, but the sales play and the quick-deploy button lead you to the most expensive option. I've seen teams spend $1,800/month to police $200 worth of actual risk.

So, before you deploy, answer these:
* What percentage of total traffic will actually be evaluated against Azure AD groups? Size the VM to that, not your internet pipe.
* Can you leverage Azure AD group claims directly in the SAML assertion to avoid running persistent polling agents?
* Have you configured explicit deny policies and application controls to prevent this from becoming a free-for-all egress gateway for every SaaS app your users can find?

The integration works. It's reliable. But enabling it without a corresponding FinOps review is how you turn a $500/month security control into a $3,000/month infrastructure anchor. The policy syntax is the easy part. The cost control is the real policy you need to write.