Overview
Tanium is an endpoint management and security platform. An agent runs on every managed machine and the agents form a peer chain, so a question asked at the console propagates across the estate and answers come back in seconds rather than through a central server polling each device in turn. That architecture is what makes Tanium useful as a source of truth about endpoints: it reports what is on the machine now, not what a scan recorded some time last month. The Asset module builds on that live data to keep a normalised inventory of hardware, installed software, network identity and last-seen times, and publishes it over a REST API.
The ReadyWorks connector calls that REST API through the json_rest_api.php driver. Authentication is different from the password-based connectors: no authentication recipe is stored, and the credential travels as a custom header on the request itself. The connection form ships with one header pre-populated, named session, and you paste a Tanium token into its value. You also supply the API domain of the Tanium server and a server-side working path used while responses are parsed.
Tanium is normally the strongest device feed an organisation has, which makes it the natural spine of the ReadyWorks estate rather than one more source among many. Reconciling it against Active Directory, the CMDB and the endpoint-management tools exposes the machines each of those has wrong: devices present in the directory that no agent has seen for months, devices reporting to Tanium that no asset record covers, and hardware specifications that decide whether a machine can take the next operating system. Last-seen times and hardware attributes together drive readiness scoring and wave assignment for device refresh and platform migration programmes.
The connector is registered as bidirectional. Two inbound templates ship, one of them a real Asset pull and the other a blank REST shell, and both are disabled until you enable them. The outbound side posts a record from ReadyWorks to an endpoint you nominate and captures status, message and record key from the reply, and it ships untargeted.
NOTE: The “Get Devices” template calls a path under the Asset module plugin. Deployments that have Tanium without the Asset module licensed and installed will get an error from this endpoint rather than data.
Connector Properties
Authentication Methods
Tanium offers a single authentication method, and it is the default for new connections. It sends a token in a custom header instead of negotiating a credential.
Method 1: Tanium (TANIUM_custom)
Connect to a GET method API with custom header fields
Sends whatever headers you define in the Custom Header Fields list on every request. The list is pre-populated with one entry named session, which is the header Tanium’s API expects the token in, and its value is stored encrypted. Paste a Tanium API token generated for a service account with read access to the Asset data you intend to collect.
Connection Configuration Fields (4)
No authentication recipe is stored. The driver script authenticates natively using the fields above.
NOTE: ReadyWorks stores the header value exactly as entered and never refreshes it. If you use a token that expires, collection stops silently on the expiry date and the token has to be regenerated in Tanium and re-entered here.
NOTE: No authentication recipe is stored against this method, so there is no separate authentication call for a Single Authentication setting to suppress. This is why the connection form does not offer that field.
Inbound Job Fields Enabled (44)
Inbound jobs expose the full REST field set, including three levels of enumeration and all five pagination modes.
NOTE: Several labels and tooltips in this form carry defects inherited from the shared ETL5 field templates: the Enumeration 1 Node label reads “Enumaration”, the Append New Data label reads “Exisiting”, and the help text on Enumeration 1 Keys End Point and Enumeration 3 Fields both refer to enumeration 2. The underlying fields behave as their labels say.
Outbound Job Fields Enabled (13)
Outbound jobs expose the REST posting field set, including the outbound field list, the return data mapping and an optional raw JSON body template.
Inbound Job Templates (2)
Two inbound templates ship: one real Asset collection and one blank REST shell. Both are disabled by default, so enabling “Get Devices” is the first thing to do after testing the connection.
Job Template Configuration
Settings Common to All Two Templates
Settings That Vary by Template
Settings That Vary by Template (continued)
Job Parameters and Enumeration
Get Devices
API data parameters:
NOTE: “Get Devices” is the only template in this connector with pagination fully configured. It uses cursor paging on meta.nextAssetId with an explicit termination condition, which is the pattern to copy if you build further Asset jobs.
Outbound Job Templates (1)
One outbound template ships, and it is the generic REST skeleton.
Job Template Configuration
Settings
Job Parameters and Enumeration
Rest POST API
Outbound fields list:
Return data fields: