| Description | This article describes issues encountered when trying to manage FortiGate with differing private-data-encryption settings in the same ADOM. |
| Scope | FortiManager, FortiGate. |
| Solution |
FortiGate's private-data-encryption setting will encrypt all passwords stored on FortiGate when enabled, such as those used to authenticate against remote authentication servers, and those configured for local firewall users.
While FortiManager does support this setting, users will encounter issues managing FortiGates with different private-data-encryption settings.
In the following example, two FortiGates are being managed in the same ADOM, one with private-data-encryption enabled, the other disabled, both initially onboarded with the same policy package:
The private-data-encryption setting can only be enabled from FortiGate, after which the setting change will be auto-updated in FortiManager. To verify the encryption key for the first device, a manual config retrieve must be performed to prompt verification of the encryption key:
However, even though the encryption key has been verified when trying to install a change in the policy package, FortiManager will try to install the following settings to the FortiGate with private-data-encryption enabled:
This is because the user's password is not encrypted in FortiManager the same way as it was on FortiGate, resulting in different ciphertexts on both sides. As a result, FortiManager will detect the config difference and try to push it to the FortiGate with private-data-encryption enabled, which will fail:
To resolve this, a separate policy package can be re-imported from the FortiGate with encryption enabled to import the encrypted password for the guest user. As the guest user does not allow per-device mappings in FortiManager's Policy & Objects configuration, the re-import will overwrite the original password stored in FortiManager:
If all FortiGates in the same ADOM are required to use the same policy package, all of them need to have private-data-encryption enabled and be configured with the same encryption key to avoid this issue as well. In the above case, if a different encryption key is used for the second device, which is assigned the newly imported policy package from the first device, the same issue will occur when trying to install a policy change to the second device:
|
