How can I find out the update history of the VAs?

Identity Security Cloud (ISC) ISC Discussion and Questions
1

I have several connectors that stopped working in the Sandbox environment starting on the 9th, and I noticed there was an update to the VA.

In PRD the connectors work and the VA is on an older version.

How do I access the VA update history/changelogs? I believe it’s related, but I haven’t found that information.

2

This might help?

3

Hi @raibom

We almost have the same issue i.e sandbox VA is inactive/unresponsive since 7th Jan and all aggregations keep failing since then. The VA is stuck in ‘VA upgrade in progress’ state. I had to reboot the CCG service and the VA/cluster a few times but still no luck.

I raised a case with support team and they are looking into it.

As per their advice, I had to check to make sure SSL inspection is disabled for all outbound traffic on the sandbox VA and also the required primary & region-specific AWS URLs are whitelisted, but still without any luck.

I would recommend, raise a support case, if possible run the STUNT script diagnosis on the VA and send them the logs to have a look.

I hope this helps.

4

On that note (currently at 2.3.8):

5

OR

You can download the STUNT script from this article. It should be at the end of the article. stunt_22.zip file.

https://community.sailpoint.com/t5/IdentityNow-Connectors/Virtual-Appliance-Troubleshooting-Guide/ta-p/78735?_gl=1*mcs1u*_gcl_aw*R0NMLjE3NTM3MDQwMTkuRUFJYUlRb2JDaE1JNUpHUng4RGZqZ01WYzZ0bUFoMHFXU0hxRUFBWUFTQUFFZ0tpSV9EX0J3RQ..*_gcl_au*MjAxMTEyMzUxOS4xNzU5NzQyNDcy*_ga*MTE4OTM2OTQyOS4xNzQ0MTA3MTgx*_ga_CDHGD2GT5X*czE3NTk3NDkyODUkbzUxMSRnMCR0MTc1OTc0OTI5MiRqNTMkbDAkaDA.

You can extract and upload the stunt_22.sh on your VA and run the below commands:

chmod +x ./stunt_22.sh (to make the stunt script executable)

./stunt_22.sh -L (to generate a zip file of the logs)

This should generate a zip file under /home/sailpoint/ directory and you can share the zip file with the support team for investigation.

6

I also have an open case.

All sources that communicate using TLS 1.0 have stopped working.

7

Move them to 1.3 if they support it. (There’s been like a 3-5 years of TLS 1.0 depreciation period)

8

It is a legacy system that does not accept TLS connections above version 1.0.

9

Depending on the size of the legacy system(s) footprint within the enterprise, you may want to look into having a TLS version translation layer (e.g. to terminate TLS 1.3 on a load balancer or proxy [ NGINX or HAProxy for example], and re-encrypt with TLS 1.0 to reach the legacy system).

1 Like