Vulnerability Solution Management - Microsoft Solution Integration Failing OOTB

[Matt Moerloos1]

I am currently in the process of deploying VR for two separate clients. We have deployed the Vulnerability Solution Management Application as per our normal practice as both clients are entitled to the application.

The issue here is that the "Microsoft Security Response Center Solution Integration" is failing to successfully complete integration runs on a schedule OOTB. The "Red Hat Solution Integration" is running successfully without issue. The odd thing is that if I manually execute the "Microsoft Security Response Center Solution Integration" by selecting the "execute now" button while viewing the integration record, the integration will complete successfully. I am seeing this occur on both client instances, and have also been able to reproduce this issue in my own DEV instance.

I have validated that there are no issues with the VR.System account.

I have opened a HI case on this issue and up to this point HI Support is stating that the issue is on Microsoft's side as there is no response received from the endpoint during the integration run, and thus me (or my clients) would have to contact Microsoft for Support. Even though I explained the integration runs successfully when manually executed, HI Support has maintained their position that this issue is beyond the scope of support. 

HI Support's response is troubling to me as this integration is shipped with the Vulnerability Response Solution Management Application, and it is failing to run OOTB on a schedule. If there is an issue on the Microsoft side, I feel as if ServiceNow should be raising this issue to Microsoft, and not the client. 

While I will continue to pursue this issue with HI Support, I am wondering if anyone else in the community has encountered the same issue, if you were able to resolve it, and how you went about resolving it.

Thank you!

[Aaron Molenaar]

While I have not experienced this specific issue (we are not using Solution Management) I have gotten the same response from HI support (presuming level 1 type support) on issues with our Rapid7 integration - that it is "an issue with Rapid7 because the data is not there in the API responses and therefore you need to take it up with Rapid7" or similar.

I have found that continuing to push your logic (which sounds solid) and asking for VR development or engineering specifically to review will usually lead to better and more in-depth, knowledgeable response. In my case, getting to this level of support ultimately resolved the issues from the ServiceNow side.

Hopefully if you are able to escalate (if you haven't already) you can perhaps get better answers.

Best,

Aaron

[Matt Moerloos1]

Update for anyone following.

I changed the Run As user for the scheduled job that executes the Microsoft Security Response Center Solution Integration to a test user account with instance admin permissions. The job ran on a scheduled successfully. I then changed the job back to the OOTB VR.System user and the job failed to run on a schedule.

The above shows that this is a permissions issue within the ServiceNow instance. HI Support is continuing to investigate why there is a permissions issue and I am currently waiting on a response.

To Note: The VR.System user & assigned roles are in an OOTB state from when VR was installed late October 2023.

[Theresa Messeng]

I am experiencing this exact issue.  I have changed the run-as account in my test instance to my account, to see if it would run as scheduled, and it did.  I will be curious how ServiceNow responds. 

Side Note:  I have seen permission inconsistencies related to other components of Vulnerability Response as well.

[Nitesh Tolani]

The Run as user should not be changed from the VR System for the different Vulnerability Integrations. Changing this can lead to several issues including the ones mentioned above.