nasty Bug with FortiManager and global Addressobjects

[sw2090]

We just ran into this issue and I just wanted to warn you to not do so too:

if you rename global address objects in FMG you can only do that via script (TAC said this).

If you assign this to an adom afterwards it will be correctly assigned.

You will have the renamed object in the adom and if you right-click that object and choose "where used" it will show you the correct references.

However if that is a policy and you edit that policy the corresponding field will be empty. 

You will not be able to deploy policy package until you correct that because it will fail because of the empty fields in your policies.

This at least affects global address objects. Cannot say about service objects as we haven't checked that yet and upon deployment it didn't complain about services.

Accoarding to TAC this is a known Bug that at least affects FMG v7.0 (cannot say anything about 7.2 or 7.4).

This also let's me wonder why TAC suggests renaming global objects by script when they know there is a nasty bug with that.

I still have a Ticket and a case open (which now got Priority C1!) with TAC and am waiting for news.

[sw2090]

TAC told me there is a similar issue with FMG API that already is known as Bug #979564 and they are opening a new bug with priority for my issue.

[Toshi_Esumi]

I thought it was never possible to change used/referenced object names. Because when you simply change it it would cause an error on the referencing side, where now referencing target doesn't exist any more. And if you change the reference first to a new name before changing the object name, it would also end with an error since the new object doesn't exist yet.
It's probably possible only on FMG side where the reference check doesn't happen until you try to install the config to the device.

We always make a new object (new name) copied/cloned from the original object then change the reference to use the new name second. And lastly removing the unused original object. We've been doing the same way even with FMG.

Toshi

[sw2090]

TAC told us to do that via script and they even sent us the script for it. On FMG Gui its not possible.

Now TAC tells us that global objects should not be renamed at all. They also told us the API Bug I mentioned above is fixed in v7.4.1.

The only workaround they gave us yet is to rename all the objects back into their old name or threw work away and go back to the last backup before the renaming.

Looks like TAC moved themselves (and us) into a dead end :\

[sw2090]

Btw the same thing in FMG works fine on non global objects. Those can even be renamed via the gui. 

[sw2090]

We thought about doing the same way Toshi said but due to the huge number of objects that would have cost us too much time so we asked TAC if there is an easier solution and got the script.

[Toshi_Esumi]

It's too late already once it's broken. But next time you might want to consider scripts (three of them) to do the three steps: create new objects copied from the old ones, rename references, remove old objects. This way, you just need to edit/create scripts in a text editor so that you can do even more than a hundred of them relatively easily and safely.

<edit>If I were the TAC person, I would provide the new set of scripts for this then you roll it back and run the script group.</edit>

Toshi

[sw2090]

Well TAC did not provide any scripts to me. They suggested to roll back a backup but before that replace the global adom db with one out of an older backup that still had the original state.

That worked as a rollback to fix it. 

In fact as I now see it after talking to TAC and doing some research - this is neither a bug nor a feature. It is a failure in programming design.

FMG does use a Database backend and it does store the objects in there. However the Fortinet developers did not use its advantages. Instead of creating some unique object id as primary key in the table and then reference the object by that id (just like their uuids the e.g. have in policies) which would have prevented this from happening they used the object name as "target" for the references.

They then provide you a rename command on clli but did not make sure that upon assigning this to an adom the references in the adom are changed.

So this had to lead to failure because FMG did rename the global object and did correctly assign the renamed object to the ADOM(s). However with that it killed the references in the policies because there was no more object with that name now. So the reference was in an unknown state in the policy. It was still there if you click "where used" on the object because that obviously was saved with the object and the object did not change except from its name.

This then had to crash upon deployment. The only good thing was that it already crashed in the dry run FMG does before deploying so it didn't crash anything on my FGT.