We have issues with the amc not recognising the IDPs. Could be related to the rest endpoint being broken.

We are also on redhat 7.9

So it looks like the issue may be the upgrade did not complete correctly.  Due to restrictive security requirements at this site, I had to replace log4j with reload4j in the iManager structure.  I could not leave the old log4j jar there, no matter what.  This seemed to work fine and caused no issue.  So fast forward to now and I did the upgrade as I normally would.  The upgrade looked to me like it completed correctly, but support says it did not because I replaced log4j with reload4j.  Support asked if I could go back to an earlier snapshot, put the vulnerable log4j jar back, and redo the upgrade.  Unfortunately, I do not have a snapshot, so I'm stuck now waiting for an answer as to what to do to fix this (been two weeks now).  Not sure what to do.  This is a dev/test lab, so that is good.  But the upgrade process is so incredibly fragile. It's a big problem. The iManager used is not the latest either.  

I need to go back and check my upgrade logs come to think of it, I jut took their word for it that the upgrade did not complete successfully, but I don't recall seeing any errors.

Matt

Indeed it looks like the upgrade is only done halfway or partly. We have tried lots of things but no joy yet. And also we do not have snapshots.

I did look at my install logs, and sure enough, it's the same problem. It looks like the NIDS plugin faisl to install during the upgrade due to the missing logger (I thought they don't use the vulnerable log4j code? Apparently they do use it).  The iManager framework NPM update I think fails too.  What's odd though is some of the other NPM updates work fine. I can see the PKI and NMAS NPM updates install no problem.  So I'm wondering if I can just update the NIDS_Plugin.npm?  It doesn't show up though in the normal available/installed NPM list in iManager.  It'll be nice when they finally replace iManager with something else!

Matt

HI Matt,

Thanks for al the help you've provided on this issue.

I believe you have been given some steps from our R&D team to address this. If you can get back to us on the support case (once you have got a chance to test), we can follow up from there.

I ended up getting a backup restored of the entire NAM environment before I upgraded it to SP4.  Then I put log4j-1.2.17.jar back and re-ran the upgrade.  This time everything worked.  Then after the upgrade I removed log4j-1.2.17.jar and replaced it with reload4j-1.2.24.jar.  Everything seems to be functioning fine still.

Unfortunately, support never made it clear to me that a work-around to fix my broken NAM 5.0 SP4 was in the works.  They supplied a script to fix the environment after I already went through the process of getting the backups restored.  I wish this would have been communicated to me.  I was given the impression that my only recourse was to return to NAM 5.0 SP3.  

Neverless, it should be made clear that if you did replace log4j-1.2.17.jar with reload4j that you MUST put it back prior to the upgrade as the upgrade will fail with NO NOTIFICATION that it failed.

In highly secure and sensitive environments, log4j-1.2.17.jar cannot be left ANYWHERE on the device.  It doesn't matter if it isn't used and should not be vulnerable, in some cases, there is no choice, it has to be removed.  I even get in trouble having it sit in my home directory as a backup!

Matt