Top Down vs. Bottom Up Management

When creating an Administrative Domain you define one of the two modes in which you wish the ADOM to operate: “Normal” or “Backup.”

An ADOM in “Normal” mode operates, as most would expect when using most centralized management solution, with a “Top Down” structure enforced. In a Top Down management architecture, all device configurations are centrally maintained and then provisioned to the managed devices.

When a FortiGate is managed in a “Normal” mode ADOM, direct access to the devices is still supported. However, making changes at the device can cause synchronization conflicts with the FortiManager, which would need to be remedied as described later. If the managed devices are running FortiOS 4.3 or later, you will be warned when logging in that the device is centrally managed and that changes should be done via the FortiManager. The warning banner also provides you with the option to login into the system in a read-only mode, in a privileged (read and write) mode or to logout.

One of the advantages of a FortiManager over many other solutions is the ability to additionally support the “Backup” mode. This allows for a “Bottom Up” deployment where all configuration is performed at a device level, but the FortiManager Administrative Domain allowing for a “Bottom Up” deployment architecture. When managing device within a “Backup” mode ADOM, the administrators are able to continue operating in an environment where all configuration management is maintained at the device level. While no configuration provisioning is centrally maintained, the FortiManager can still be leveraged for revision control as a configuration repository, for script deployment, centralized firmware upgrades, FortiGuard service updates, and device monitoring.

Creating Administrative Domains

Before you can create multiple ADOMs to suit their deployment requirements, you must first enable Administrative Domains.

To enable ADOMs through the Web UI, simply go to the “System Settings” tab and navigate to the “System Settings → General → Dashboard.” Once at the dashboard, locate the “System Information” widget and select the “Enable” link on the row for “Administrative Domain.” After confirming that you want to enable ADOMs, you will be required to log back into the FortiManager.

Upon re-authenticating, the administrator will encounter a slightly different tab layout. Gone will be the “Device Manager” and “Policy & Objects” tabs and instead we will now see the “Administrator Domain” tab. In this new tab, we are able to create, edit, and delete administrative domains for our administrative needs.

From the ADOM tab we are able to view the ADOMs created on the FortiManager as well as the device statuses within each ADOM. If this is the first time accessing the ADOM tab, only the default “root” ADOM will be visible. In order to create additional ADOMs, we simply select the “Create New” button or right click and select the option “New.” Upon doing so we will be presented with the ADOM creation screen (see Figure 9.2).

Start by giving the new ADOM a name and “Version.” The Version selected must correlate to the firmware revision of the devices to be managed. As of this writing, the supported versions are 4.0 MR2 and 4.0 MR3. The “Mode” of operation will either be left as “Normal” or changed to “Backup.”

If you choose to continue to create the ADOM in Normal mode, you will also need to select the “VPN Management” options. The choices are “Central VPN Console” and “Policy & Device,” both covered in some detail later. Last, you will have the option to select from devices already being managed and include them into the ADOM. You can select none, one, or many devices depending on the requirements. However, bear in mind that any devices moved into this new ADOM will no longer be accessible in their previous.

After ADOM creation, you can always use the right click option to “Edit” the ADOM and change any of the configuration options. To enter an ADOM and manage your device, you can right click over the desired ADOM and select “Enter ADOM.” Then hover your mouse over your intended ADOM and select the “Enter” button that appears or use the drop down menu in the top right of the Web UI.

Once in the ADOM, you will find your “Device Manager” and “Policy & Objects” tabs unique to the ADOM. Each ADOM maintains its own device, policy, and objects databases, allowing for unique configurations of the devices within each ADOM.

“Add Device” Wizard

There are multiple approaches for importing devices into the FortiManager. The first of the two approaches we will cover is the “Add Device” wizard. This wizard will walk you through discovering your device settings, importing policies and objects, and exporting them to the security console “Policy and Object” tab. It will also walk you through the process of mapping the device interfaces to the security console’s Zones.

Selecting the “Add Device” button toward the top of the window will launch the import wizard and walk you through the steps to import your device.

The first screen is where we input the IP Address, User Name, and Password information for the device we want to add to the manager. The User Name and Password must be that of a privileged administrator on the device we intend to import. FortiManager will use this account to read and write directly to the managed device when we deploy configurations, execute CLI scripts as well as manage firmware upgrades. If there is a concern about the level of privilege for the specific administrative account, that account can be locked down to the IP addresses of the FortiManager system using the trusted host option on the device.

You also have the option to add a modeled device if you want to prepare to manage a system that is not yet in production. When adding the modeled device, you will provide the IP Address, User Name, and Password for the device to be managed. However, unlike when adding a live device, the wizard will not walk you through the importation of objects and policy configuration as those settings would not yet exist.

By selecting “next,” the FortiManager will attempt to login and query the device using the account provided. Assuming good IP connectivity exists, allowing TCP port 514 access to the device, the account has the correct access right to the device and the device is configured to allow FortiManager administration on the interface to which you are attempting to connect, the device will be discovered and you will be provided a summary. This summary will include the IP Address, Admin User, Device Model, Firmware Version, Serial Number, and the High Availability Mode of the device. If all the information is what as expected, you can select “next” to move forward. If there was an error, you can go “Back” and correct your mistakes.

The next step allows you to choose a name and description for the device. The default value will be what is configured on the device, though if that is not unique enterprise-wide, you may wish to change it. During this step, you can also choose to include this device into one of the defined groups. You will also be able to add other administrative information such as the location and a primary contact.

As you move to the next step in the wizard, the FortiManager will retrieve all the device’s configuration settings and load them into the FortiManager device database. Once added, the FortiManager will walk you through mapping the device’s interfaces to Zones, importing the security objects into the ADOM’s Object Database, and copying the policies into a Policy Package. If the device being imported is configured with multiple VDOMs, the wizard will walk you through these processes for each individual VDOM.

During the Zone mapping of the device’s physical interfaces, the FortiManager will present you with those interfaces that have policies applied and offer to create Zones with names that match the interface names. At this point, you can choose to accept the new Zone names, to map the interfaces to a new Zone, or map them to Zones that have already been created in the Policy and Object console. If you wish to select an existing Zone, you can begin typing the name of that Zone. If you are not positive of the Zone name you wish to select, character match-based suggestions will be presented. However, be aware that these suggestions are case sensitive.

The last option to select is whether or not you want the FortiManager to automatically map all of the interfaces to Zones with names matching those of the interfaces themselves, but without policies applied. This is often useful for devices with many interfaces.

The next steps walk through the process of importing the policy configuration from the device into a New Policy Package where you can select the name of the package as well as the package folder in which to store it. You also have the option to import all of the device’s policies or choose to select specific rules to be imported. Understand though that everything set in the Policy Package, the next time you push to the device, will be the policy set on the device. If you do choose to leave policies out of the import process, expect those policies to vanish from the device when the package is modified and redeployed to the platform.

During the import process, you will be able to review the object being imported, view any duplicates that will not be imported, and be presented the option to choose which object to keep to resolve conflicts with an already-existing object of the same name in the database. Once this process is complete, you will see a summary created as well as the option download and view the “Import Report.” The import report provides us a more detailed summary of the zones, policies, and object imported.

Adding Multiple Devices

The second method to discuss is only available if you have enabled the “Show Add Multiple Button” in System Settings → Admin Settings. This provides the ability to add multiple devices to an administrative domain in a single action. By navigating to the “All FortiGate” folder within the Device Manager tab, you can select the “Add Multiple” button and be presented with a new screen. By providing the Name, Device Type, IP Address, Admin User, and Password for each device you intend to add, the FortiManager will query each and import the configuration into the database (see Figure 9.3).

This process does not include an automatic walk through to assist with importing the objects and policies into the FortiManager’s Policy & Objects database. This can be helpful when adding multiple devices to be managed by the same policy package.

If you must install the objects and policies from any of the devices, the process is pretty straightforward. After you select the “All FortiGate” folder, right click on the device you wish to import and select “Import Policy.” This will walk you through the Zone Map, Object, and Policy portion of the Add Device wizard and, following the same process outlined earlier, will import the information into the Policy & Objects database. For each additional device to import, you will repeat this process (see Figure 9.4).

Device Groups

With many devices to manage, the creation of Device Groups will help to organize and manage the environment. Groups not only allow us a way to view our device-based organization relationships, but also allow us to execute actions such as configuration and firmware deployments at the group level, thereby reducing the operational step to managing the environment. It is also possible to nest group to provide a potential hierarchy of management.

Select the “Add Group” button to create your Device Group. The “Add Device Group” window will appear, allowing you to name the group, select the group OS type, and the device and/or groups to be included in the new group.

Once your groups are created, they will allow you to monitor those devices in the group as well as allow you to deploy scripts and firmware to the devices in the group without requiring you to perform those tasks on a device-by-device basis (see Figure 9.5).

Policy Package Management

The “Policy” tree is where you will maintain and organize the policy packages used to define the firewall security configurations that are to be installed down to the managed devices. Policy packages can be assigned to a single or multiple devices based on the administrator’s requirements. This allows for a significant reduction in the workload required to maintain the security posture of potentially thousands of devices.

The first time entering the “Policy & Objects” tab, the administrator will find the policy package named “default.” If the administrator has already used the “Device Manager,” there may also be additional policy packages available. Use of the installation wizard was covered in detail during the “Device Manager” section above.

To create a new policy package, simply right click on “Policy” in the left pane and select “New,” “Policy Package.” This selection will present the administrator with the “Create New Policy Package” pop-up. When creating a new policy package, you are required to provide a unique name for the new package. When creating it, you also have the option to clone an existing policy package and/or select the installation target or targets to which the package will be applied (see Figure 9.8).

The cloning option allows you to create a new package based off of an existing template, to create a copy or backup of an existing package that you plan to manipulate, or for any other reason to duplicate an existing package. Once you select “Clone Policy Package,” a list of the available packages is displayed. Simply select the presented package you intend to clone.

The last decision to be made when creating a new policy package is to determine the installation target or targets for the new package. Targets can include a single managed device, multiple managed devices, one or more device groups, or any combination of devices and groups, including none. Selecting “apply” to complete package creation without selecting at least one device to install the package on will result in a warning that no targets have been selected. If you did not select a target in error, simply select cancel when warned and choose your targets and reapply. It is, however, perfectly acceptable to create a package that does not contain any active targets. Installation targets can always be selected after package creation by right clicking on the package name and selecting “Edit.” A screen similar to the package creation screen will be presented, allowing the administrator to select additional devices and/or remove existing targets.

While a single policy package can be assigned to multiple devices, deploying multiple policy packages to a single device may not have the desired or expected results. While it is possible to have more than one package configured for the same target, the intent is not to have multiple packages applied to the device at the same time. During the deployment process, each package overwrites the previous. So, installing multiple policy packages to a device in sequence will have the result of only the last package taking effect. If an administrator was to install multiple policy packages to a device or group of devices in sequence, the last policy package applied will define the rule set on the device or devices overwriting the rule sets applied in the previous installations. Without the understanding that applying multiple packages does not have a cumulative effect on the security posture will create a situation where you do not have the setting you want on the device and potentially cause a degraded security posture.

If there is a requirement to have a layered rule set, a simple example being a corporate security policy that needs to be applied to all Firewalls regardless of the local administrators rule base, this is possible with FortiManager. We will cover this topic by describing the use “Global Policy Packages” later in this chapter.

If an administrator finds they need to manage many policy packages, it may be convenient to organize the packages into folders. Similar to creating a new package, one would again right click on “Policy” in the left pane and then select “New” → “Folder,” provide a name for the new folder, and select “OK.” In order to organize the policy packages into folders, simply left click on the package and drag that package into the folder desired. If the complexity is warranted, folders can be created and organized hierarchically.

As packages are intended to maintain the security policies to be deployed to the devices, individual policies are created similarly to how policies are created within the FortiGate Web UI. However, the Web UI of the FortiManager is much more flexible, as it allows you to copy, cut, and paste polices, as well as drag and drop policies for reordering. You are provided much more flexible search and “where used” capabilities and a context-sensitive right click function that will present different functions, based on the policy package you intend to manipulate (see Figure 9.9).

Unlike a policy set on a device that references the interfaces and security objects of that device, policy packages can apply to a single device or many devices. To accomplish this, the packages will reference values from the domain’s Object database.

Managing Security Objects

Each Administrative Domain has a database for administrators to create the security objects needed to maintain their environment while avoiding name and value conflicts, as different ADOMs have their own database space.

As mentioned previously, the administrative workflow is nearly identical to that seen in the FortiOS Web UI. The key difference is that these objects will be applied across policy packages that affect the security posture of potentially thousands of devices. This greatly reduces the work required to tune the environment’s security.

Installing Policy and Device Configurations

When an administrator must deploy configuration changes to the managed device, they will want to verify them prior to deployment. First, an administrator may wish to leverage the “Policy Check” feature. This is only available if you have enabled it in the “Admin Setting” section. Policy Check runs a validation process against all the Policy Packages in the domain and will indicate conflicts, shadowed policies, duplicate objects, and candidates for optimizations (see Figure 9.10).

After you are comfortable with your packages and are ready to deploy them, the “Install” wizard will walk you through the process. You will be prompted to install all pending changes including the Policy Package data or to just install the device level configurations. If you choose to deploy all pending changes, the wizard will allow the selection of which Policy Packages are to be deployed and to which of the targeted devices. During the wizard execution process, the interface to zone mappings will be validated, giving you an opportunity to preview the changes. After successful deployment, the FortiManager will save a new revision in the device’s revision history, assisting with future auditing (see Figure 9.11).

Global Policy & Objects

In some environments, there will be a need to have individual administrators responsible for their respective devices while still allowing a more senior administrator to override policies. The FortiManager allows this hierarchical approach to deploying policy through the use of “Global Policy & Objects.”

Like the other features on the device, Global Policy & Objects is a licensed feature that is enabled in Admin Settings. This workflow and configuration tasks are nearly identical to the workflow of tasks in the Policy & Objects section. The few differences between the workflows are detailed below.

First, the Global Packages consist of “Header” and “Footer” policies. While the policies are created and managed like those in a normal packager, in a Global Package, the Header Policies will be prepended to any Policy Package at the ADOM level. However, the Global Package is also assigned as the Footer Policies will be appended to the policy set in the local ADOM packages. This provides the ability to override the ADOM Packages with Header Policies and to use Footer Packages to add trailing rules prior to the implicit deny (see Figure 9.12).

Like the ADOM “Install” wizard used to deploy changes to the managed devices, Global Policy & Objects are deployed to the Policy Packages in the ADOM using the “Assignment” wizard. When launching the Assignment Wizard you select the Global Package to be deployed and the ADOMs and/or Policy Packages within the ADOMs to which you will assign the Header and Footer Policies. New Header and Footer Policies are not deployed to the managed devices until you select to use the Install wizard in the appropriate ADOM (see Figure 9.13).

Finally, understand that to use Global Zones their names must match those of the ADOM zones to which they will be applied. If there are no matches, the assignment will fail. As of this writing, zone names do not “inherit,” so preplanning zone naming is important.

Policy and Device VPNs

The first, and default, method is known as “Policy and Device VPNs.” If you are required to utilize multiple ADOMs in managing your environment, it is also the default mode selected when creating each additional administrative domain.

With this approach, IPSec configuration is managed in the “Device Manager” tab. The Phase I and Phase II configurations are constructed and maintained on a device-by-device basis with a configuration workflow effectively identical to that seen in FortiOS. Because the IPSec configurations are maintained on an individual device basis, this mode of operation does not provide much economy of scale during the tunnel creation process. However, there are still many advantages in using the FortiManager to maintain devices security postures. You can leverage the common object database and policy packages to simplify the workflow required once the tunnels are established.

Central VPN Console

As you can see, using FortiManager with to maintain a distributed VPN environment has advantages over accessing each device individually. What may also be evident is that, for every device we want to add to the VPN, there are many steps for creating the objects, polices, tunnels, and routing required. The more steps involved with any process, the greater chance for errors to occur causing unwanted results.

To help us reduce the number of steps required to build a VPN network, FortiManager provides a second mode of VPN management. The “Central VPN Console” helps automatically provision IPSec VPN tunnels and routing requirements when creating a large-scale distributed Hub and Spoke or Fully Meshed VPN.

The Central VPN Console is configured on a per ADOM basis, but before an administrator can use this function, they must globally enable the option. To do this, simply navigate to the Admin → Admin Setting section within the System Settings tab, check the option for “Show VPN Console” and select apply. Once this option is selected, the VPN console will show up within those ADOMs where we will change the VPN management mode from “Policy and Device VPNs” to “Central VPN Console” (see Figure 9.27).

If you are not using multiple ADOMs, you will enable the Central VPN Console in the System Information widget of the General → Dashboard within the System Settings tab. If the FortiManager is configured to use multiple ADOMs, enabling the Central VPN Console on a per ADOM basis is accomplished by right clicking and selecting “Edit” for the ADOM to be modified. Once the edit screen for the ADOM appears, change the VPN Management option to “Central VPN Console” and then “OK” (see Figure 9.28).

Now that we have enabled the Central VPN Console, we may reenter the ADOM and generate our VPN. To punctuate the advantages of using this mode, we reference the same VPN layout as earlier. Assuming your devices are already installed to the FortiManager and your Zones for firewalls are mapped, there are just a few steps to prepare before creating your VPN. There are then a mere handful of actions to define and deploy your VPN.

First, we must define a Firewall Address object for each protected subnet. These address objects will be used in our policy creation as before but they will be also used when defining each managed gateway device in our VPN configuration.

Once our address objects are defined, we may construct our VPN. The Central VPN Console is capable of maintaining multiple Star, Mesh, or Dialup VPNs. If we navigate to the Policy & Objects tab, we find the VPN Console nested at the bottom of the left window pane. With our focus on the VPN Console, we select “Create New” and then select a Star configuration for our example. We must then define our Phase I and Phase II configuration. These settings will be used by the VPN Console to create the tunnel configurations on each of the devices which we will add as managed VPN gateways. This allows us to define these settings once for each device in the VPN, eliminating the risk of misconfiguration that occurs when we configure tunnels on a device-by-device basis (see Figure 9.29).

After committing our changes by selecting “OK,” our focus will shift to the main screen and require us to select the VPN we just created. To select this, click on the VPN name you wish to manage. Once in the VPN you can select “Create New” to define either a “Managed” or “External” gateway. As each device you create is part of the VPN, and managed by the FortiManager, we will create all of our devices as Managed Gateways.

The first VPN member to be created is the “HUB” in our Hub and Spoke/Star configuration. While there are only a few items to define, there are a few things that will make your first installation go smoothly. Set the “Node Type” to “HUB,” and select the Device named Hub. Then select the Zone name mapped to the outside interface where the IPSec tunnel is created with the value “Default VPN Interface.” At the time of this writing, the name of this value is misleading. The options in the drop down list are Zone names, not physical interfaces. It is likely that this will be renamed in a subsequent software release so it will more appropriately describe the value needing to be selected.

The value “Hub-to-Hub Interface” could also be a Zone name. While supported, in our example we are not creating a dual hub star configuration and will not need to define a Hub-to-Hub connection. If we were to create a dual hub solution, this value would help create an IPSec tunnel between the two hubs for routing of VPN traffic.

Another task we had to perform in the earlier examples was the creation of the appropriate routes to ensure traffic would traverse the correct tunnel when accessing the protected segments. With the VPN console, you can have the FortiManager automatically create the routes. By selecting “Automatic” as the routing value, the FortiManager will take the “Summary Network(s)” and “Protected Subnet” values and propagate them to the remote devices so they can use the tunnels for the correct subnets.

The two values “Summary Network(s)” and “Protected Subnet” are populated with the firewall address objects created earlier. You can use either “Protected Subnet” for individual routes desired to be seen on the remote devices. “Summary Network(s)” can also be used, assuming the summary route is not overly general. This avoids routing confusion at the remote locations (see Figure 9.30).

Once we commit the configuration for our Hub, we will follow the same process for adding the remote locations as spokes in our VPN. The one difference in the configuration is selecting the “Node Type” as “Spoke.”

Once the VPN is configured, we simply configure our Policy packages to allow the appropriate traffic in and out of the new tunnels. The VPN Console creates the VPN with Interface Mode tunnels, so we will create our policies as “Accept” policies. Another advantage of using the VPN Console is to not have to create Zones and map them to the interfaces at each individual device.

When using the VPN Console, FortiManager automatically creates three different Zones to be automatically mapped to the appropriate interface based on our configurations when adding devices into the VPN Console. These special Zones appear as options for the source and destination Zones when creating policies in our policy packages. Each Zone name will be created with three values separated by the “_” character. The first value is “vpnmgr” to identify that the Zone was created by the VPN Console. The second value will be the VPN name used when the VPN was created, allowing you to select to correct Zone when multiple VPNs are defined.

The third is one of the three values. The first of these, “hub2spoke,” is used to identify the source and/or destination Zone when defining the policy for the Hub. The second of these values, “spoke2hub,” is used to identify the source and/or destination Zone when defining policy for the spokes. The last of these values, “mesh,” is used to identify the source and/or destination Zone by all locations in a full mesh VPN.

In our example we find the Zones vpnmgr_VPN_Test_hub2spoke, vpnmgr_VPN_Test_spoke2hub, and vpnmgr_VPN_Test_mesh. For those paying attention, you may have noticed a third “_” between the words “VPN” and “Test.” This underscore is actually part of the name “VPN_Test” used when we initially created our VPN. All spaces in VPN names will be converted to underscores when accessed in this manner (see Figure 9.31).

We once again find ourselves having completed our configuration and may deploy our device and policy package configurations. Like before, once both the Policy Packages and Device Settings are pushed to the Hub and remote sites, you may begin testing and using your centrally managed Policy Mode VPN.