PFE Architecture Question: FortiClient Custom Installer Distribution – Dedicated DMZ File Server vs. Exposing LAN EMS Apache via WAF
Hey everyone,
​I'm currently working on my PFE (Graduation Project) focused on deploying a Zero Trust Architecture using the Fortinet Security Fabric. I’m finalizing the deployment strategy for the FortiClient custom installer distribution, and I'd love to get some architectural feedback from the community.
​The Goal: Securely distribute the custom installer generated in EMS to remote endpoints during an initial onboarding period, and then tightly lock down registration afterward.
​The Environment: My core EMS server lives inside the secure Server LAN.
​For both options below, the download page is protected by a FortiWeb WAF that requires Active Directory (AD) pre-authentication before a user can access the installer. However, given the recent high-severity vulnerabilities (like the 8013 auth bypass CVEs), I am highly paranoid about zero-days and expanding the internal attack surface unnecessarily.
​Here are the two design paths I am debating:
​Option 1 (Dedicated DMZ Server + WAF + AD Auth): I spin up a separate, dedicated web server inside the DMZ (alongside our public website) purely to host and serve the static custom .msi/.pkg installer files. The WAF handles AD auth and protects this DMZ server. The internal EMS server remains completely hidden from the internet.
​Option 2 (Exposing LAN EMS Apache + WAF + AD Auth): I don't build a new DMZ server. Instead, the WAF handles AD auth and forwards successful traffic straight into the internal Server LAN to expose the built-in Apache web service running directly on the EMS server to download the custom installer page.
​My Proposed Security Lifecycle:
​To mitigate the risk of leaving registration open, my post-onboarding plan is:
​During Onboarding: Allow public access (via AD credential login on FortiWeb) to download the pre-configured custom installer (which has the telemetry key embedded).
​Post-Onboarding: Disable the global invite code and change the telemetry key on EMS. This effectively makes that initial custom installer useless for any unapproved devices trying to phone home.
​Ongoing Operations: For any new client onboarding after this main phase, I will generate an individual, strictly monitored invite code to track exactly how many times it's used and tightly control registered devices.
​My Questions for you guys:
​Is Option 1 still the superior choice here from a security standpoint? My logic is that even with FortiWeb doing AD pre-authentication, if a zero-day drops that allows a WAF/Auth bypass, Option 1 only compromises a dummy file server in the DMZ. With Option 2, a bypass gives an attacker direct access to the EMS server's built-in Apache service right inside the Server LAN.
​Does my logic for rotating the telemetry key and switching to individual invite codes hold up in a real production environment?  Thanks in advance for any insights!