I have transitioned to a new website for my blog. Please adjust your bookmark to https://nine41consulting.com/blog.
Month: February 2017
Special Interchange Edition: Ivanti Apple Administrator Base Camp Course
In April of this year, Nine41 Consulting is launching as an Ivanti Expert Solution Provider, specializing in Apple device management for UEM. As part of that effort, Nine41 Consulting will be hosting a 4-day training course, May 5th – May 8th, just prior to Ivanti Interchange 17. If you’re interested, register at http://www.nine41consulting.com/training-calendar/
Force the Removal of a Specific macOS Configuration Profile
We’ve all done it. We installed something without fully vetting it out and now we need to get it off – of all of our machines. Whoops!
The other day, I received a question from a customer asking how he could remove a configuration profile from all of his machines at once – without having to log in to each machine.
Apple actually makes such a task quite easy as viewing, installing and removing a profile from a Mac is inherently built into the operating system itself. Therefore, with a short script we can detect whether the profile is installed and then remove it if it is.
To manually check the status of a machine’s profiles, you can run, inside of Terminal, the following command.
View All Profiles
sudo /usr/bin/profiles -P
So doing should give you a report out of both the machine and user based profiles installed.
In the screenshot above, all 3 profiles are computer based profiles. If I wanted to remove all of the profiles listed above, all I need to do is use the ‘profiles -D’ command and call the respective profileIdentifier.
Remove All Profiles
sudo /usr/bin/profiles -D
However, removing all profiles is probably a bit forceful, often a little precision can help us in the long run. In our example above, we may choose to only remove one of the profiles instead of all of them. To do this, we just need to specify that we’re removing a profile and what the profile identifier name is.
Remove a Single Profile
sudo /usr/bin/profiles -R -p com.landesk.profile
-R is the command to remove the profile and -p specifies we’re removing it by the identifier name. There are actually quite a few other options available as well, so check out the man page for more info. For example, you may need to add in the password to remove so the user doesn’t get prompted. This switch is -z.
Automation
Now, let’s use LANDESK Management Suite to create a custom patch definition that will detect the machines that have a given profile and remove it if you choose to repair it. You can download the custom definition I built on my GitHub site here or build it yourself using the scripts below.
Custom Patch Detection Logic
Just change the variable profileIdentifier to match your desired profile identifier.
#!/bin/sh
# singleConfigurationProfileDetection.sh
# Created by Bennett Norton on 2/6/17.
# Detects the whether a specific profile exists on a machine
# Profile Identifier Name Variable
# Change this name to match the profile identifier you want to remove
# Find the name by typing sudo /usr/bin/profiles -P in Terminal
profileIdentifier="com.landesk.profile"
# create an output variable with the the potential profile from the machine
# grep filters all of the results to only show that which matches our desired configuration profile
# awk allows us to pull just the data we're looking for from the command line
discoveredProfileIdentifier=( $( sudo /usr/bin/profiles -P | grep "$profileIdentifier" | awk '{print $4}') )
if [[ $profileIdentifier != $discoveredProfileIdentifier ]] ; then
echo "Found: Configuration profile $profileIdentifier was not found on the machine."
echo "Reason: $profileIdentifier not intalled."
echo "Expected: $profileIdentifier to not exist."
echo "Detected: 0"
exit 0
else
echo "Found: Configuration profile $discoveredProfileIdentifier was found on the machine."
echo "Reason: $discoveredProfileIdentifier intalled."
echo "Expected: $discoveredProfileIdentifier to not exist."
echo "Detected: 1"
exit 1
fi
Custom Definition Repair Script
Just as in the first script, you need to change the variable profileIdentifier to match your desired profile identifier.
#!/bin/sh # singleConfigurationProfileDeletion.sh # Created by Bennett Norton on 2/6/17. # Deletes a specific profile on a machine # Profile Identifier Name Variable # Change this name to match the profile identifier you want to remove # Find the name by typing sudo /usr/bin/profiles -P in Terminal profileIdentifier="com.landesk.profile" # Delete sudo /usr/bin/profiles -R -p "$profileIdentifier"
Disable Your Mac from Automatically Booting On Lid Open
The other day I was “flipping” through Flipboard and came across an article on OSXDaily that discussed how one could prevent a Mac from automatically booting when the lid is opened.
The command to enable or disable this setting is quite simple. By leveraging Terminal, all you need to do is set the AutoBoot value.
Disable AutoBoot:
sudo nvram AutoBoot=%00
Enable AutoBoot:
sudo nvram AutoBoot=%03
While I personally like the AutoBoot feature, I can see why some people may choose to disable it; especially in an academic or corporate setting.
Using LANDESK Security Suite 2016, the NVRAM AutoBoot setting can easily be scanned for with every vulnerability scan, by building a custom definition to evaluate the NVRAM AutoBoot value. Then, using the repair logic, you can maintain a desired state in your organization even if an administrative user opts to change it.
And, the best part is, I’ve created the custom definition for you – no scripting needed on your behalf. Download the custom definition from GitHub here and import it to your core server.
Custom Definition Import
- Open the LANDESK console
- Go to Tools > Security and Compliance > Patch and Compliance
- From the definition types dropdown menu, ensure you have selected Custom definition
- In the white space area, right click and select Import
- Browse to the custom definition file and click the Open button to import
Once imported, set the definition to Autofix and it will maintain the AutoBoot state for you. It’s that easy to maintain, pretty nice, isn’t? It doesn’t matter if a person changes the value themselves, using Autofix it will continually set the value back to the state defined in the defintiion.
Understanding the Custom Definition
If you’re like me and want to understand how I built the custom definition, as opposed to just blindly importing the file I created, then read on.
There are 5 basic steps to building a Mac custom definition. First, you need to create the custom definition and add in the Properties Details. Secondly, you need to create a detection rule and set the affected platform state. The third step is to provide a script to do the detection work, add that to the Custom Script panel. The forth step is to specify the repair process in the Patch Information panel. Lastly, you need to provide Patch Install Commands to make the changes necessary if you initiate a repair.
- Create a custom definition by clicking on the green circle with a white plus symbol when inside the Custom Definition dropdown panel
- Enter in your desired information on the General tab and Description tab, like the severity and notes around what the custom definition will do.
- Click the Add button under Detection Rules panel and specify your Affected Platforms. I check both Mac OS X and Mac OS X Server.
- Now you need to add in your detection logic in the Custom Script panel. For the AutoBoot feature, we really only need two lines. We need to specify the shebang environment and we need to capture the AutoBoot value. Now, I have added a few extra lines for documentation, which you can leave to assist your coworkers. My scripts are all pasted below or available on GitHub. Also, in every custom definition, you need to return the Found state, Reason state, Expected state and a Detected State of either 0 or 1. I don’t get into the details of this, so for more info see the Interchange Presentation regarding Custom Definitions.
- Finally, we need to add in the repair logic on the Patch Install Commands.
That’s all there is to it. Just hit OK at this point.
Now, if you’re wondering why I didn’t add in some Uninstall logic to revert our change back, if we desire, it is because the Mac agent doesn’t support it at this time. Feel free to put in a request with Product Management if you think this would be helpful.
Scripts
Detection Logic
#!/bin/sh
# autoBootNVRAMDetection.sh
# Created by Bennett Norton on 2/2/17.
# Detects the state of AutoBoot set in the NVRAM
# nvram AutoBoot will call and obtain the value for just the AutoBoot variable
# calling nvram -px will show all values and put the output in an XML format
# awk filters out the AutoBoot text and leaves us with just the value
autoBoot=( $( nvram AutoBoot| awk '{print $2}') )
# compare the nvram state with your desired state
# a value of %00 means the autoboot is disabled
# a value of %03 means the autoboot is enabled
# any other value means the autoboot state is undefined
if [[ $autoBoot == *"%00"* ]] ; then
echo "Found: NVRAM AutoBoot value is $autoBoot"
echo "Reason: NVRAM AutoBoot value is $autoBoot"
echo "Expected: NVRAM AutoBoot to be disabled or set to %00"
echo "Detected: 0"
exit 0
else
echo "Found: NVRAM AutoBoot value is $autoBoot"
echo "Reason: NNVRAM AutoBoot value is $autoBoot"
echo "Expected: NVRAM AutoBoot to be disabled or set to %00"
echo "Detected: 1"
exit 1
fi
Disable Logic
#!/bin/sh # autoBootNVRAMDisable.sh # Created by Bennett Norton on 2/2/17. # Sets the AutoBoot state in the NVRAM # nvram AutoBoot=### sets the state # a value of %00 means the autoboot is disabled # a value of %03 means the autoboot is enabled nvram AutoBoot=%00
Enable Logic
While I don’t use the next script in the custom definition, if you wanted to enable the setting for all machines, you’d use this script instead.
#!/bin/sh # autoBootNVRAMEnable.sh # Created by Bennett Norton on 2/2/17. # Sets the AutoBoot state in the NVRAM # nvram AutoBoot=### sets the state # a value of %00 means the autoboot is disabled # a value of %03 means the autoboot is enabled nvram AutoBoot=%03
Apple in the Enterprise Moved 
Recent Comments