+1We have an issue with some techs abusing their device admin accounts and installing software without security review. We have techs making employees an admin on devices just to avoid getting tickets.
I have an extension attribute that shows me admins on the device, but I can't see who did it.
Is there a system log that will show me exactly what account made changes? Jamf doesn't give granular info like that. Can it been done through an extension attribute?
+26Unfortunately not really. Its not that JAMF does not give granular information like this, its that macOS does not record granular information like this in any readable manner.
There will be a log dropped for the permissions check when escalating to make another account an admin. Unfortunately that log does not provide any information as to what the escalation check was for.
Validating credential Test_Account (504) for system.preferences (engine 7321)
credential 504 is member of group admin (does satisfy rule) (engine 7321)
There should be a subsequent log that will show the escalation check was successful. This log does not tell you who attempted the escalation.
Succeeded authorizing right 'system.preferences' by client '/System/Library/PrivateFrameworks/SystemAdministration.framework/XPCServices/writeconfig.xpc' [21690] for authorization created by '/System/Library/ExtensionKit/Extensions/UsersGroups.appex' [21651] (2,0) (engine 7321)
To string the logs above you should be able to use the "engine ####" to link the related logs together.
You should then see some logs about APFS being updated with Admin access changes. However, in typical macOS fashion, it does not tell you what account was promoted to Admin or what account authorized the promotion.
Updating APFS Preboot Volume with Open Directory data implied by Crypto Users on root APFS Volume: UpdatePreboot: Creation of OD query for "admin" group members gave no error and returned resultsUpdating APFS Preboot Volume with Open Directory data implied by Crypto Users on root APFS Volume: UpdatePreboot: OD query action for "admin" group members gave no error and returned resultsUpdating APFS Preboot Volume with Open Directory data implied by Crypto Users on root APFS Volume: UpdatePreboot: Successfully wrote Admin User Info File
I would not attempt to gather this information with JAMF. MacOS event logging is a beast not not something JAMF is designed to stream or gather beyond what JAMF bakes in themselves. If you need this kind of information I recommend looking in to a SIEM tool.
If you have techs going rogue you probably want to look in to another method to control Admin Access. Maybe dont give techs blanket Admin access, and make them open JAMF SelfService to temporarily promote themselves to admin with a policy, and demote them automatically later. The policy will log who ran it and when in JAMF. The same kind of work flow could be used for users to temporarily promote themselves to Admins. You could also add a function to dump logs to a file during the time window while Admin access was provisioned and grab that with JAMF. The best option would be a Privilege Management tool, but that may not be in the budget.
+15This may sound like a sales pitch, but this is exactly what Jamf Protect excels at with its custom analytics and telemetry collection if you need to know this.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.