Posted on 08-01-2024 05:13 PM
I finally was able to enable the Elevate Privileges option in the Jamf Connect menu and it seems to be working ok. How can I audit who has used it, when, and why?
I saw the documentation about possibly seeing up a SIEM to receive that information, but I'm not sure I know how I would do that. We use Rapid7, and I feel like there's a way but might take a bit of work. Is there any other way to gather that information just so we can see who's using it and why? I tried the log stream command in the documentation just to see what information it showed but it didn't seem to do anything and just sat there at a blinking cursor. I checked Azure's sign-in logs and nothing of note in there either unless I was looking in the wrong place. Security needs me to remove local admin rights from all computers, but we still need to allow our devs to install things for their job and we don't want to be buried under a bunch of requests to remote in and use admin credentials to install simple plug-ins and stuff.
Posted on 08-01-2024 05:24 PM
When you use "log stream" it is live output when you perform the action based on the predicates. You can use "log show --last Xm" (X = a number, m = minutes) to go back in time. log only holds the last 30 days.
You can use "log show" to dump to a file then import into a SIEM or other database...you could even use the API to upload the file to the Jamf record if you wanted
Posted on 08-02-2024 06:12 AM
Using log stream can be a bit of a task, you need to know exactly what to tell terminal you want to see. The blinking cursor just means that whatever event you were looking for was not happening. Apple does not try to make this easy for us.
Streaming Logs:
Thankfully Jamf does provide the terminal commands to see the logs so we dont need to figure them out.
Auditing Privilege Elevation with Logs - Jamf Connect Documentation 2.37.0 | Jamf
These commands will stream macOS logs, meaning if the command is running then terminal will report when Jamf Connect promotes and demotes admins.
log stream --style compact --predicate '(subsystem == "com.jamf.connect.daemon") && (category == "PrivilegeElevation")'
log stream --style compact --predicate '(subsystem == "com.jamf.connect") && (category == "PrivilegeElevation")'
Showing historical logs:
You can rework the commands that Jamf gave you from log stream to log show, and trim down to a window of time to see what happened in say the last 30 minutes (time value can be changed).
log show --style compact --predicate '(subsystem == "com.jamf.connect.daemon") && (category == "PrivilegeElevation")' --last 30m
log show --style compact --predicate '(subsystem == "com.jamf.connect") && (category == "PrivilegeElevation")' --last 30m
Redirecting logs:
MacOS does not natively support remote log viewing, or event log redirection. You can use the commands above with SSH to view them in terminal without extra tools. To redirect macOS event logs, you will need a client on the device that can do this, and unfortunately there are not very many that can. Jamf Protect and Splunk Universal Forwarder (not officially released last I checked) can redirect logs to SIEM. Jamf Pro CANNOT redirect macOS event logs to SIEM nor can you view macOS event logs in Jamf Pro, SIEM redirection is a separate premium service.
You can take the commands above and turn them in to log filter predicates for tools like Jamf Protect, which will redirect events to SIEM. From there you can do all the things you usually do with a SIEM and the events being forwarded.
Unified Logging - Jamf Protect Documentation | Jamf
"subsystem == "com.jamf.connect.daemon" && category == "PrivilegeElevation" && (eventMessage CONTAINS "Added user" OR eventMessage CONTAINS "Removed user")"
Continued Conversation:
Rapid7 cannot read macOS event logs. It is more or less checking system files looking for things it does not like, it is not streaming OS event logs.
If security is really wanting Admin access removed, this is a project your Identity Management Team needs to be spearheading. Unfortunately, Jamf Cannect's temp admin access function is still granting admin access, users are still admins and can still do whatever they want with the access; just for a window of time that the user controls as they can re-escalate themselves.
My suggestion. Your Security team needs to look into an Endpoint Permision Management tool and basically stop putting half measures in to securing macOS. Even if you got your SIEM log redirection setup, and all the logging working, if your security team does not know what the logs mean they cannot make any playbooks on the information. Off the top of my head both CyberArk and BeyondTrust make EPM tools. Basically, your security team makes policies to auto escalate the specific workflows your developers need, and your developers themselves never actually get admin access.
Endpoint Privilege Management for Windows and Mac |… | BeyondTrust
Endpoint Privilege Management - Endpoint Protection | CyberArk
Posted on 08-09-2024 08:09 PM
side bar: How were you able to get the elevated permissions working? We use Okta as an IDP and i am running into a few issues