Special Interchange Edition: Ivanti Apple Administrator Base Camp Course

artboard-1

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.

profiles -P.png

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

  1. Open the LANDESK console
  2. Go to Tools > Security and Compliance > Patch and Compliance
  3. From the definition types dropdown menu, ensure you have selected Custom definitionpatch and compliance dropdown menu.png
  4. In the white space area, right click and select Import custom definition import.png
  5. 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.

  1. Create a custom definition by clicking on the green circle with a white plus symbol when inside the Custom Definition dropdown panel screen-shot-2017-02-03-at-1-19-16-pm
  2. Enter in your desired information on the General tab and Description tab, like the severity and notes around what the custom definition will do.  Properties Panel.png
  3. Click the Add button under Detection Rules panel and specify your Affected Platforms.  I check both Mac OS X and Mac OS X Server.Affected Platforms.png
  4. 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.Detection Logic.png
  5. Finally, we need to add in the repair logic on the Patch Install Commands.  Patch Install Commands.png

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

 

Migrate a Mac’s Outlook Settings from an On Premise Server to a Hosted Office 365 Instance

Last week a customer approached me asking for some assistance in migrating their client devices from an on-premise server to their new Office 365 instance hosted in the cloud. In addition to migrating to a new Exchange server, the customer was also planning on moving all of the clients to Outlook 2016 from Outlook 2011.

Having not had the experience personally in doing this in a business environment, I was unsure what the entire process was going to look like.  Luckily, with only a few minutes of google searching, I discovered a post in which Talkingmoose outlined how a simple Applescript would do the trick.

tell application "Microsoft Outlook"
    set server of exchange account 1 to "https://outlook.office365.com/"
end tell

With the AppleScript in hand, we just needed to put together a process to use LANDESK or what is now rebranded as Ivanti.  The Ivanti Mac agent itself, unfortunately, doesn’t support AppleScript directly.  That means that rather than creating an AppleScript file, I needed to write a shell script and simply change the shebang line environment to be osascript as opposed to the standard shell.

#!/usr/bin/env osascript

And that’s it.  I pushed out the script using LANDESK Management Suite, and even with the Outlook client open on the test device, the server URL was appropriately changed.

You can download the script from GitHub, or as I typically do, the full script is below. You’ll see it’s very short.

#!/usr/bin/env osascript
# changeOutlookServer.sh
# Created by Bennett Norton on 1/25/17.

tell application "Microsoft Outlook"
 set server of exchange account 1 to "https://outlook.office365.com/"
end tell

Remember, after you save your file, set the execute permissions on it by opening terminal and running the command below and then copy it to your package server share.

chmod +x /path/to/your/script.sh

With the script ready, you now need to build the software package to distribute to the Macs.  To do this, follow these steps below:

  • From the LANDESK Console, open Tools > Distribution > Distribution Packages
  • Inside the menu tree, highlight My Packages or Public Packages and then select the New Package button on the menubar and select New > Macintosh > Macintosh Agent
  • Give the package a name, description and point the primary file to the .sh file created previously
  • Fill out the Metadata details if desired
  • Save the package

In a true migration environment, I would create a bundle package that pushes out both the Office upgrade as well as the script to change the Exchange server address.  See my previous blog post on how to build an Office 2016 package.

 

 

How to Bind a Mac to Active Directory using Profile Manager and LANDESK

Below is a somewhat brief overview of how you can build a payload with the settings to bind a Mac to a domain.

In order to build this Directory payload, you’ll need to download and install macOS Server.  Your clients won’t need access to the macOS Server, so you can put this on a virtual machine that you start just when you need to build a new profile.

You’ll also need LANDESK Management Suite 9.6 or greater.

Distributing Enterprise Applications to macOS devices using MDM

Distributing Enterprise Applications to macOS devices using MDM

In an earlier blog post, Bennett described how to create and deploy VPP software packages to macOS and iOS devices using LANDESK Management Suite 2016.3 and later. You may have noticed a radio button in the console UI that, at the time, was ignored:

manifest-url-package

Yep, you can deploy your own software packages using LDMS MDM, not just those software applications available on the App Store.

If you select the Manifest URL button, you get some additional UI:

mdm-properties

The additional UI allows you to enter the URL of a manifest plist file, and the Bundle ID and version of the application being installed. This can seem pretty daunting. Thank goodness Apple has provided a web page documenting the requirements for software distribution via MDM. It’s a good read, and answers a lot of questions, but, at least for me, it didn’t get to the point of being able to create something I could distribute via MDM. But let me summarize:

To distribute software or other things (like fonts for example), you need:

  1. Create an installer package (a .pkg file) created with the productbuild command-line tool, and signed with the root certificate of your mdm solution.
  2. A manifest file in the form of a property list (.plist) which describes and points to the installer package in very specific ways (see the above link for a sample)
  3. A webshare, accessible from your intranet or the Internet. You can place the package and manifest file in a hidden directory or in any location that’s readable using https. It must be readable using https, and using a non-self-signed certificate, since Apple URL services will not connect via https to a server with a self-signed cert.

Once you have these three things, you can fill out the Manifest URL UI to create an LDMS package to distribute to enrolled macOS devices using MDM.

The installer package

Creating an installer package for an application you want to install can be as easy as running the command line tool product build. For example, to create an installer package on my external drive “Work” for Google Chrome, which is sitting in my Applications folder, the following terminal command will do the trick:

productbuild --component "/Applications/Google Chrome.app" "/Applications", "/Volumes/Work/Google Chrome.pkg" --sign identity-name

You will need to replace identity-name with the name of a valid signing certificate on your computer. If you have enrolled your macOS device in the LDMS MDM service, you can find the certificate for the MDM service in your system keychain. This is a valid signing certificate for deployment with our MDM solution.

The manifest file

If you read the Apple documentation (see above), you were given an example manifest file to fill out with our package-specific info (I’ve simplified this by removing some items that are not applicable to the LANDESK environment:

Sample macOS content manifest file for an application bundle
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">
     <dict>
         <key>items</key>
         <array>
              <dict>
                   <key>assets</key>
                   <array>
                       <dict>
                            <key>kind</key>
                            <string>software-package</string>
                            <key>md5-size</key>
                            <integer>10485760</integer>
                            <key>md5s</key>
                            <array>
                                 <string>41fa64bb7a7cae5a46bfb45821ac8b99</string>
                                 <string>51fa64bb7a7cae5a46bfb45821ac8b98</string>
                                 <string>61fa64bb7a7cae5a46bfb45821ac8b97</string>
                            </array>
                            <key>url</key>
                            <string>https://www.example.com/apps/myapp.pkg</string>
                       </dict>
                   </array>
                   <key>metadata</key>
                   <dict>
                       <key>bundle-identifier</key>
                       <string>com.example.myapp</string>
                       <key>bundle-version</key>
                       <string>1.0</string>
                       <key>items</key>
                       <array>
                            <dict>
                                 <key>bundle-identifier</key>
                                 <string>com.example.myapp-unique</string>
                                 <key>bundle-version</key>
                                 <string>1.7.4</string>
                            <dict>
                       </array>
                       <key>kind</key>
                       <string>software</string>
                       <key>sizeInBytes</key>
                       <string>26613453</string>
                       <key>title</key>
                       <string>Example My App Package</string>
                   </dict>
              </dict>
         </array>
     </dict>
</plist>

Things to know about if you are planning to do this by hand:

Once we have the package built as above, to fill out this manifest file, the application needs to know:

  1. The location of the the installer package on the https server. Replace “https://www.example.com/apps/myapp.pkg” with the actual name and location of the hosted package.
  2. The md5-hash of each 1 megabyte chunk of the installer package file. Replace the array of md5 hash (labeled “md5s” above) with the actual hashes.
  3. The bundle identifier and version of the application you are installing. Replace the strings labeled “bundle-identifier” and “bundle-version” above with those strings.
  4. The size in bytes of the application package. Replace the string labeled “sizeInBytes” above with this.

When the manifest file (“something.plist”) has been successfully created, it needs to be moved to the same server that is actually serving the installer package. Best practice is probably to place both the manifest plist file and the installer package file in a directory appropriately named on the https server. So, for example, if our application was named “Example.app”, we might have Example.pkg and manifest.plist files sitting on the server in a directory named “Example”.

The LDMS Manifest Package UI

Once we have the package and manifest file build correctly and hosted on our https server of choice, filling out the LDMS Manifest Package UI is pretty simple. I paste the manifest file url into a web browser, load it up, and copy and paste the bundle id and version into the LDMS Manifest Package UI, along with the manifest file url.

Conclusion

Well, there you go, you now have all of the information you need to be able to build your own manifest distribution packages for the LDMS MDM solution. I can vouch for these instructions, as they have allowed me to attain nearly a 25% success rate manually setting things up. I’m sure you can do even better…

But we couldn’t get anywhere getting our own work done without starting to automate some of the pieces of this task, and at this point we’ve managed to produce an early version of an app we’re calling Manifester, which you can point at an application bundle, or a directory with an application bundle, put in your signing cert, and have it create a directory with an installer package and manifest file in it that you can just copy to the correct location on your https server:

manifester

Manifester will create a .manifestation folder which you then upload to the location on your https webshare that you specified in the Manifester UI.

manifest-output

Manifester currently supports creating manifest distribution for macOS applications. We will be enhancing it as we get time to support other file types (probably fonts will be first). It should be available through the LANDESK Community site soon after the first of the year.

 

 

 

Assigning DEP Enabled Devices to an Apple MDM Server

The Holy Grail

Zero-touch configuration for IT, the holy grail of device management!  This is the promise of a DEP enabled device.  Just buy it and turn it on, it’ll pull down your designated management profile once the device has an established Internet connection and all of the associated settings and applications assigned will be deployed to the device.

Easy, right?  For the most part, yes it is.  All you need to do is make sure your DEP enabled devices, purchased from Apple or from an authorized DEP reseller, are associated with an Apple MDM server.  In turn, that Apple MDM server needs to be configured with your MDM management service.  To configure LANDESK as your preferred MDM server, see my previous blog post.

Today’s discussion will simply focus on getting those Apple devices enrolled with Apple’s MDM server.  While the process only takes a few minutes, it is a required step for that zero-touch configuration; so don’t skip it.

Adding an Apple Device to an Apple MDM Server

  1. Browse to https://deploy.apple.com from your browser of choice deplogin
  2. Provide your Apple ID associated with your DEP account – enroll with Apple here if you have not yet performed this step
  3. Provide your two-factor authentication verification code; this is required by Apple for DEP management2factor
  4. From the menu bar on the left, select Manage Devices
  5. Select your desired radio button to add devices by Serial Number, Order Number or via a CSV Uploadserialnumber-assign
  6. Select the action Assign to Server under Step 2 and find your appropriate server from the drop down list and hit OKassign-complete

And that’s it.  Now when you unbox your shiny new Apple device, whether it be an iOS or macOS device, once it has an Internet connection (the touch part in the zero-touch process 🙂 ), it’ll pull down the assigned profile from your MDM server.  Then, anytime the device is reset, the process will re-enage, ensuring that device always has your MDM profile assigned.

How to Customize and Silently Deploy Cisco AnyConnect 4.x

If you’re an existing 3.x consumer of Cisco AnyConnect you may be surprised when you load up the 4.x installer and find your users have a plethora of additional features; like Web Security, System Scan, Roaming Security and AMP Enabler.ciscoanyconnect-all

If these are features you’re planning on using, great, you’re all set.  If you were just hoping to leverage the VPN, well, all is not lost.  You can easily customize the installer, providing it a set of instructions indicating what modules you want installed and what modules you want blocked – and it’s all done via a simple PLIST file.

I’ve included the entire example PLIST I used to block everything but the VPN as well as the installer script for LANDESK on my GitHub site here.

Let’s discuss the PLIST first.  Here is an example of one of the dictionary objects found in the PLIST file, in this case it is for the VPN feature.

 <dict>
    <key>attributeSetting</key>
    <integer>1</integer>
    <key>choiceAttribute</key>
    <string>selected</string>
    <key>choiceIdentifier</key>
    <string>choice_vpn</string>
 </dict>

Basically we have a dictionary of values that define the module and tell the installer of whether it should be installed by setting the Integer value to 1.  If you want to block the given module, set the integer value to 0.  Look at the string value to figure out what module you’re enabling or disabling.

You shouldn’t need to adjust any of the other settings.  So go ahead and download the example PLIST file I have on my GitHub site and finish customizing it for your environment.  My PLIST file has everything disabled  outside of the VPN.  If you were to manually install the application, you’d see the window below.  manualinstallciscooptions

Now that you have your PLIST ready to go, you need to save it as ‘ChoiceChangesCiscoAnyConnect.plist’ so it can be properly referenced in our installer script.  If you save it as something else, just make sure you make the appropriate change in your installer script.

OK, we’re now ready to create the installer script.  For simplicity, I’m going to build my installer script to do both the downloading of the AnyConnect package file, the PLIST file we just created and then it’ll kick off the installer – all using SDClient so I can take advantage of the bandwidth and throttling settings.

The entire installer script is pasted below.  In your environment, you’ll likely only need to change the plistFilePath and packageFilePath variables.  The script copies everything to a folder titled CiscoAnyConnect inside of sdcache.  I  purposely chose to put everything in the sdcache folder as the script doesn’t purge anything when finished, letting the standard sdcache cleanup process take care of that at the appropriate time.

Once you have your paths set, you should be ready to go.  You’ll notice that SDClient is used, with several arguments, to download the files.  The -noinstall argument is quite obvious, it tells SDClient to just download and not do anything else.  The -package is telling SDClient where to obtain the file and the -destdir argument is telling SDClient where to copy the file to.

/Library/Application\ Support/LANDesk/bin/sdclient -noinstall -package "$packageToCopy" -destdir "$destinationLocation"

As mentioned before, the script copies down the PLIST file and the Cisco installer.  If you have a DMG version of the Cisco Installer, just mount it on a Mac and copy out the AnyConnect.pkg from the DMG.  I copied mine directly to my standard SWD file share.

Then the scripts wraps up by executing the AnyConnect.pkg installer with a few arguments as well.  We tell macOS we want it to run a pkg intsaller and point to where that file is.  In my example, it’s in the /Library/Application Support/LANDesk/sdcache/CiscoAnyConnect folder.  I leave the -target path empty, basically letting the installer put where it’s designed to.  I then add the flag -applyChoiceChangesXML so that it knows customization is to be performed and I supply the path to that name/file.

installer -pkg "$destinationLocation"/"$packageName" -target / -applyChoiceChangesXML "$destinationLocation"/"$plistName"

And that’s it.  You now have everything you need to deploy your package.  Save out your installer script, I named mine ciscoAnyConnect4.3Deploy.sh but you can name yours whatever you want.

As always, once saved, make sure you give the script the execution permissions by opening Terminal and running:

sudo chmod +x /path/to/script.sh

Now copy your installer script to your LANDESK SWD file share.  I used the same path for my script, PLIST file and AnyConnect.pkg installer.

Once you’ve copied up your script, you just need to create your LANDESK Mac package so you can target and silently deploy Cisco AnyConnect with all of your customizations.

Creating LANDESK Management Suite Mac Packages

  1. Open the LANDESK Console
  2. Navigate to the top menu bar, select Tools > Distribution > Distribution Packages.
  3. In the lower left menu tree, highlight My Packages or Public Packages from within the Distribution Packages window
  4. On the Distribution menu bar, press the New Package button and select New Macintosh Agent package.
  5. Give the package a name
  6. Provide a description as well as any metadata information desired
  7. Set the primary file to the script file you previously transferred to your package share
  8. Fill out the Metadata details if desired, specifically supplying a logo so it shows up properly in the portal
  9. Save the package

Creating a Scheduled Mac Software Distribution Task

  1. Right click on the Mac software distribution package created and select Create Scheduled Task
  2. From the network view, select and drag the desired machine(s), user(s) or query(ies) and drop them onto the task
  3. Now, right click on the task and select properties
  4. Set the desired Task type under Task Settings as to whether you want a push, a policy or a hybrid of the two types in a policy-supported push
  5. Set the radio button in the Portal Settings to either Recommended or Optional if you desire to put the package into Workspaces.  If you’d like to automatically deploy the app, select Run automatically
  6. Change the Reboot Settings or Distribution and Patch settings if desired
  7. Set the schedule task settings with the appropriate start time

PLIST File

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<array>
 <dict>
 <key>attributeSetting</key>
 <integer>1</integer>
 <key>choiceAttribute</key>
 <string>selected</string>
 <key>choiceIdentifier</key>
 <string>choice_vpn</string>
 </dict>
 <dict>
 <key>attributeSetting</key>
 <integer>0</integer>
 <key>choiceAttribute</key>
 <string>selected</string>
 <key>choiceIdentifier</key>
 <string>choice_websecurity</string>
 </dict>
 <dict>
 <key>attributeSetting</key>
 <integer>0</integer>
 <key>choiceAttribute</key>
 <string>selected</string>
 <key>choiceIdentifier</key>
 <string>choice_fireamp</string>
 </dict>
 <dict>
 <key>attributeSetting</key>
 <integer>0</integer>
 <key>choiceAttribute</key>
 <string>selected</string>
 <key>choiceIdentifier</key>
 <string>choice_dart</string>
 </dict>
 <dict>
 <key>attributeSetting</key>
 <integer>0</integer>
 <key>choiceAttribute</key>
 <string>selected</string>
 <key>choiceIdentifier</key>
 <string>choice_posture</string>
 </dict>
 <dict>
 <key>attributeSetting</key>
 <integer>0</integer>
 <key>choiceAttribute</key>
 <string>selected</string>
 <key>choiceIdentifier</key>
 <string>choice_iseposture</string>
 </dict>
 <dict>
 <key>attributeSetting</key>
 <integer>0</integer>
 <key>choiceAttribute</key>
 <string>selected</string>
 <key>choiceIdentifier</key>
 <string>choice_nvm</string>
 </dict>
 <dict>
 <key>attributeSetting</key>
 <integer>0</integer>
 <key>choiceAttribute</key>
 <string>selected</string>
 <key>choiceIdentifier</key>
 <string>choice_umbrella</string>
 </dict>
</array>
</plist>

Installer Script

#!/bin/sh

# ciscoAnyConnect4.3Deploy.sh
# Created by Bennett Norton on 11/30/16.


#File to copy
#change this to match your hosted path, it needs to be http
plistName="ChoiceChangesCiscoAnyConnect.plist"
packageName="AnyConnect.pkg"
plistFilePath="http://yourFileShareServer/Path/To/PLIST"
packageFilePath="http://yourFileShareServer/Path/To/CiscoAnyConnect"
packageToCopy="$packageFilePath"/"$packageName"
plistToCopy="$plistFilePath"/"$plistName"

#Location to copy file to
#change this to match your destination path
destinationLocation='/Library/Application\ Support/LANDesk/sdcache/CiscoAnyConnect'

#Check to see if destination exists and if not, create it
if [ ! -d "$destinationLocation" ]; then
echo "Location doesn't exist. Creating directory"
mkdir $destinationLocation
echo "$destinationLocation created"
fi

#Download and execute command
#You shouldn't need to make any changes here
#-noinstall ensure the package does not get executed when downloaded
#-package is the source url path
#-destdir is the destination url path
/Library/Application\ Support/LANDesk/bin/sdclient -noinstall -package "$packageToCopy" -destdir "$destinationLocation"
/Library/Application\ Support/LANDesk/bin/sdclient -noinstall -package "$plistToCopy" -destdir "$destinationLocation"
installer -pkg "$destinationLocation"/"$packageName" -target / -applyChoiceChangesXML "$destinationLocation"/"$plistName"

Remotely Inject a CylancePROTECT License Token on macOS

Have you found that, after a seemingly random period of time post CylancePROTECT deployment, your help desk is receiving calls about CylancePROTECT not being licensed?

Well, you’re not the only one.

The client / server architecture setup for CylancePROTECT on macOS requires that the client machine check-in on a periodic basis or it will automatically “forget” it’s license key.

This behavior is great if the machine happens to be lost or stolen; however, if you have remote users that don’t frequently get on the network, having a machine forget it’s license is definitely not ideal.

Luckily, we can remotely inject the license key using LANDESK Management Suite to deploy a little script to work the magic.  All remotely might I add.  Neither you nor I want to touch every machine that needs an update.

Furthermore, this script would work if you find that your original license key was compromised and you need to replace it with a new one.

The script is a fairly basic script.  It’ll stop the CylancePROTECT service, run a backup on the existing token XML file, inject the token into the XML, and restart the service.  All you need to do in the script is change the variable value “newCylanceCustomToken” with your actual token value.  You can download the script from my GitHub site or just create your own by copying and pasting from the script below.  Just remember to run chmod +x on your script if you make your own.

Special shout out goes to Logrhythm SIEM for the assist on the SED portion of this script.

Once you have your script ready to go, compress it and copy it to your file share so you can create a LANDESK package and deploy it out.

CylancePROTECT Package Creation

  1. Open the LANDESK Management Suite Console
  2. Navigate to the top menu bar, select Tools > Distribution > Distribution Packages.
  3. In the lower left menu tree, highlight My Packages or Public Packages from within the Distribution Packages window
  4. On the Distribution menu bar, press the New Package button and select New Macintosh Agent package.
  5. Give the package a name
  6. Provide a description as well as any metadata information desired
  7. Set the primary file to the script file you previously transferred to your package share
  8. Fill out the Metadata details if desired, specifically supplying a logo so it shows up properly in the portal
  9. Save the package

CylancePROTECT Package Deployment

  1. Right click on the Mac software distribution package created and select Create Scheduled Task
  2. From the network view, select and drag the desired machine(s), user(s) or query(ies) and drop them onto the task
  3. Now, right click on the task and select properties
  4. Set the desired Task type under Task Settings as to whether you want a push, a policy or a hybrid of the two types in a policy-supported push
  5. Set the radio button in the Portal Settings to Run Automatically
  6. Change the Reboot Settings or Distribution and Patch settings if desired
  7. Set the schedule task settings with the appropriate start time

 

#!/bin/sh

# CylanceTokenReplacement.sh
# Created by Bennett Norton and Logrhythm SIEM on 10/20/16.
# This script will stop the Cylance service, replace the token file, and restart Cylance

#Script Variable
#change the variable to match your token 
newCylanceToken="newCylanceCustomToken"

#Don't change these variables
cylanceTokenLocation="/Library/Application Support/Cylance/Desktop/registry/LocalMachine/Software/Cylance/Desktop/"
cylanceValuesXML="values.xml"

#Stop the Cylance service
launchctl unload /Library/LaunchDaemons/com.cylance.agent_service.plist

#Make a backup of the values.xml and then edit the by adding in the InstallToken key
sed -i.backup 's/<\/values>/<value name=\"InstallToken\" type=\"string\">'"$newCylanceToken"'<\/value><\/values>/g' "$cylanceTokenLocation/$cylanceValuesXML"

#Start the Cylance service
launchctl load /Library/LaunchDaemons/com.cylance.agent_service.plist