Hey there,
I edited a /bin/bash script that automatically checks the devices uptime and tells the user to restart his computer after 2weeks uptime (with the help of https://www.jamf.com/jamf-nation/discussions/17336/user-has-not-restarted-in-x-number-of-days)
The following part generates the ""jamf" wants access to control "system events"" message for end users:
#!/bin/bash
# Discover logged in user
user=`stat -f%Su /dev/console`
#Execute code as logged in user (instead of root)
sudo -u $user /usr/bin/osascript <<-EOF
tell application "System Events"
activate
set question to display dialog "The device has not been restared for [...]"
with title "RESTART YOUR COMPUTER" buttons {"Shut Down", "Restart", "Cancel"} ¬
cancel button "Cancel" with icon caution
set answer to button returned of question
if answer is equal to "Shut Down" then
tell application "System Events"
shut down
end tell
end if
if answer is equal to "Restart" then
tell application "System Events"
restart
end tell
end if
if answer is equal to "Cancel" then
return
end if
end tell
EOF
exit 0
fiI already read the thread (https://www.jamf.com/jamf-nation/discussions/30388/loginwindow-wants-access-to-control-system-events) but couldn't find the solution there.
The issue seems to be the tell / end tell statement but I can't find a way to change the script.
I tried several PPPCs and gave JAMF access to Accessibility, System Events and everything else that's required.
The script itself works fine.
Can someone help me out here?
I managed to solve this one after days of trial and error.
I ended up using this article to monitor the logs as the process was running to call my apple Script. It pointed to the jamf daemon. https://scriptingosx.com/2020/09/avoiding-applescript-security-and-privacy-requests/
I created a PPPC profile just for the jamf daemon and all worked. Has to be the Jamf Daemon binary and not the app - /Library/Application Support/Jamf/Jamf.app/Contents/MacOS/JamfDaemon.app/Contents/MacOS/JamfDaemon
Creating a monolithic PPPC profile with all the jamf binaries didn't work for me either and I suspect they were causing conflict.
Hope this helps someone.
This one had me pull a few hairs out but it's fixed now.. For anyone still following along, here's what I found..
macOS 12.1 -> user login (or Self Service item) will trigger a policy / script that calls osascript with a Finder tell block. "Jamf want's access to Finder.." began springing up.
Checking the logs below and reading some posts ( https://mjtsai.com/blog/2021/06/01/macos-11-4-breaks-full-disk-access-for-helper-tools/#comment-3465... ), I needed to explicitly whitelist helper executables included in the Jamf.app bundle; com.jamf.management.daemon ( login ), com.jamf.management.service ( self service )
/usr/bin/log show --predicate 'subsystem == "com.apple.TCC"' --info --last 1h
( https://krypted.com/mac-os-x/reviewing-tcc-dialog-prompts-using-logs-on-a-mac/ )
2022-01-17 22:33:43.340568+1030 0x15a6a Info 0x45da1 9216 0 tccd: [com.apple.TCC:access] do_TCCAccessRequestIndirect: indirect object information processed
2022-01-17 22:33:43.340574+1030 0x15a6a Default 0x45da1 9216 0 tccd: [com.apple.TCC:access] target_executable_path_URL: file:///Library/Application%20Support/JAMF/Jamf.app/Contents/MacOS/JamfDaemon.app/Contents/MacOS/JamfDaemon
2022-01-17 22:33:43.340914+1030 0x15a6a Info 0x45da1 9216 0 tccd: [com.apple.TCC:access] Constructed 'accessingProcess' from indirect_object_token in message from <TCCDProcess: identifier=com.apple.finder, pid=9338, auid=2041273090, euid=2041273090, binary_path=/System/Library/CoreServices/Finder.app/Contents/MacOS/Finder>
2022-01-17 22:33:43.340943+1030 0x15a6a Info 0x45da1 9216 0 tccd: [com.apple.TCC:access] AttributionChain: accessing={<TCCDProcess: identifier=com.apple.finder, pid=9338, auid=2041273090, euid=2041273090, binary_path=/System/Library/CoreServices/Finder.app/Contents/MacOS/Finder>}, requesting={<TCCDProcess: identifier=com.apple.finder, pid=9338, auid=2041273090, euid=2041273090, binary_path=/System/Library/CoreServices/Finder.app/Contents/MacOS/Finder>},
But I had already done this, entries for both are whitelisted to send Apple Events to Finder etc. Reading on in the TCC logs I saw these below;
2022-01-17 22:33:43.341540+1030 0x15a6a Info 0x45da1 9216 0 tccd: [com.apple.TCC:access] -[TCCDAccessIdentity initWithIdentifier:type:executableURL:SDKVersion:platformType:]: self.bundle=0x129b055f0, bundle:<TCCDBundle: bundleID=com.jamf.management.Jamf, version=10.35.0-t1640197529, path=/Library/Application Support/JAMF/Jamf.app>; for: com.jamf.management.daemon, URL: file:///Library/Application%20Support/JAMF/Jamf.app/Contents/MacOS/JamfDaemon.app/Contents/MacOS/JamfDaemon, /Library/Application Support/JAMF/Jamf.app/Contents/MacOS/JamfDaemon.app/Contents/MacOS/JamfDaemon
2022-01-17 22:33:43.342193+1030 0x15a6a Default 0x45da1 9216 0 tccd: [com.apple.TCC:access] -[TCCDAccessIdentity staticCode]: static code for: identifier com.jamf.management.daemon, type: 0: 0x129b0b1c0 at /Library/Application Support/JAMF/Jamf.app
2022-01-17 22:33:43.369037+1030 0x15a6a Info 0x45da1 9216 0 tccd: [com.apple.TCC:access] -[TCCDAccessIdentity matchesCodeRequirement:]: SecStaticCodeCheckValidity() static code (0x129b0b1c0) from com.jamf.management.daemon : identifier "com.jamf.management.daemon" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "483DWKW443"; status: -67050
2022-01-17 22:33:43.369054+1030 0x15a6a Info 0x45da1 9216 0 tccd: [com.apple.TCC:access] Override: eval: matched <kTCCServiceAppleEvents, com.jamf.management.daemon>; result: Auth:Unknown (<Unspported Authorization Reason value>); because: code does not meet requirement
It seemed my issue was during validation of the code requirement for JamfDaemon executable. As a test, I even tried relaxing that requirement to ( identifier "com.jamf.management.daemon" and anchor apple generic ) but still no change!! I tried again but this time, using the identifier of the parent bundle eg. Jamf.app
Identifier: com.jamf.management.daemon
Code Requirement : identifier "com.jamf.management.Jamf" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "483DWKW443"
Once deployed, everything began working again as normal with no further prompts for approval on login. I did this again forJamfManagementService ( Self Service ) and it also worked by removing user prompts on execution.
Identifier: com.jamf.management.service
Code Requirement : identifier "com.jamf.management.Jamf" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "483DWKW443"
So for my environment, changing the code requirement identifier on both whitelist entries to match the parent bundle they live in, ( /Library/Application Support/JAMF/Jamf.app : identifier "com.jamf.management.Jamf" ) worked for me.
@Bol My logs showed the app I was telling to open with oascript wanted the access. Creative cloud and its helpers. So now im wondering if i can just remove that portion, but even when my script opens safari it asks for that as well. I used your whole identifier and the same code requirement however it actually ended up prompting for more access.
Include this in a profile, along with all the regular permissions / Apple Events you would normally give Jamf;
From the config profiles being applied, if there are two of the same identifiers declared, I believe it will apply the most restrictive. I had singular profiles for everything originally but then started again, making one larger profile for everything Jamf. I took their example on github and needed to add the daemon / service binaries to it.
@rtrouton Thanks so much for the response!
My older Jamf TCC profile which worked before (maybe)11.4 is shown below but I had a 2nd separate TCC profile for osascript. I have most of the tcc config profiles set separately and again used to work in that regard. Im going to attempt using just your profile and exclude my two from it, but in looking it over I don't see the access to accessibility that I think it may require to input keyboard typing. I'll let you know though.
@GabeShack Sorry I didn't get back to you earlier, timezones and a full on week back to school.
I can take a look at the script, no troubles, but I can already see the problem with your profile. As I mentioned in my original post in this thread, you need to change the code requirement to match the parent jamf.app it's located in, not that of the binary itself.
See your profile picture here;
Change it to look like this, I posted this above accessing osascript;
You need to change this for the daemon (login triggers) and the service (launched from self service)
Identifier: com.jamf.management.daemon
Code Requirement : identifier "com.jamf.management.Jamf" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "483DWKW443"
nagement.service
Code Requirement : identifier "com.jamf.management.Jamf" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "483DWKW443"
Let me know if that works or not.
