Skip to main content

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

fi


I 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?



Hey @marck,



I did not select 'Don't Allow' on my testing machines. They are installed freshly and there are no permissions set yet.
The Window appears even with all those profiles.

Try changing your osascript by getting rid of the Tell Application bit.



So it should read something like...



osascript -e 'display dialog "Blah Blah...."

Did your guys Jamf Pro instance update to 10.12.0 this week? Did that fix the issue @leonwun ?

@kdean we got updated to 10.12, the issue still exists.



@timdambrosio I don't really understand how to change it to remove the "Tell Application", can you explain further please?

@leonwun He means to remove "Tell Application" from the osascript. He is saying you should still get the results you want from system events w/o the Tell Application in front of it. BTW I was able to resolve this issue with a PPPC config profile from GitHub. I opened a ticket with JAMF and they pointed me to GitHub



Ref: https://www.jamf.com/jamf-nation/articles/553/preparing-your-organization-for-user-data-protections-on-macos-10-14



Ref: https://github.com/jamf/JamfPrivacyPreferencePolicyControlProfiles

I too was having this happen... I added the BundleID of Jamf.app with access to System Events and was getting pop-ups
Was about to go down the rabbit hole of what combo would work then I tried something simpler...



Remove the tell, activate, and end tell lines
Remove these lines:



tell application "System Events"

    activate

...

end tell


Now in the example from the original poster @leonwun , this may not be much of a help as you are explicitely telling System Events to restart and shutdown, methods that may not be available if you are not telling System Events. Not sure if these are the "nice" methods that ask for a user to save work, but if they are not (or you don't care 🙂 perhaps you could just capture the output of the osascript for button returned and then use bash to run shutdown -h now (halt/shutdown) or shutdown -r now (restart)



osaresult=$(/usr/bin/osascript -e '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' 2>/dev/null)

button=$(awk -F 'button returned:|, gave up:' '{print $2}' <<< $osaresult)


Use a case statement (or ifs) with the ${button} variable to do what you need



NOTE: There are caveats if you omit "telling" an application and you include an icon path
It must invoked/run from Self Service to succeed if an icon path is used
If you run the script directly from Terminal it will fail
If you invoke the policy via command line, it will fail (jamf policy -id <id> or jamf policy -event <name>)
If the policy is called from another policy using "jamf policy ..." via script script or with Files and Processes "run command", it will fail also...



For example, this will fail when run from Terminal:



osascript -e 'set dialogAnswer to display dialog "You can do a simple button pop-up, with timeout of 5 seconds" with title "Title" with icon file ":System:Library:CoreServices:CoreTypes.bundle:Contents:Resources:Clock.icns" buttons {"OK"} default button 1 giving up after "5"'


20:261: execution error: File file :System:Library:CoreServices:CoreTypes.bundle:Contents:Resources:Clock.icns wasn’t found. (-43)


However if the above snippet is in a script that is run in a Self Service actuated policy it will succeed.
So... there's a workaround but it only works in Self Service otherwise it's got some serious downsides to consider... hope this saved some folks a few hours (that I'll never get back ;)

Having all 3 items including allowing all the Apple Events allowed me to bypass the osascript prompt @leonwun .







How do you find osascript to add to those lists?

Have you looked here?: https://github.com/jamf/JamfPrivacyPreferencePolicyControlProfiles/blob/master/JamfAppleEvents.mobileconfig

@gene.kennett run this command in terminal to find path for osascript.



bash-3.2# which osascript
/usr/bin/osascript

I think I have this figured out. I was running into this exact problem while attempting to use osascript to remove Bluetooth devices from our loaner computers. I fixed this using a PPPC, see below:





I wasn't able to navigate to these files inside of the PPPC Utility, instead I had to open up the files in Finder and drag them into the PPPC Utility window. Add these files:
-- /Library/Application Support/JAMF/Jamf.app/Contents/MacOS/Jamf
-- /Library/Application Support/JAMF/Jamf.app/Contents/MacOS/JamfManagementService
-- (Right Click on Jamf.app and select "Show Package Contents" to get to these files)



Make sure to reference them inside of the Apple Events section as well.
Why not just add Jamf.app? I don't know. You would think that would work, but I could only get it to work by digging down to these specific files.
I hope this helps someone.

I'm seeing this message on fresh DEP/ADE enrollments when it says "enroll" wants to control system events. The enroll command is actually a tiny bash script that is installed in /usr/local/jamf , along with jamf binary, by the InstallApplication payload in the MDM profile. This script contains the jamf enroll -invitation 1234567890... and a few other commands like jamf recon.



I speculate that this could be a race condition where Jamf's PPPC profile hasn't arrived on the system when this script starts running — OR — that macOS takes too long to process the new approval.

@lparnell PERFECT! That's awesome. I ended up building a mobileconfig file version of your work and included it in my most recent project. https://github.com/franton/Mac-Patcher-and-Upgrader



Full credit given.

Im seeing similar issues as well.



Fresh installed Mac via ADE / DEP.

My eventual solution was to dump as much applescript as possible, stop referring to finder or system events and the issue cleared up.



In the future, I will dump all the applescript as soon as a dialog alternative is around.

@lparnell Did you find not having the "Big Sur Compatibility" turned on making a difference for machines with Big Sur? 

@lparnell Did you find not having the "Big Sur Compatibility" turned on making a difference for machines with Big Sur? 


I've honestly been so lost on this whole thing. I've started running into issues again with this and I don't know if it was one of the last updates that caused issues again or what. The last one I setup worked without utilizing the Big Sur Compatibility even though it was on Big Sur computers. Maybe using it will help with my current issue, but I can only bang my head against the wall for so long before I just give up.

If only they could make this process more complicated...

anyone have this working with a fresh install of DEP enrolled Big Sur 11.4? I had this working with Big Sur pre 11.4 trying to find out what changed.

I was able to resolve this with the following PPPC: 

Identifier: /usr/local/jamf/bin/jamf
Identifier Type: "Path"
Code Requirement: 
anchor apple generic and identifier "com.jamfsoftware.jamf" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or 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")

App Or Service = AppleEvents
Access = Allow
Receiver Identifier: com.apple.systemevents
Receiver Identifier Type: "Bundle ID"
Receiver Code Requirement: identifier "com.apple.systemevents" and anchor apple

Update: 
However after a tccutil reset Apple Events, the same pop up came back. Even after restart or reapplying the Configuration Profile. 

Anyone have any other suggestions?

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.

 

@jack_chung88  This didn't work at all for me. On launching the policy that uses applescript, the user still gets prompted twice: One to let Jamf access  System Events and another for Finder. 

Once the user does that, then the policy works. But end users don't know what to make of prompts like that, nor should they ever have to if IT is managing their computer. Something's wrong with PPPC in Big Sur and the latest version of JAMF. We never had to worry about this before just using the PPPC templates provided by JAMF. 

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-3465376 ), 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.

 

 

 

 

 

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-3465376 ), 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 I started playing around with this as I also started needing to have users click the ok button when it popped the "Jamf" wants access to control "System Events" message.  In our environment this is due to a AppleScript that takes their username and adds our domain name onto it to at least make creative cloud logins one step easier as well as opening safari and (default website) our class link portal, it also types in the username (as well as opens safari extensions so the user can click on the classlink extension).

 

I tried to use your suggestion however after setting the identifier to the generic .Jamf, then it seems to forget to give osascript permission to use accessibility to be able to type in what I want.

 

We are now using 12.2 and from the links you included, it looks like this was indeed broken in 11.4 (and worked previously for my login scripts).

Im still playing around though and will update if I find anything further.

@Bol I started playing around with this as I also started needing to have users click the ok button when it popped the "Jamf" wants access to control "System Events" message.  In our environment this is due to a AppleScript that takes their username and adds our domain name onto it to at least make creative cloud logins one step easier as well as opening safari and (default website) our class link portal, it also types in the username (as well as opens safari extensions so the user can click on the classlink extension).

 

I tried to use your suggestion however after setting the identifier to the generic .Jamf, then it seems to forget to give osascript permission to use accessibility to be able to type in what I want.

 

We are now using 12.2 and from the links you included, it looks like this was indeed broken in 11.4 (and worked previously for my login scripts).

Im still playing around though and will update if I find anything further.


@GabePPS Did you try using the whole identifier below, this is what worked for me;

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"

There may be new requirements preventing the relaxed one to work, I would leave your existing profiles and create another to apply along side with more access. I then worked back to find the correct permissions needed.

My pop ups were Jamf accessing Finder, with system events you may need accessibility or try full disk access to start allowing: com.jamf.management.service (Self Service)

Could you post the TCC access logs to see what is requiring the access?

Reply


Terms & ConditionsCookie settings