Deployment procedures
The deployment example has the following topology:
In this example topology, a customer has several servers running in their internal corporate network. Web access to the servers are divided by user groups.
|
User |
AD User Group |
Access |
|---|---|---|
| FortiAD\Tom Smith (tsmith) | Sales |
Webserver1 Webserver2 |
| FortiAD\Dan Parker (dparker) | Finance |
Webserver1 Webserver2 Finance server |
| FortiAD\Administrator | Administrators |
Webserver1 Webserver2 EMS server FortiAnalyzer FortiAuthenticator |
User authentication is managed by Windows Active Directory. Each user logs into the FortiAD domain for authentication on their workstation. FortiGate integrates with Windows AD via a LDAPS connection and uses the same user groups for SSL VPN and ZTNA.
The web mail server is accessible by all via a Virtual IP. The EMS server registration and telemetry service (TCP/8013) is also accessible by all via a Virtual IP. They do not require SSL VPN or ZTNA policies to access.
The FortiAuthenticator is optional in this environment. It can be used to provide different types of authentication such as SAML or RADIUS, or provide MFA via FortiTokens or email OTP. In this Deployment Guide, the FortiAuthenticator is not used for authentication. However it is used to demonstrate a Web application accessible by the Administrators group.
Lastly, this topology simulates on-net users in the 10.0.1.0/24 network, using a default DNS server on 10.88.0.1. Off-net remote users on the other hand are on the 10.0.3.0/24 network, using the FortiGate 10.0.3.254 as its default DNS server. Users should have the same level of access whether on-net or off-net.
Migrating from SSL VPN to ZTNA for hosted Web Applications
Before migration can occur, we must examine the current SSL VPN configuration and topology, assess components and configurations that can be re-used, and then prepare the components for ZTNA. Migrations is performed one server at a time, starting with servers accessible by the least number of users and groups.
This chapter will walk through the following:
The goal is to apply device identity and posture check to prevent unauthorized devices or vulnerable devices from accessing the hosted Web applications. Security posture check in our example amounts to the following:
-
Devices are checked for critical vulnerabilities. If critical vulnerabilities exist, devices cannot be trusted.
-
Devices are checked for domain registration. They must be registered to the company’s Active Directory domain.