API to export policy logs

Benjy
New Contributor

Hello experts. 

I'm new to jamf and this community so apologies if this has been answered already as I haven't been able to find a recent solution response. 

I have a policy that enables users to run a script and management wants to know who has run it via self-service.  So far, I've been able to get this computer-by-computer, but is there a better way?   My solution uses: Finds a subset of computer history data by ID (jamf.com) with the subset set to PolicyLogs.  With thousands of computers scoped for the policy, that's a large number of API calls to make.   Ideally I would use Finds a subset of data for a policy (jamf.com); however, there is no subset for PolicyLogs.  

 

Any advice or solutions you can offer? 

2 ACCEPTED SOLUTIONS

jamf-42
Valued Contributor II

if I understand correctly your requirements.. 

 

if you add a script to the policy, that collects the logged in user and writes it out to a file with a tag for the policy

you can the code an extension attribute to read that, then have a smart group scope to that EA

that smart group will then list who has run the self service policy

you could even include the date and time. .

View solution in original post

AJPinto
Honored Contributor III
  1. If you have sys log redirection in place, you can have your SIEM tool look for the policy event in the JAMF or Install logs. This would probably be the best option for an environment that absolutely must know a thing happened. 
  2. Have an Extension attribute look for whatever your script is doing. If your script creates a directory, updates a plist or whatever, have your EA look for those changes as validation the thing was done.
    1. If the script does nothing you can read with an EA, add something that can be read. Such as manually dropping a .log file somewhere, and having an EA look for that log file. If the file exists the script was run. However I would make sure the log file is written with an if statement that only happens if the thing you are doing was done successfully. 

 

 

View solution in original post

5 REPLIES 5

jamf-42
Valued Contributor II

if I understand correctly your requirements.. 

 

if you add a script to the policy, that collects the logged in user and writes it out to a file with a tag for the policy

you can the code an extension attribute to read that, then have a smart group scope to that EA

that smart group will then list who has run the self service policy

you could even include the date and time. .

Benjy
New Contributor

Thanks for the quick reply.   I feel you did understand based on the information i provided, so perhaps i should have shared more.  The script in question is the make me admin.   The goal is to report who has run it, when and how many times, so follow-ups can be done to prevent abuse.   We could do as you suggested, and since this could be run multiple times, we'd have to extend the script to maintain its contents (ie keep a log).  I assume the same EA approach could contain the whole file contents? 

 

Seeing as the GUI already displays the information we're looking for (without any apparent way to export), we were hoping there could be a more direct approach.   We've managed to get it from the computer history but this will require thousands of api calls.  Was hoping there is a way to get it all from the policy itself.  

jamf-42
Valued Contributor II

this maybe another idea https://github.com/SAP/macOS-enterprise-privileges

yup. there is some engineering to get it working. but its well used and could provide the magic 😎

AJPinto
Honored Contributor III
  1. If you have sys log redirection in place, you can have your SIEM tool look for the policy event in the JAMF or Install logs. This would probably be the best option for an environment that absolutely must know a thing happened. 
  2. Have an Extension attribute look for whatever your script is doing. If your script creates a directory, updates a plist or whatever, have your EA look for those changes as validation the thing was done.
    1. If the script does nothing you can read with an EA, add something that can be read. Such as manually dropping a .log file somewhere, and having an EA look for that log file. If the file exists the script was run. However I would make sure the log file is written with an if statement that only happens if the thing you are doing was done successfully. 

 

 

Benjy
New Contributor

@AJPinto / @jamf-42  - Thank you both for the replies and direction.  As I'm new to jamf, the idea of using EAs not intuitive nor one that I would recommend.  I will pass along this information to our jamf support team to get their thoughts. 

 

In the end, while EA may be the best approach, it would be nice if the existing API supported the export of data already there.  In my googling, i've found it it was self hosted, we could 'backdoor' the database and pull the information but with SaaS, database access isnt possible.  Would be nice to submit this as a feature request if possible.