SailPoint® is excited to announce that setting up new virtual appliances is now easier and more secure than ever before!
To make setting up your Virtual Appliance (VA) even more secure and user-friendly, we’re excited to introduce a new “pairing code” process. This process uses a simple, generated code for setup, eliminating the need to handle sensitive credentials directly. The pairing code ensures a smoother, more secure experience, reducing the complexity of the setup process and enhancing overall security.
Who is affected?
Customers, partners, and/or PS who are establishing new VA’s.
Clusters will see this new setup process as well.
Existing clusters and VAs continue to operate as usual - adding a new VA to an existing cluster will require this new process.
Action Required
If you have previously downloaded VA packages (stored somewhere locally, or an AWS image ID or equivalent), delete them and use the latest package from SailPoint documentation site - VA Deployment Packages
Is there any plans for Terra form support? With this process how does it change for the legacy virtual appliances that were setup with a specific passkey phrase i.e. I want to add more virtual appliances to the cluster. Will I have to setup a brand new cluster? Does this still mean that the virtual appliance is still treated as a disposable appliance? i.e. I forgot my login password and/or passkey phrase?
I would also like to call out that this probably requires two new endpoints to be allowed by all customers at the network/firewall to make this work properly. I do see it was updated here: System and Network Requirements - SailPoint Identity Services
What happens after the 4 hour mark if the virtual appliances does not pair with the tenant? Do you have to re-deploy the virtual appliance? Is there a CLI that we can run to check the status of the virtual appliance to assist with troubleshooting? Assuming we’re just looking at charon/va_agent logs here?
-Tom
@ashleygeorge : I tried similar steps whatever you tried to show but my UI says invalid code/Expired, I also tried to check logs it says
{"@timestamp":"2024-09-18T07:37:10.944","level":"ERROR","type":"agent","message":"Config file not in place."}
{"@timestamp":"2024-09-18T07:37:40.974","level":"ERROR","type":"agent","message":"Config file not in place."}
I am not sure which config file it is referring.
Please note that this is Identitynow demo(Partner Tenant) in which I am trying to configure new VA for my bootcamp practical sessions, I need your help to fix this up
Hi, questions/remarks from my side on this update:
The rollout is said to be the week of September 16th, yet this announcement was made in the evening of September 17th. I think it would be better to have these types of announcements in advance such that we can plan ahead on this. The announcement mentions “To make setting up your Virtual Appliance (VA) even more secure and user-friendly…”. I think that having a timely announcement will add to the user friendliness.
There used to be a technical white paper describing how SailPoint handles the credentials to applications, using encryption in the virtual appliance. The link used to be: https://community.sailpoint.com/t5/Lighthouse/Technical-White-Paper-Delivering-Innovative-Security-in-the/ta-p/76576. I see it is not here anymore, can you please share me the latest location of this document and tell me if this is updated to the changes mentioned above (and also up to date for applications using a SaaS connector, which does not depend on a passphrase from our side)? I think to have these white-papers available and up to date adds to the VA’s being more secure, as they can be attested by the end users like before.
Since the steps to take to onboard a new virtual appliance has changed, the SailPoint Certification exam questions (Professional and Engineer) are incorrect as they refer to the old way. Will this exam be updated at the same time and/or will those that have planned the exam be informed in time such that they know how to answer the questions?
The video mentions that the tenant type (dev or prod) needs to be given to the VA. Is this new? Why do we need to tell the VA what type of tenant it communicates with? Why should the VA behave differently depending on type? And if needed, why doesn’t the VA retrieves this data itself? It can communicate with ISC, so ISC can tell the VA what type it is. This looks like an unnecessary step to be performed by the customer to me.
The announcement mentions that this new process will be “…eliminating the need to handle sensitive credentials directly”. However in the video I see that there is still a passphrase that we need to create and user on each VA. In what way does this paring code eliminate this need to handle sensitive credentials directly?
Hi @angelo_mekenkamp I can speak to #4: In light of these changes, we are already, currently looking at exam questions related to VA setup and configuration and will be making changes to exams - where needed - to reflect the new process. This is on our radar and being actively worked.
Also, @pawank7, I’ve been researching some of the errors I’ve seen posted in both SailPoint communities (i.e. 403/command not found setting the key passphrase).
I discovered that when the va-bootstrap command is not present, the recommended solution is to either have the AMI reshared OR download a new image. Someone else reported that changing the DNS Server Inside static.network solved the issue. I was also informed that if the new key pairing process returns a 403 error, please open a support ticket.
I will reply to @pawank7 's post if I learn of anything further that can help resolve key pairing issues.
Hi Tom, existing clusters that were setup with the old method can have VA’s added using this new process, i.e. you don’t need a new cluster.
Regarding the need to redeploy or provision new virtual appliances, there is now a “reset” command as part of the new bootstrap command, it’s not fully documented yet but it essentially allows admins to reset existing VA’s and revert back to ‘factory settings’ without have to stand up new VMs and infrastructure.
Hi Angelo, for #6, you’re right in that users still need to define their passphrases. The part that we wanted to eliminate was the handling of the config.yaml file that was previously available to download from the user interface and possibly persisting on user computers.
For #5, good catch, the video will be updated, this step is not generally needed as most customers don’t have a dev type tenant, it was primarily for our own SailPoint devs to hit a different set of APIs.
Hi Bryant. When the reset switch doesn´t help, what do we do then? The VA is running version 3975.2.1. We can successfully generate the passphrase and insert the hashed value to ISC. The VA just complains about missing configuration file and no pairing happens.
We ended up redeploying the VA. Funny thing is that the OS version is the same as the one we have on VAs not working. Only difference is that the ones not working the VA upgraded it self to the new image version, but no go. A redeploy worked like a charm.
Hi All…
We have deployed in aws environment. Initially the VA’s has paired correctly and the status was connected. After a couple of hours the VA’s changed to “Inactive State”
After 24h the status was the same, we have reeboted the Cluster several times but the status is the same.
Do you know if it’s necessary any other action ?
SailPoint® is excited to announce that setting up new virtual appliances is now easier and more secure than ever before!