Skip to main content

I have a stupid script that removes stale homedirs in a computer lab that (for reasons I won't get into) uses PURE network accounts. Computers bound to AD, etc...so we can't leverage jamf -removeAccount type of script 

 

Network accounts aren't really accounts. 

The lab manager wants homedirs that haven't been modified for 14 days to be removed. We have a script that works. We point to it in a policy that can be run in Terminal as a custom trigger or could be scheduled to run at a set interval. It works just fine,  but only  if Terminal is granted full disk access.

 

I know that JAMF scripts get copied to a local temp dir and run from there. How can I do what I want without granting Terminal full disk access (slight security risk but I don't want to do it if I don't have to). 

so are you not executing the script from Jamf Pro? just from the workstation? the wording is throwing me off a little here.  I would avoid kicking it off manually through terminal and do it through Self Service(maybe behind login) as it will always run the policy with root access, this way the lab manager can do it on their own if they want, right at the workstation vs you setting it up to be a set interval or granting application permissions.

@teodle  You will need to whitelist the Jamf daemon to interact with another app eg. Terminal. That will then cover policies triggered by login / startup etc.

From Self Service you would do the same but for the Jamf management service. 

For example;

Identifier: com.jamf.management.Jamf
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"

Apple Events
Receiver Identifier: com.apple.Terminal
Receiver Code Requirement: identifier "com.apple.Terminal" and anchor apple

 

so are you not executing the script from Jamf Pro? just from the workstation? the wording is throwing me off a little here.  I would avoid kicking it off manually through terminal and do it through Self Service(maybe behind login) as it will always run the policy with root access, this way the lab manager can do it on their own if they want, right at the workstation vs you setting it up to be a set interval or granting application permissions.


it is kicked off through jamf custom trigger right now just for testing but the idea is to schedule it. 

 

@Bol   so out of the box, JAMF isn't configured so that jamf management and jamf daemon can manage the Mac without restriction?

 

we have a TON of PPPC payloads --everything from Zoom to Adobe AfterEffects. Just didn't realize that we needed one for Terminal.app

 

Jamf Pro does have its own built in PPPC and it will execute scripts and perform tasks etc without user intervention com.jamf.management.Jamf is in this payload automatically.

.  If you execute a script within terminal, the app will ask for those permissions as you're using it at the user level.  you should not get any sort of prompts for allowing if you are running this from the server unless there is something in the script that is being passed as a user.  

@TheAngryYeti  Correct, although Jamf out of the box profiles whitelist the binary : com.jamf.management.daemon

Code requirements changed in later macOS 12 versions, you must whitelist the parent bundle as opposed to the child / helper binaries.

See here for more details;
https://community.jamf.com/t5/jamf-pro/quot-jamf-quot-wants-access-to-control-quot-system-events-quot/m-p/256295/highlight/true#M237627

@Bol   so out of the box, JAMF isn't configured so that jamf management and jamf daemon can manage the Mac without restriction?

 


You can enable this in security as below. Unless something has changed in the last few Jamf Pro versions that i've missed, it still only whitelists the helper applications as opposed to the parent bundle id.
This is where things got tripped up after some hardening by Apple.
For me, I was using Apple Script to interact with terminal / finder etc. on a login script. 

 

@Bol   so out of the box, JAMF isn't configured so that jamf management and jamf daemon can manage the Mac without restriction?

 


And sorry, Jamf daemon handles automated policies, jamf software service handles policies called from self service

we have a TON of PPPC payloads --everything from Zoom to Adobe AfterEffects. Just didn't realize that we needed one for Terminal.app

 


The built in Jamf payload handles bare bones, you need to add additional permissions for it to interract with other applications.

You are calling a policy from Jamf -> to then interact with Terminal. Apple blocks by default as a part of TCCC

You can enable this in security as below. Unless something has changed in the last few Jamf Pro versions that i've missed, it still only whitelists the helper applications as opposed to the parent bundle id.
This is where things got tripped up after some hardening by Apple.
For me, I was using Apple Script to interact with terminal / finder etc. on a login script. 

 


In our instance, we deploy a custom PPPC config profile; the "Automatically install a Privacy Preferences Policy Control profile for "Jamf management framework" is NOT checked. 

In our instance, we deploy a custom PPPC config profile; the "Automatically install a Privacy Preferences Policy Control profile for "Jamf management framework" is NOT checked. 


Same, although it doesn't really matter if it is or isn't selected with a custom payload as the higher permission profile should take precedence.

Reply


Terms & ConditionsCookie settings