Skip to main content

Hello All,

In an effort to lock down our Macs with the goal of removing local admins, we've created a Configuration Profile applying to machines which set various Restrictions. This includes what is accessible for users in System Preferences, Applications, functionality, etc. 

We also are using Admin By Request to allow users to request elevation for their Account Type to Admin to facilitate installs, updates, etc. 

However, with the way the Configuration Profile is applied, even when users elevate to Admin, the Configuration Profile with restrictions still applies. 

 

Is there a better way to lock down functionality of these machines so elevated Admins aren't bound by the restrictions? Or, is there a way to apply the Configuration Profile at a user level for only Standard account - so Admins bypass it?

 

Thank you for an assistance

Hi Nosred
We have configuration profile at user level.
We have still some users who have an incorrect MDM Enabaled/Capable Users. This means these users wont get the configuation profile at user level.
To still distribute our configuration profile at user level, I created a new extenstion attribute with the value yes or no.

Those with a correct MDM Enabled user will receive the profile at user level. if otherwise, they wont get anything.

Maybe this could be an idea for your environement too. 
if account == standard then

  push configuration profile

else

no configuration profile

fi
 ;-)

@Nosred 

1. You have to use extension attribute to identify if the user is admin. 

#!/bin/bash
loggedinUser=$(/bin/ls -l /dev/console | /usr/bin/awk '{ print $3 }')
# Check if current user is admin. If Yes, submit EA value as "Yes"
if [ $(dseditgroup -o checkmember -m "$loggedinUser" admin | awk '{print $1}') == "yes" ]; then
echo "<result>Yes</result>"
fi

2. Create a smart group based on the EA.

3. Add this smart group as exclusion for the restrictions. 

Note: Some restrictions may require you to restart the machine for the restrictions to be removed.

Thanks.

 

@Nosred 

1. You have to use extension attribute to identify if the user is admin. 

#!/bin/bash
loggedinUser=$(/bin/ls -l /dev/console | /usr/bin/awk '{ print $3 }')
# Check if current user is admin. If Yes, submit EA value as "Yes"
if [ $(dseditgroup -o checkmember -m "$loggedinUser" admin | awk '{print $1}') == "yes" ]; then
echo "<result>Yes</result>"
fi

2. Create a smart group based on the EA.

3. Add this smart group as exclusion for the restrictions. 

Note: Some restrictions may require you to restart the machine for the restrictions to be removed.

Thanks.

 


@karthikeyan_mac Thank you! That does work and I'm able to see users who are Admin on their machine. However, the uptake of the attribute is slow - taking hours for Admin users to report back to jamf that they're admins.

I'm not sure there is a way to trigger a Mac to report back to jamf once a user becomes admin - I come from a Windows environment where an event (user's account type changes for example) can be used to trigger an event/script/etc. I may be barking up the wrong tree. Either way, thank you for the assistance so far!

@karthikeyan_mac Thank you! That does work and I'm able to see users who are Admin on their machine. However, the uptake of the attribute is slow - taking hours for Admin users to report back to jamf that they're admins.

I'm not sure there is a way to trigger a Mac to report back to jamf once a user becomes admin - I come from a Windows environment where an event (user's account type changes for example) can be used to trigger an event/script/etc. I may be barking up the wrong tree. Either way, thank you for the assistance so far!


@Nosred you can try adding `jamf recon` in the extension attribute after submitting the result. I have not tested it but you can give a try.

Thanks

Reply


Terms & ConditionsCookie settings