Actually we have a centralized portal where we show all the patching related data, which completely runs serverless …so I want this Bigfix WebUI to be accessed by that portal …as far as I see WebUI is looking like software which needs to be installed. Please let me know is there any way that Bigfix WebUI can be made publicly accessible?
Thanks in Advance
I don’t know exactly what you mean? It may be worth contracting with Professional Services to help you build your reporting integration, but I think that would likely pull data from the Root server, Web Reports, or Insights, I don’t see a need to include WebUI for a third-party patch reporting.
Like @JasonWalker said.
Most of the Information you request can be obtained through Rest API (Root Server), SOAP API (Web Reports) or Insights (SQL Query)
If you are looking for WebUI Patch Policy schedules and such they can be obtained from the DB itself - reference - Patch Policy Reporting
Please vote for Patch Policy API Idea - https://bigfix-ideas.hcltechsw.com/ideas/BFP-I-108
Thanks @JasonWalker and @orbiton for the very quick response.
I see that REST APIs available in …is very limited , we want to extract as much as data possible from bigfix console and put it in our centralised portal.
I did not get this point " SOAP API (Web Reports) or Insights (SQL Query)", how to extract the data from webreports and using Bigfix Query??.. can you please elaborate a little please ,.or if you have any clear document please share it here with me.
Regards,
Madhumita
The REST API should be capable of returning just about anything you need, I’d be curious as to what is missing?
When using the API though you may need to just retrieve the data, and much of the correlation between Fixlets, computers, etc. would then need to be done at your application level (this is how the Console, Web Reports, and WebUI do much of it).
hi @JasonWalker
We want to include following usecases into our portal, for the below i did not find required APIs:
i) Post method to rollback the action.
ii) API to get the list of VMs on which agents are not installed.
iii) API to get the actions taken based on time parameter like one day back, 2 days back
iv) APIs to list down the critical patches/fixlets available for our VMs.
etc …
If you think that above usecases can be acheived by the existing Bigfix APIs, please let me know.
Regards,
Madhumita
I think the main pattern here is that the APIs can retrieve the raw data, but correlating & filtering needs to happen in the higher-level application layer
I just looked up some of the references (I don’t have a system with correlations handy to test at the moment) but looping through /api/computer/id should return what’s needed for item 2 - finding machines with a VMWare agent but no Native Agent
https://developer.bigfix.com/rest-api/api/computer.html
for GET /api/computer/id :
Request: URL is all that is required. You can use a computer id or a correlation id as {computer id}. You can reduce the amount of information returned in the response using the ?fields= parameter (use --fields in the IEM cli), as described in Filtering Response Fields.
Response:
If it is a computer, it lists all of the computer’s properties.
If it is a correlation, it lists all of the master representation’s properties and all of the other representations’ properties in different ManagementExtension nodes.
The reported properties belong to the master representation. A new xml node called ManagementExtension is present for each correlated device, the Type attribute of which is set to the AgentType of that specific device. All the properties defined for the device are reported within this node.
Response Schema: BESAPI.xsd
Digging in to it a bit further, what I think is the pattern is that
/api/computers returns a list of computers that are either a correlated or uncorrelated computer; if a computer is correlated, only one instance appears in this list and the individual nodes (Native Agent, MDM Proxy, Cloud Proxy, etc.) are not presented.
After retrieving /api/computers, loop through each Resource to get the details of that computer. Each Resource will point to
/api/computer/{id}
When retrieving the computer details, a Correlated computer will by default include all of the Global Properties for the Native instance of this computer, and optionally ManagementExtension nodes if this is a correlated computer. ManagementExtension will include the extension type as well as properties retrieved by that specific extension. A non-Correlated computer will not include any ManagementExtension nodes.
<Computer Resource="https://bfwinroot.exampledomain.local:52311/api/computer/3773142797">
<Property Name="Computer Name">GWIN11</Property>
<Property Name="OS">Win11 10.0.22000.2295 (21H2)</Property>
<Property Name="CPU">2700 MHz Core i7-6820HQ</Property>
<Property Name="Agent Type">Native</Property>
<Property Name="Last Report Time">Tue, 05 Sep 2023 20:10:27 +0000</Property>
<Property Name="Locked">No</Property>
<Property Name="BES Relay Selection Method">Automatic</Property>
<Property Name="Relay">bfbionics4.exampledomain.local:52311</Property>
...
<Property Name="ID">551093853</Property>
...
<ManagementExtension Type="Proxy - MDM - Windows">
<Property Name="Computer Name">GWIN11</Property>
<Property Name="OS">Win10 10.0.22000.2295</Property>
<Property Name="Agent Type">Proxy - MDM - Windows</Property>
<Property Name="Last Report Time">Tue, 05 Sep 2023 16:10:10 +0000</Property>
<Property Name="Locked">No</Property>
<Property Name="BES Relay Selection Method">Automatic</Property>
<Property Name="Relay">bfrh81a.exampledomain.local:52311</Property>
<Property Name="ID">548813572</Property>
</ManagementExtension>
</Computer>
Some interesting things to note is at the top-level properties, the ‘ID’ property refers to the ID ‘551093853’ of the Native Agent, which does not match the URL we used to pull the Correlated computer ID ‘3773142797’. In the ManagementExtension node we can see the ‘Proxy - MDM - Windows’ ManagementExtension refers to the correlated MCM manager for this computer, which has it’s own ID ‘548813572’.
In this instance only ‘3773142797’ appears in the list at /api/computers.
I think what we can say about this is
We retrieve /api/computers, and loop through the results; for each computer found retrieve /api/computer/id, and
If Agent Type is Native and it has no ManagementExtension node, it’s a native computer with no correlations.
If Agent Type is Native and it has ManagementExtension node(s), it’s a correlated computer with a Native agent and one or more correlations
If Agent Type (of the top-level Computer node) is one of the Plugins, it’s one of the extensions that is missing a native agent and/or failed to correlate to a native agent somewhere
hi @JasonWalker
Thanks for help …what I see is only on the VMs where Bigfix Client got istalled …those are only getting listed under this /api/computers. And what are these correlated and uncorrelated VMs? I’m not able to get it …do you have any documentation regarding this ???
And also other query is regarding finding out the critical patches… as you told above …to look out for CVE names
"Each result has a Resource attribute to retrieve that Fixlet, one would loop through each Resource to retrieve the Fixlet and examine the CVENames node from the Fixlet to filter them."
but for some of the fixlets i dont see any CVE names or severity for example this fixlet does not have any CVE name:
api/fixlet/external/BES%20Support/2306
In that case how we can find the criticality of the patch???
waiting for your reply
Now I’m confused by what you’re asking.
Correlation refers to cases where the same device/instance can be represented in multiple ways - a VMWare Extender shows the view of the virtual machine seen from the VMWare host, the AWS or Azure extenders see the cloud host via Azure or AWS API, the MDM provider shows the Managed Device, and the native BigFix Client in the operating system provides the “Native Agent” view.
Correlation refers to BigFix determining that several of these views refer to the same machine, and they are “correlated” into a single representation in the Console or WebUI. Correlated machines will appear in the list with both a “Cloud” and “Native” and “MDM” icon of all three are installed.
What I thought you were asking originally was how to detect via API that a given machine was detected by the Cloud or VMWare Extender, but the VM did not have the Native Agent installed in the OS. That would be detected by the VMWare plugin displaying a computer that has no matching (correlated) Native Agent.
As for CVEs, it’s not required that a Fixlet have a CVE. In fact most Fixlets don’t resolve CVEs. If you only want to retrieve the Fixlets that have CVEs associated you could filter that in your query, or ignore the results that have empty CVE values.
As for documentation, yes we have it. A lot of it. A good place to start is at https://support.hcltechsw.com/scm?id=bigfix_support especially the “Getting Started” section of the Product Documentation, and the Training sessions area (I think most of our training is still instructor-led remote and free)