Welcome back to “Getting the most out of Action1 with PSAction1.” In the first and second parts, we learned how to get data out of Action1 via PSAction1 and how to create, modify, and delete objects as well. Those are fine foundations for taking this to the next level, broad actions that bring substantial amounts of utility in small, easy-to-support scripts.
By now you should understand the basics of how the PSAction1 module can aid in bulk ID and change operations in Action1, but what else can it do? Let’s say there is not much need for large bulk operations in your environment, so what other cool things can I do with Action1 and PSAction1? Let’s explore the following practical example.
How to Synchronize Action1 Endpoints with Active Directory Using PSAction1?
One often encountered example is in networks with high system turnover. It is not uncommon to accumulate agents in Action1 that no longer exist in your AD. So how can you take data from two separate systems to achieve a unified result? With PSAction1, of course!
Since we are no longer working command by command, we will format this a little differently. These are full scripts designed to be run as a unit, not single statements. While in some cases line by line will work, they are still designed as a chunk of code that works together.
So, what we know is that we can get a list of computers from AD, and we can get a list of endpoints from Action1, compare them, and then remove the endpoints that no longer exist in your Active Directory. Wondering how this is going to happen? Don’t worry, we are here to help with that!
Let’s walk you through the straightforward process of synchronizing these environments using PSAction1.
Step 1. Launch PSAction1:
Open an elevated PowerShell session with the PSAction1 module loaded. Ensure you have domain admin privileges or equivalent access rights to query Active Directory objects and manage Action1 endpoints.
Step 2. Execute the Synchronization Script:
Now, compare the lists; anything that is not included in AD is also not included in Action 1. This is a straightforward process! Keep in mind that the “-Force” parameter bypasses confirmation prompts. Make certain you know what you are doing or remove this option to have a last chance ability to halt before making changes. Result? In four functional lines of code, you just created a system integration!
Certainly by now you are starting to get the feeling of, Wow, I can do a lot very easily with the API and PSAction1. And that is why I wanted to write this series, to show that even with the most modest PowerShell skills and the most basic understanding of Action1, you can create advanced solutions fast and easily.
How to Build a Vulnerability Management Bridge: Converting External Scanner Vulnerability Data into Action1 Remediations
Let’s take that a step further and make it a bit more complex of a task. Let’s consider that perhaps you have another vulnerability scanner, RMM, or other system reporting that a collection of systems on your network is susceptible to a collection of patchable vulnerabilities.
And you would like Aciton1 to patch according to that other system’s stated vulnerability analysis. If the system can generate that list in pretty much any standard structured format, CSV, JSON, XML, delimited text… Then that bridge is actually a pretty simple build using PowerShell and PSAction1.
Now, let’s see how exactly to complete the task through this step-by-step guide:
Step 1. Launch PSAction1:
Open an elevated PowerShell session with the PSAction1 module loaded. Ensure you have domain admin privileges or equivalent access rights.
Step 2. Prepare Vulnerability Data Format:
What we need to do is structure the list’s format to one that we can translate into PSAction1. Your input options here are infinite and therefore largely arbitrary; the source system’s type is irrelevant, as long as it can make a list that says this system needs this patch, the rest can be messaged into place.
Step 3. Copy and paste the entire script below into your PSAction1 console:
The entire integration process consists of approximately 20 lines of code, including comments and formatting!
So simple, in fact, I could have titled this installment of the series “Systems integrations before your coffee gets cold.”
What we did here is process the list, and every time an endpoint name was repeated, we added the patch name to a list of comma-separated values of patches applicable to that endpoint.
Before | After | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
And with that, you have created not only a simple-to-use but also reusable systems integration between the vulnerability management system that essentially knows nothing of one another. And if tomorrow the source of this data changed formats or even sources, you would be able to adapt easily to get right back to where you were last time.
For more examples of more advanced use cases, head over to our GitHub repo, https://github.com/Action1Corp/APIScripts. There you will find other examples of use cases from real customers that leverage PSAction1 to get the job done. You will find more useful examples that can be used or adapted to your needs and certainly learned from.
What Comes Next?
In part four of our series “Getting the Most Out of Action1 with PSAction1,” we will dive into data extraction so examples like the systems integrations we just performed can make the return trip for bidirectional integration. As well as getting data for more advanced reporting needs—and maybe just a little fun with PowerShell and data!