| Solution | In accordance with the documentation, AAA data is not excluded from the configuration synchronization process (expected to be synchronized): Synchronizing the FortiManager configuration. Upon logging in to the secondary unit, a pop-up notification reminds the user of the necessity to make all changes on only primary units: 
Under the GUI System Settings -> Admin, the options to add or change admin users are greyed out as well: 
But with access to the CLI of the secondary unit, the restrictions above are not applied anymore, and changes to the admin user section can be made independently from the primary node: FMG_2 # config system admin user (user)# show config system admin user edit "admin" set password ENC PB2+D18mgNhJtEQSoHMi3O9v2TjV5iGA7CLCSH3dscqAKvFTIKHVtSgmha3bqA6BNu+SLajbLKrYO0lonlAQXo8uO0BF+6PUsFaMEqO2RZw6uE= set profileid "Super_User" set rpc-permit read-write next edit "Johny" set password ENC PB2/BoKGJeCTwq4OE5/rQ3gLAtjMVFZmnMOXi/AnsKtNFTpuZpSVd9ccBjGiYrH0VbKw5DA9zfcGa+nz/is+a8mMuotQmvJC6KgGGz7wf/+Ly0= set profileid "Super_User" next end (user)# delete Johny <<<<<<<<<<<<<< (user)# show config system admin user edit "admin" set password ENC PB2+D18mgNhJtEQSoHMi3O9v2TjV5iGA7CLCSH3dscqAKvFTIKHVtSgmha3bqA6BNu+SLajbLKrYO0lonlAQXo8uO0BF+6PUsFaMEqO2RZw6uE= set profileid "Super_User" set rpc-permit read-write next end (user)# end FMG_2 # get sys ha-status HA Health Status : OK HA Role : Secondary FMG-HA Status : Synchronized State <<<<<<<<<<<<< Model : FortiManager-VM64-KVM Cluster-ID : 11 Debug : off File-Quota : 4096 HB-Interval : 10 HB-Lost-Threshold : 30 HA Primary Uptime : Wed Mar 18 10:12:07 2026 HA Primary state change timestamp: Wed Mar 18 10:12:28 2026 HB-Lost-Threshold : 30 ----- Cluster member 1: FMG_1, FMGVMSTM25001218, 10.12.10.59 Last Heartbeat : 7 seconds ago Last Sync : 208 seconds ago Last Error : Total Synced Data (bytes) : 790127 Pending Synced Data (bytes) : 0 Estimated Sync Time Left (seconds): n/a HA Sync status : n/a System Usage stats : FMGVMSTM25001402(updated 0 seconds ago): average-cpu-user/nice/system/idle=0.20%/0.00%/0.20%/99.49%, memory=16.83%
The primary unit also shows that it is in sync, and users are unchanged: FMG_1 # get sys ha-status HA Health Status : OK HA Role : Primary FMG-HA Status : Synchronized State <<<<<<<<<<<<<<< Model : FortiManager-VM64-KVM Cluster-ID : 11 Debug : off File-Quota : 4096 HB-Interval : 10 HB-Lost-Threshold : 30 HA Primary Uptime : Wed Mar 18 10:12:07 2026 HA Primary state change timestamp: Wed Mar 18 10:12:28 2026 HB-Lost-Threshold : 30 Primary : FMG_1, FMGVMSTM25001218, 10.12.10.59 ----- Cluster member 1: FMG_2, FMGVMSTM25001402, 10.12.20.126 Last Heartbeat : 7 seconds ago Last Sync : 488 seconds ago Last Error : Total Synced Data (bytes) : 790127 Pending Synced Data (bytes) : 0 Estimated Sync Time Left (seconds): 0 HA Sync status : up,in-sync <<<<<<<<<<<<<< System Usage stats : FMGVMSTM25001218(updated 0 seconds ago): average-cpu-user/nice/system/idle=0.20%/0.00%/0.31%/99.29%, memory=18.18% FMGVMSTM25001402(updated 7 seconds ago): average-cpu-user/nice/system/idle=0.05%/0.00%/0.51%/99.33%, memory=16.82% FMG_1 # config sys admin user (user)# show config system admin user edit "admin" set password ENC PB2+D18mgNhJtEQSoHMi3O9v2TjV5iGA7CLCSH3dscqAKvFTIKHVtSgmha3bqA6BNu+SLajbLKrYO0lonlAQXo8uO0BF+6PUsFaMEqO2RZw6uE= set profileid "Super_User" set rpc-permit read-write next edit "Johny" <<<<<<<<<<<<<< set password ENC PB2/BoKGJeCTwq4OE5/rQ3gLAtjMVFZmnMOXi/AnsKtNFTpuZpSVd9ccBjGiYrH0VbKw5DA9zfcGa+nz/is+a8mMuotQmvJC6KgGGz7wf/+Ly0= set profileid "Super_User" next end
The change above is not an issue while all operations are executed on the primary node. But as soon as HA failover is executed, the secondary node gets promoted to the new primary node, and the haworker process begins synchronization. In the results of the synchronization, the previous secondary node will become the source of truth, and all configuration changes in the admin users section will be applied for the whole HA cluster. In other words, in the current example, the user 'Johny' will be removed from both FortiManagers with the following message in Event Logs: "itime=1768998059","date=2026-03-18","time=10:11:59","devid=FMGVMSTM25001402","vd=root","pri=notice","type=event","subtype=system","","","","changes=path=system.admin.user,key="Johny","act=delete","cli_act=add","cmd_from=cli","desc=CLI execution info","idseq=68647977811443712","log_id=0001010026","msg=","objattr=","objname=","operation=delete","","","path=system.admin.user","performed_on=haworker","session_id=0","tz=+0100","user=daemon_admin","","userfrom=haworker",""
Considering all of the information above, it is good practice to maintain a log of the CLI output of the config system admin user from the primary node. This information can be used to restore access in the event of unintentional changes. |
