Quantcast
Channel: SimpleMDM – SimpleMDM
Viewing all 51 articles
Browse latest View live

iOS Deployments Without Apple IDs

$
0
0

You-will-enter-the-Apple-ID-password-once

The Problem with Apple IDs

Not long ago, a unique Apple ID was required for every iOS device in a deployment. Without it, a device wouldn’t be able to install apps. Similarly, features like iCloud Lost Mode could not be utilized.

For bring-your-own-device (BYOD) deployments where employees own their own devices, this wasn’t a problem. A given employee already had an Apple ID on their device from installing personal apps. If a device went missing, the company couldn’t utilize lost mode, but the employee could.

For large deployments of company-owned devices however, this Apple ID requirement was a massive headache. Two common solutions emerged:

  1. One Apple ID would be used for every device in the deployment. This sometimes worked, but was a violation of Apple policy. Apple was known to shut down Apple IDs that were being used in this manner.
  2. Administrators used scripts to automatically generate hundreds of Apple IDs. They then entered these Apple IDs by hand on each device.

Both of these solutions were nightmares in of themselves for obvious reasons.

Luckily, Apple has gradually loosened the dependency on Apple IDs over the years and now provides facilities to manage iOS devices entirely independent of Apple IDs. If you are planning on deploying a fleet of company owned devices, we strongly recommend using the following features of SimpleMDM.

Device-Assignable VPP App Licenses

An iOS device will not run an app unless it has a license for it. This goes for free apps as well. This isn’t readily apparent because a lot of the app licensing in iOS occurs in the background.

For instance, when installing an app from the Apple app store, iOS prompts for an Apple ID before allowing the app to download. The reason is that Apple needs to apply a license to the Apple ID so that the app will have permission to run on the device.

Enter the Apple Volume Purchase Program (VPP).  Apple recently expanded VPP to allow assignment of licenses directly to a device via serial number, instead of requiring an Apple ID. This means that a company can purchase licenses for most apps, including free apps, and license a device to run an app without the need for an Apple ID at all.

SimpleMDM seamlessly handles app licensing at the device level by default. By purchasing licenses for apps in VPP, SimpleMDM will intelligently assign licenses to devices right before installing the app to the device. No Apple ID prompt will appear on the devices themselves.

MDM Lost Mode

As recently as iOS 9.3, Apple and SimpleMDM now support activating, monitoring, and disabling Lost Mode from within SimpleMDM without requiring access to an Apple ID or iCloud account. The only requirement for using this functionality is that a device is in supervised mode.

Lost mode via MDM makes particular sense for company owned devices because IT can effectively recover a device without requiring intervention from the device user. Previously, the owner of the Apple ID on the device would need to grant IT access to their iCloud account, or, IT would need to have pre-initialized a device with an Apple ID.

Next Steps

SimpleMDM supports iOS Lost Mode and device-assignable VPP app licenses. You can begin using these features today and manage your deployment without using Apple IDs.

For further reading, we suggest the following articles:

iOS 9.3 Lost Mode, Per-Device App Deployment, Notes

Introducing Per-Device VPP App Distribution. No Apple ID required.

 


Install iOS Apps Silently

$
0
0

One of the most common requirements is the ability to install apps without requiring user intervention on the device itself. We wrote this guide to explain the reason prompts appear and how to avoid them, achieving silent app push and installation with SimpleMDM.

The Two Hurdles to Silent App Installations

When pushing an App Store app to a typical iOS device, there are two prompts that are typically displayed to the user before an app will install.

The first prompt requests permission to install the app on the device. This exists because Apple believes that a company should not be able to install an app on an employee-owned device without their permission. To avoid this problem you must indicate to Apple that the device you’re pushing the app to is actually owned and managed by a company.

If you aren’t already familiar with it, device supervision is the way to indicate this relationship to Apple. When a device is put into supervised mode, SimpleMDM is given additional controls and permission on the device, including the ability to install an app without requesting permission from the device user first.

We’ve produced the following article and suggest reading it for more information on device supervision: What is iOS Supervised Mode? How do I activate Supervision?

The second prompt to appear is related to licensing and will ask the user to enter their Apple ID if they haven’t already. The best way around this is to purchase app licenses through the Apple Volume Purchase Program (VPP) and allow SimpleMDM to assign licenses to devices directly. When SimpleMDM handles license assignment, the device will not prompt for an Apple ID.

For more information on Apple VPP and per-device licensing, we recommend reading: Introducing Per-Device VPP App Distribution. No Apple ID required..

Other Potential Problems

In some cases, even with supervised devices and VPP app distribution, problems occur. Here are the common ones to look out for:

  • Some app licenses do not support device assignment. App licenses, by default, support device assignment. App developers retain the rights to disable this feature, however. On rare occasion, you may find that app licenses you have purchased do not support device based assignment. When this occurs, iOS will prompt the user for an Apple ID.
  • iOS 9.3 or greater is required. Earlier versions of iOS do not support device-based app assignment.

Introducing Location History & Improved Mobile App

$
0
0

Location History

Screen Shot 2016-08-15 at 11.46.25 AM

SimpleMDM now has the ability to display historical device locations. To see historic location information for any device, go to the device details screen. A map showing the most recent location update as well as any activity from 24 hours previous to the update is shown. Click on any historic location marker to see the time that the update occurred.

Additionally, administrators may request a location update manually by clicking the “update” button at the bottom of the map. The device will respond with a location update at its earliest convenience: generally within a minute if the device has internet connectivity.

To take advantage of location tracking during normal operation, the SimpleMDM mobile app must be installed and opened on the device you wish to track. Location tracking via MDM Lost Mode is still available when lost mode is activated on supervised devices, with or without the SimpleMDM mobile app.

Mobile App Enhancements

The SimpleMDM mobile app has undergone many changes in order to improve its reliability, accuracy, and ease of use.

Enhancements:

  • More reliable location updates
  • Admin ability to manually request current location
  • Better detection of iOS settings that may prevent proper functionality
  • Additional instruction on resolving settings-related issues

Version 2.0.0 of the app is available from the app store today. If you haven’t already, we strongly recommend upgrading.

screen696x696

Push Apple Configurator 2 Profiles to SimpleMDM Devices

$
0
0

configurator

Ever needed a feature available in Apple Configurator 2 that’s not supported by SimpleMDM? Or, do you have configuration profiles you’ve previously created that you’d prefer not to rebuild?

SimpleMDM now supports uploading and deploying custom configuration profiles to managed devices.

Getting started is easy:

  1. Create or open an existing profile in Apple Configurator.
  2. Save the profile as a .mobileconfig file.
  3. Upload the profile to your SimpleMDM account as a custom configuration profile.
  4. Assign the profile to the device groups you wish to deploy to.

SimpleMDM will process your configuration and deploy it to assigned devices as if it were generated by SimpleMDM.

How to Block iOS Updates

$
0
0

 

update-10

A common question we receive through our support channel is this: How can we prevent our devices from updating to the latest version of iOS?

Often, organizations wish to vet the latest iOS release, verifying that the business-related apps they use will continue to function properly on the devices used by their organization. By delaying the deployment of the latest version of iOS within their organization, they buy additional time to run these checks before green lighting the upgrade.

The Different Methods We’ve Seen

To be clear, Apple does not currently provide any functionality, either within iOS, via MDM, or otherwise to purposefully prevent an iOS update. We have seen two common methodologies used by our customers.

Ask Users to Delay Updating

Send an announcement to all staff requesting that they hold off from updating their devices. iOS will always prompt users before it begins an update and a user can prevent the device from updating by denying the prompt. The most effective company announcements generally disclose the concerns of updating early, including the potential incompatibilities with business-related apps. This helps staff understand how an early update may negatively affect them and aligns them with the interests of the company.

Block the Update Servers

Blocking communication with the Apple update servers at the company network level may also help prevent updates. By disallowing traffic to the update servers on the company network, devices will be unable to update themselves. The pitfall of this methodology is that the device will be able to update itself if it joins a different WiFi network or has a cellular connection.

The two update servers that we are aware of are: appldnld.apple.com and mesu.apple.com.

Is Delaying an Update Recommended?

In short: it’s a double edged sword. On one hand, delaying the release of an iOS update can prevent a situation where users are not able to use apps they depend on due to software incompatibilities. On the other hand, it can leave devices with outdated versions of iOS which may have publicly known security vulnerabilities, exposing your organization to much greater risks.

One thing to consider when making a decision to upgrade or not is what the specific upgrade is for. If it’s a minor update, for instance an update from 9.3.2 to 9.3.5, it likely contains security fixes. It also is unlikely to have any incompatibilities with existing apps. If the update is a major one, for instance 9.3.5 to 10.0.1, there will be a higher risk of finding incompatibilities with apps.

Planning for the Future

Ideally, your organization is ready for iOS updates on the day of their release and can avoid having to delay updating altogether. Apple makes the GM (the version slated for public release) of major iOS updates available before the release date, often a week or more in advance, and these versions can be tested by IT beforehand.

Introducing Managed App Configurations

$
0
0

screen-shot-2016-09-19-at-10-30-23-am

SimpleMDM now includes support for managed app configurations. This feature allows a SimpleMDM administrator to specify the configuration file provided when an app is pushed to a device. This is useful for apps that support this functionality.

Examples of apps that support managed app configurations are Box, Concur, and Kiosk Pro. Kiosk Pro, for instance, allows an administrator to specify the homepage, idle time, and whether the status bar is present all from the SimpleMDM web interface. An incomplete list of apps that support managed app configurations is available at appconfig.org.

As configurations often must vary between devices, we’ve included variable support. Instead of specifying a fixed value in the configuration that will be shared with all of your devices, you may instead specify a variable that will be replaced with a device-specific value when the app is deployed.

Some of the currently supported variables are:

  • ICCID
  • IMEI
  • MEID
  • Model
  • Phone number
  • Serial number
  • UDID
  • WiFi MAC address

To access managed app configurations, visit the “Managed Configuration” tab under App details.

Don’t have a SimpleMDM account? Sign up instantly and manage up to 5 devices for free.

 

Block/Hide Any iOS App

$
0
0

SimpleMDM allows you to block and hide iOS apps, including system apps, from the iOS home screen.

App restrictions allow you to build either a blacklist of apps not to be shown or run on the device, or a whitelist of apps allowing only the apps listed to appear on the device. This provides the capability to either block just a few specific apps or only show a designated list of apps.

Administrators currently using the single app lock feature (or, guided access) may find the ability to restrict app usage as a suitable replacement in cases where more than one app needs to be made accessible.

This functionality is available today on all supervised iOS devices running iOS 9.3 and later. Want to try it out but don’t have a SimpleMDM account? Create an account and enroll your first 5 devices for free.

Introducing macOS Application Support

$
0
0

featured-content-sierra-roundel_2x

SimpleMDM now supports the installation of applications to macOS managed devices, over the air. SimpleMDM utilizes the Apple Volume Purchase Program (VPP) to support licensing and deployment of macOS applications.

If you already have an Apple VPP account tied to your SimpleMDM account, macOS licensed apps will appear in your app catalog today. If you do not yet have a SimpleMDM account, you may sign up for an account and manage your first five devices for free.

Note: While we use the terminology “macOS”, SimpleMDM also supports older versions of the Mac operating system, such as OS X 10.11 El Capitan.


Explained: InstallEnterpriseApplication MDM Command

$
0
0

MacOS 10.13.6 adds the new MDM verb InstallEnterpriseApplication. What does it do, how does it differ from the preexisting InstallApplication verb, and why does it matter? We explain below.

What’s It Do?

InstallEnterpriseApplication is an Apple MDM command that provides support for installing software packages to macOS computers. More narrowly defined, it allows for the delivery of developer signed distribution-style packages, or PKGs. It is a useful function for admins who wish to deploy software like Munki, NoMAD, Crypt, Chef, Puppet, or similar. More on this is available in our Munki Deployment Using Apple DEP and MDM and Popular Open Source Tools for Mac Admins articles.

InstallEnterpriseApplication is an MDM protocol-level function, so unless you are an MDM developer or working with an open source MDM, you will not work with it directly. It is worth understanding, however, as not all MDM providers implement it. Many MDM providers require that their own software is installed on the macOS endpoint before any other software can be delivered. Their software acts as the delivery mechanism for your own packages. Since InstallEnterpriseApplication allows for package installation on the MDM protocol level, providers that implement it will not require additional client software.

Wait, Isn’t This Just InstallApplication?

InstallEnterpriseApplication is very similar to InstallApplication, which has been in existence for some time. InstallApplication is a much broader command and is used for installing App Store Apps, Enterprise iOS apps, and macOS packages. InstallEnterpriseApplication is intended to replace the macOS package installation functionality of InstallApplication and adds additional security options.

When an installation command is sent to a device, it includes a manifest. The manifest is a document that provides information about the package that is to be installed, such as its name, a download URL, and a checksum that the device can use later to validate the integrity of the downloaded file. The InstallApplication command provides a URL for the device to download the manifest from. InstallEnterpriseApplication adds two options:

  1. Certificate pinning: The MDM command can specify the public key that the web server hosting the manifest must be using.
  2. In-band delivery: The manifest can be specified in the InstallEnterpriseApplication command itself.

Why Does This Matter?

InstallApplication required devices to contact a web server to fetch the manifest file. Since this web server was outside of the MDM communication channel, it required vendor-brewed security measures to limit access to the manifest file. If a manifest URL or URL formatting pattern was discovered and had poor security mechanisms, outside parties could, in theory, review and download the software of an organization.

Additionally, since InstallApplication did not support certificate pinning, devices were more susceptible to a man-in-the-middle attack when fetching the manifest file.

By contrast, InstallEnterpriseApplication’s in-band manifest delivery option is significantly more secure. Only enrolled MDM devices can retrieve the manifest file and the transmission occurs over the already-secured MDM communications channel. If a manifest URL is specified instead, certificate pinning optionally provides a bit more protection.

When Will This Feature Be Available?

SimpleMDM supports InstallEnterpriseApplication today. Any packages delivered to devices running macOS version 10.13.6 and later will receive an InstallEnterpriseApplication MDM command. Earlier versions of macOS will continue to receive the InstallApplication command for backwards compatibility.

The post Explained: InstallEnterpriseApplication MDM Command appeared first on SimpleMDM.

What is the Apple Volume Purchase Program (Apple VPP)?

$
0
0

The Apple Volume Purchase Program (VPP) is a free Apple service offered by Apple to businesses and organizations. The purpose of VPP is to simplify the process of purchasing and distributing apps. In this article, we will discuss the features this program has to offer and how it can benefit your deployment.

Purchasing Licenses

In the past, an employee using a company-owned device had to purchase apps through the App Store manually from the device itself. This often meant that employees had to pay for apps themselves and be reimbursed, which meant extra time and effort for both administrators and the device users. It also permanently associated the license with the employees Apple ID, making the employee the owner of the license and not the company.

The Volume Purchase Program simplifies this process by allowing businesses to purchase app licenses en masse for all users from a single company account. These licenses are then owned by the company and not the user whose Apple ID it was purchased with. VPP also provides multiple payment options: licenses can be purchased at the time of the order with a credit card, or a specific amount of VPP credit can be paid for by purchase order to be redeemed later.

License Assignment & Managing Apple IDs

Prior to VPP, users had to enter their Apple ID credentials in order to install an app, at which point that user was given ownership of the license. For businesses, a common solution was to create a single Apple ID and distribute the credentials to their users. This solution had its own complications. For example, any user with the company’s credentials could login to the Apple ID account and make undesirable changes, or if the password was reset, all users would need to be notified. It also violated Apple Terms of Service, as using a single Apple ID allowed a company to share a single app license with all of their employees.

Since VPP app licenses are owned by the company, licenses can be assigned, revoked and re-assigned to users or devices at any time. This eliminates the need for a shared Apple ID account, and, if desired, the need for an employee to use an Apple ID on the device at all.

Device-Based Assignment

With device-based assignment, app licenses are assigned to a device by serial number rather than to an Apple ID. One license will be allocated for each device the app is installed on. With this method, apps will remain on devices regardless of the Apple ID in use, if any. On supervised iOS devices, this method allows apps to be installed without prompting or notifying the user. Businesses looking for a zero-touch deployment process will find this to be particularly beneficial.

User-Based Assignment

When VPP apps are deployed with user-based assignment, device users will be prompted to enter an Apple ID if one is not already present on the device and be invited to join the VPP program of the company. While this requires more user interaction than device-based licensing, it is useful in situations where a single user will be utilizing multiple devices. The app license is usable on all devices that are using the Apple ID. As a result, only one license will be allocated from the total number available in the VPP account.

Redemption Codes

App licenses can be distributed to Apple IDs using redemption codes, where a code can be redeemed once by an Apple ID for a particular app license. Users will be prompted to enter a code in order to redeem the purchase and complete the installation of the app. After entering the redemption code, ownership of the app license is transferred permanently to that user ID.

These codes are delivered in a spreadsheet format and can be distributed to users through various methods, including: assigning them via SimpleMDM, sending a URL by email, assigning to devices through Apple Configurator, or providing codes to users manually. When used with SimpleMDM, SimpleMDM will automatically redeem the codes for users when apps are installed.

Custom Apps for Business & B2B VPP App Store

The Apple B2B VPP program allows app developers to distribute their apps to specific VPP accounts of their clients instead of using the public App Store. This is particularly useful for third-party app developers because it allows them to control who has access to download their app. For example, if an app developer has been contracted to build an app that is intended only for internal use within their customers’ business, the developer can publish it so only that customer can access it.

Since these apps are not visible to the public, Apple’s approval process for publishing B2B apps is more lenient than it is for the public App Store.

B2B App Store apps can be offered for free or as paid apps.

For more information on the different methods of distributing a business app, read How To Deploy Custom iOS Apps For Businesses.

MDM Integration

Apple VPP accounts can be connected to SimpleMDM to easily distribute apps to managed devices. When VPP apps are deployed via SimpleMDM, licensing is handled automatically and app installations can happen immediately. A significant advantage offered by utilizing VPP with MDM is the ability to “silently” install and update apps on devices remotely via MDM, without requiring any interaction from the user. We have written an article on this topic which can be found here: Install iOS Apps Silently.

SimpleMDM administrators have the option to select the method of license assignment, as described below, when deploying apps. App licenses can also be revoked and re-assigned remotely through the interface.

Availability

Apple is regularly expanding the availability of the Volume Purchase Program to new countries. A complete list of countries that VPP is available in can be found under the “Availability” section of this article from Apple’s documentation.

Getting Started

Organizations can obtain a VPP account through Apple Business Manager. These steps may include but are not limited to: creating an agent account associated with your organization email address, establishing an authority contact within your organization, providing business information such as company address and D-U-N-S number, and agreeing to Apple’s terms and conditions.

To get started, visit the Apple Business Manager website.

The post What is the Apple Volume Purchase Program (Apple VPP)? appeared first on SimpleMDM.

Avoid Kernel Extension and TCC / Access Control issues during macOS Updates

$
0
0

Deploying Kernel Extension or Privacy Preferences Policy Control profiles to your macOS devices? Read this article to ensure that these configurations are available immediately upon OS update.

When upgrading macOS, some previously installed configuration profiles may become effectively ignored. This article explains the behavior, the reason for it, and how we’ve designed SimpleMDM so that our customers can avoid this pitfall in their deployment.

Kernel Extensions and High Sierra

Starting with High Sierra 10.13.2, Apple introduced the concept of Secure Kernel Extension Loading (SKEL). SKEL is a macOS service that acts as a security gatekeeper, only allowing the execution of third party kernel extensions that have been pre-approved. Kernel extensions can be approved by the user interactively or can be whitelisted by a SimpleMDM administrator via configuration profile. You can read more about kernel extension whitelists in our article What is User Approved MDM Enrollment? by scrolling to the section entitled “How do I Whitelist Kernel Extensions with SimpleMDM?”.

The kernel extension configuration profile, however, does not act as the source of truth on a macOS instance. Rather, when the profile is installed, the configuration is imported to a separate local database called the System Policy Configuration – Kext Policy (KPDB). macOS refers to this database when deciding if a kernel extension is entitled to run or not. This causes a complication in the following scenario:

  1. Computer running macOS Sierra 10.12 receives and installs kernel extension profile. The profile is installed, but the whitelist is not imported into the KPDB as it does not exist in this version of macOS.
  2. Computer is updated to macOS High Sierra 10.13.2 or later. The profile remains installed, however macOS does not import the whitelist data to the KPDB.
  3. When trying to run software or automated processes after update, the whitelist in the configuration profile is not honored and either prompt the user, or worse, fail.

This issue can be difficult to debug. macOS shows a valid kernel extension configuration profile installed, however, the settings in the profile are not actually being honored.

So, why not wait to install the profile once 10.13.2 is detected? While this avoids the problem of installing a profile that macOS cannot yet process, it does not ensure that the profile is available immediately upon OS update. We will address this issue in a moment.

TCC / Access Controls / Privacy Preferences Policy Control and Mojave

macOS Mojave (10.14) introduces a gatekeeper for gaining access to cross-application data like Contacts, Calendar, and Photos, hardware like the camera and microphone, and important system files. This gatekeeper is a similar paradigm to the gatekeeper used for kernel extensions. Likewise, it has a separate database for tracking approved access. Despite this functionality still being in beta, Apple has publicly announced the change to provide a heads up for system administrators.

While it is still yet to be seen, the same issue exhibited with kernel extension profiles and OS updates may apply here as well. For instance, if a TCC whitelist profile is installed to an instance of macOS High Sierra 10.13.6 and then upgraded to Mojave 10.14, the profile may essentially be useless despite remaining installed.

How Does SimpleMDM Fix This?

In order to “reactivate” a profile, it must be reinstalled on the device. When SimpleMDM detects that the installed OS has updated, it will automatically reinstall any profiles that may be affected by an OS update. SimpleMDM is able to check for an OS update each time the device checks in for an inventory update.

However, a problem of timing still exists. macOS does not notify SimpleMDM, natively, when an update has occurred. This can cause a gap in time between an OS update and when the profiles become active. This introduces two problems:

  1. A user’s first experiences using the new OS is confusing when they can’t run their desired application, a new, unfamiliar permissions prompt appears, or some element of the application is rendered inoperable.
  2. An automated software install, intended to run after OS update, is not able to run.

To solve this problem, a script may be installed to the device that notifies the SimpleMDM service when an OS update is occurring. With this script installed, SimpleMDM will automatically reinstall any necessary profiles during the OS update process, before the login screen is displayed for the first time. Thus, subsequent automated processes and user interactions are not affected by inactive profiles.

If you are a SimpleMDM customer and would like to utilize the script in your deployment, please contact support. We have a packaged version that can be automatically deployed to your fleet using SimpleMDM.

The post Avoid Kernel Extension and TCC / Access Control issues during macOS Updates appeared first on SimpleMDM.

How To Use Custom Configuration Profiles With Custom Attributes

$
0
0

Configuration profiles are a primary building block of mobile device management. Taking the form of an XML property-list file, these profiles allow you to remotely apply profiles to devices that can be used to configure specific settings, enforce restrictions, set up preferences, and much more.no

Many of these profiles can be created quickly using features already available through the SimpleMDM interface. However, some situations may require the flexibility for a custom implementation. For this reason, SimpleMDM includes support for Custom Configuration Profiles. This allows admins to upload their own profiles and edit them within the SimpleMDM interface using a built-in text editor. Custom Attributes can also be inserted into these profiles which provides the ability to inject variable values on a group-level and/or device-level basis.

In this guide, we will walk you through how to use a Custom Configuration Profile and Custom Attributes to specify profile values for individual devices and groups of devices.

Goal of this Guide

Our objective in this tutorial is to display a custom message on the user login screen for macOS devices with the custom “Loginwindow” configuration profile.

As an aside, there are a couple good resources to check first when looking for references of available configuration profiles. One is within Apple’s Configuration Profile Reference. Additionally, the profile docs guide maintained by the MacAdmins community is another great resource.

For our walkthrough, we will assume that you already have a profile (“.mobileconfig” file) available to you – we won’t be covering the steps for creating the initial profile. There are many different sources for creating or obtaining configuration profiles, including but not limited to: Apple Configurator, ProfileCreator, or creating it manually using a text-editor. The MacAdmins documentation above also has links to download generic profile templates.

If you want to follow along with our specific example, you can copy the code for the Loginwindow profile we will be using here:

<?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">
<dict>
	<key>PayloadContent</key>
	<array>
		<dict>
		    <key>LoginwindowText</key>
		    <string></string>
			<key>PayloadDescription</key>
			<string>Configures Loginwindow settings</string>
			<key>PayloadDisplayName</key>
			<string>Loginwindow</string>
			<key>PayloadIdentifier</key
			<string>com.github.erikberglund.ProfileCreator.729A188D-D90A-430F-8B4E-24133EDC6E76.com.apple.loginwindow.FD61E78F-B806-4ADD-B328-F0F4580F3809</string>
			<key>PayloadOrganization</key>
			<string>SimpleMDM</string>
			<key>PayloadType</key>
			<string>com.apple.loginwindow</string>
			<key>PayloadUUID</key>
			<string>FD61E78F-B806-4ADD-B328-F0F4580F3809</string>
			<key>PayloadVersion</key>
			<integer>1</integer>
		</dict>
	</array>
	<key>PayloadDescription</key>
	<string>Sets text on login window.</string>
	<key>PayloadDisplayName</key>
	<string>LoginWindow</string>
	<key>PayloadIdentifier</key>
	<string>com.github.erikberglund.ProfileCreator.729A188D-D90A-430F-8B4E-24133EDC6E76</string>
	<key>PayloadOrganization</key>
	<string>ProfileCreator</string>
	<key>PayloadScope</key>
	<string>User</string>
	<key>PayloadType</key>
	<string>Configuration</string>
	<key>PayloadUUID</key>
	<string>729A188D-D90A-430F-8B4E-24133EDC6E76</string>
	<key>PayloadVersion</key>
	<integer>1</integer>
</dict>
</plist>

Creating a Custom Configuration Profile in SimpleMDM

The first part of this process is to add the profile to SimpleMDM. From the Profiles page, click the “Add Profile” button, and then select “Custom Configuration Profile” from the list. On the Custom Configuration Profile settings screen, give the profile a relevant name.

The next step is to add the .mobileconfig – there are two ways to do this:

  1. Next to the “Mobileconfig” field, click “Choose File” and follow the prompts to upload your .mobileconfig from your computer.
  2. Copy and paste the code from your profile into the text-editor field (if you are feeling particularly ambitious, you can type it in manually as well).

Next, we will check both boxes located below the text editor. The first box, “For macOS devices, deploy as a device profile instead of a user profile”, tells MDM whether to install the profile so it applies to the whole system or just to enrolled user accounts. For this example, we want this profile to be applied at the device level. The second box, “Enable attribute support”, will be necessary for steps covered later in this walkthrough.

After adding the profile and checking both boxes, click “Save”. If SimpleMDM detects an issue with the profile contents that would make it invalid, an error message will appear on the profile settings page. If you see this, be sure to check for typos, required keys that might be missing, syntax errors, or other similar issues.

Once the profile has been saved successfully, you have a working custom configuration profile that can be deployed to devices. To deploy the profile, assign it to your device groups as needed by checking the box next to the profile name on the Device Group Details page.

Even though the profile has been deployed to devices, you shouldn’t see any change at this point because we haven’t edited the profile to set the login window text. We will do that now.

Navigate back to Configs > Profiles and click the custom profile name. You should see the XML code from the profile showing in the text editor. Locate the following piece of code in text editor:

This is where we will set the message displayed on the login window. We’ll start by setting this value for all devices with this profile installed. In the text editor, type a new value in between the <string> tags:

<key>LoginwindowText</key>
<string>Property of Example Co.</string>

The profile should be updated on your devices shortly after saving the changes made in the editor. You may need to log in / out to refresh the screen and display the new message.

Adding Attributes & Custom Attributes

Let’s say that you want to have your Macs to display their serial number on the login screen for your admins to easily reference. This can be accomplished by using the “serial_number” attribute, which is one of several attributes supported by default. Edit the configuration profile XML like before, except instead of adding the value you want to display directly, enter the attribute name using the following syntax:

<key>LoginwindowText</key>
<string>{{serial_number}}</string>

You should now see the device serial number appear when logging in and out.

Assigning Values at the Group Level

Note: We will not be covering the full process for creating custom attributes since we have included these steps in previous articles. If you aren’t already familiar with them, you may refer the “Setup: Custom Attributes” section of this blog article as well as this article from our Knowledge Base for guidance.

Going further, let’s assume that all your devices are grouped based on the department they belong to within your organization, and you want your devices to display both their serial number and the name of the department.

Create a custom attribute – we’ll call it “department_name” – under the Attributes section in the SimpleMDM interface. In the Group Details page for each of your groups, click the “Settings” tab and enter the corresponding values you want to use for “department_name”. For example, enter “Marketing Department” for a marketing group, “Engineering Team” for an engineering group, etc.

Update your configuration profile similar to the following:

<key>LoginwindowText</key>
<string>{{serial_number}} - {{department_name}}</string>

Your devices should now display new messages corresponding to the group-level attribute value, such as:

C012ACME902P – Marketing Department

Assigning Values at the Device Level

Finally, if we want to be even more specific and include the device user’s name in this message, we can do this by repeating a similar process except we will set the attribute value at the device level instead of the group level.

Create another attribute such as “device_user_name”. Assign these values for individual devices in the corresponding field under the “Settings” tab of the Device Details page. Then update the configuration profile:

<key>LoginwindowText</key>
<string>{{serial_number}} - {{device_user_name}} - {{department_name}}</string>

Your results should look similar this:

C012ACME902P – Gretchen – Marketing Department

Going Further

There is a wide range of tasks and solutions that can be accomplished using custom configuration profiles and custom attributes. This walkthrough was meant to introduce a fairly simple solution for demonstration purposes, but there are a number of possibilities that exist with varying levels of complexity.

More advanced users might find that this sort of implementation could be an effective strategy for tasks such as setting up Munki profiles and enabling firewall configurations, amongst many others.

The post How To Use Custom Configuration Profiles With Custom Attributes appeared first on SimpleMDM.

How To Sign macOS PKGs for Deployment with MDM

$
0
0

We have written previously about how to distribute macOS PKGs with MDM. To review, Apple MDM has certain requirements for deploying macOS PKGs:

  1. The package is built as a product archive.
  2. The .PKG file must be signed using “Developer ID Installer” certificate, obtained from an Apple Developer account.

This article will cover how to fulfill the latter of those requirements. We will discuss some of the different methods available for signing macOS packages for distribution via MDM.

Getting Started

In order to sign macOS packages, you will need access to an Apple Developer account. If you don’t have one already, you can start the signup process on Apple’s website.

The Apple Developer account is required for generating signing certificates. Certificates can be generated by linking your Developer account to Xcode and exporting the certificate file from Xcode, or you can log in to your Apple Developer account online and download the certificate through a web browser.

When creating the certificate, be sure to select the certificate type as a “Developer ID Installer” certificate. Verify that it is saved to your macOS Keychain.

Once you have your certificate, there are a few different ways to sign the macOS PKG.

Signing PKGs with Terminal / Command Line

For this example, we will use the “productsign” command.

First, open Keychain Access within macOS and locate the certificate. The name of the certificate should start with “Developer ID Installer:”, followed by your Apple Developer account name, and ending with some serial number in parenthesis – take note of this information.

Next, open Terminal. The command to sign the package should look similar to this:

productsign --sign “Developer ID Installer: Your Developer Name (1A2B3C4D5E)” ~/Desktop/example.pkg ~/Desktop/signed-example.pkg

The value in quotes following the “–sign” tag should be the Common Name of your certificate. The first argument (‘~/Desktop/example.pkg’) is the current location on your computer of the unsigned package. The second argument (‘~/Desktop/signed-example.pkg’) is the destination that you want to save your signed package.

Then, run the command. If it is successful, you should see something similar to the following printed out in Terminal:

productsign: using timestamp authority for signature
productsign: signing product with identity "Developer ID Installer: Your Developer Name (1A2B3C4D5E)" from keychain /Users/sdeveloper/Library/Keychains/login.keychain-db
productsign: adding certificate "Developer ID Certification Authority"
productsign: adding certificate "Apple Root CA"
productsign: Wrote signed product archive to /Users/sdeveloper/Downloads/munkitools_signed-3.2.0.3476.pkg

Verify that the signed package is located at the destination you specified.

Signing Using Xcode

If you are developing your macOS PKG in Xcode and have an Apple Developer account linked to it, Xcode can automatically request a certificate from your Developer account and add it to the signing certificate to the package during the build and archive stages. We recommend referring to Apple’s documentation for more detailed instructions on this process.

When using this method, verify that you have selected “Developer ID Installer” from the dropdown list for the ‘Signing Certificate’ setting. This is located under the Signing section of the General settings tab.

Third-Party Tools

In addition to the manual methods we’ve mentioned, there are third-party tools that exist to help with the process of signing packages. One open-source solution we will look at it is called Hancock. This tool retrieves certificates saved in your computer’s Keychain and provides a GUI to easily sign your packages.

The first step is to download and install the Hancock app to your computer. Links to download the installer can be found in the releases section of the Hancock GitHub site.

When the Hancock app has finished installing, run the app. In the app window, a dropdown list will be shown with names of any certificates saved to your Keychain – select your “Developer ID Installer” certificate here. Click “Sign” and select the package file that you want to sign. You will then be prompted to allow access to your Keychain – accept this prompt. Finally, choose the location on your computer where you want to save the signed package.

Distributing the Package

Any of these methods will allow you to adequately sign a macOS PKG for distribution with MDM. Once complete, you can upload the .pkg file to SimpleMDM and deploy it to your Macs. For guidance with this process, you may refer to the walkthrough at the bottom of our previous article: Distribute macOS PKGs via MDM.

 

The post How To Sign macOS PKGs for Deployment with MDM appeared first on SimpleMDM.

Customer Spotlight: Tom Bridge’s macOS Deployment Playbook

$
0
0

This is the first article in our Customer Spotlight series. The goal of this series is to take a closer look at the unique strategies that our customers are using for their deployments, and in doing so, provide insight into the different ways that Apple Admins are solving common problems.

Who is Tom Bridge?

Tom Bridge is a partner at Technolutionary, Inc, where he acts as an Apple IT consultant and Mac administrator. Tom is also the producer and host of the MacAdmins.org Podcast and is a regular conference speaker at MacDevOps YVR, Penn State Mac Admins, MacADUK, MacTech, and MacDeploy conferences. 

Tom manages numerous customer deployments with SimpleMDM. We are honored that he was willing to share his strategy for this article. Thanks, Tom!

Tom’s Goals

  • A macOS deployment workflow with minimal end-user and administrator interaction
  • Keep users well-informed about the magic happening behind the scenes and what to expect
  • Provide the user with clear guidance on what steps must be taken
  • Minimize security risks and administrative costs
  • “Good technical solutions paired with good human solutions”

Tools Used

It Starts with Something Tangible

The initial step of the Technolutionary’s deployment workflow comes even before devices are activated. Prior to being handed over to their eventual user, a printed introductory guide is included with the computer. It explains exactly what the user should expect after activating their device, includes detailed instructions on the aspects of the deployment that require their interaction, and provides information for who they can contact if they encounter difficulties. This step is significant for Technolutionary because it demonstrates how they are able to align with their goal of “good technical solutions paired with good human solutions”.

Apple DEP and User Account Setup

Once devices are activated, they proceed to check in with Apple DEP and, as a result, enroll with SimpleMDM. The DEP settings are configured to skip a few Setup Assistant screens, but Technolutionary allows users to see most of these panes and choose their own configurations. In addition, the DEP configuration is set up to automatically create a local admin account, prompt the user to create their own local admin account, and assign the device to a specific, initial device group within SimpleMDM. The only initial configuration profile this group applies via MDM is the FileVault profile – this forces the user to enable FileVault after a certain number of logins and escrows the key to SimpleMDM.

Wiring Munki + AWS CloudFront, JumpCloud, and More

Though this initial group may not always be the device’s end destination, it plays another vital role in the deployment process. Through this group, the InstallApplications package is deployed to the device via the ‘InstallEnterpriseApplication’ command during enrollment. When used as this initial package, InstallApplications can be used to run scripts preflight (before reaching the Setup Assistant screens), and to install many other configurations and applications during the Setup Assistant phase and/or at the time of user account creation.

In the case of this deployment, the InstallApplications package downloads a JSON file hosted on a Technolutionary web server. This JSON file instructs InstallApplications to download and install a handful of packages during the Setup Assistant phase. Amongst them are an install script for JumpCloud, a Munki-Cloudfront package, the various required Munki-tools packages, and the DEPNotify package.

The signed Munki-Cloudfront package is particularly noteworthy. Technolutionary’s Munki repository is hosted on an AWS CloudFront CDN, and this package installs the verification keys necessary for devices to access the Munki repo. This acts as a security layer to prevent unwanted devices from accessing the contents of the Munki repo. It also helps minimize hosting costs and aids in tracking abilities.

Providing the User with Feedback Using DEPNotify

InstallApplications also writes a configuration for DEPNotify that tells it what to do next. It is at this point that InstallApplications hands off to DEPNotify to take over the rest of the process. After the end-user has completed the Setup Assistant panes and has logged in, DEPNotify launches a window from the Technolutionary website that provides details to the user about what is going to happen and instructions on what steps to take. The first step is to download and install the Managed Software Center. Once installed, the user is prompted to click “Next Step” to complete a series of additional tasks, such as ensuring that LastPass and other software has been installed successfully, they have logged in to G Suite and changed their password, and signed in to Slack.

Once all of these steps have been completed, the user is informed that their machine setup is finished and they are all set. In some cases, this is the last step. In others, admins may re-assign the device to a new group within SimpleMDM to apply other configurations and install additional applications. Tom mentioned that they may be looking to automate this process even further by utilizing the SimpleMDM API to check which group a device belongs in and have it re-assigned to that group automatically.

Have a question about this deployment? Leave a comment below and we’ll do our best to address it.

The post Customer Spotlight: Tom Bridge’s macOS Deployment Playbook appeared first on SimpleMDM.

Customer Spotlight: How Unbounce, Inc. Onboards Their macOS Fleet

$
0
0

This is the second article in our Customer Spotlight series on macOS. The goal of this series is to take a closer look at the unique strategies some of our customers are using for their Mac deployments and to provide insight into the different ways that Mac Admins are solving common problems.

Tim Fitzgerald of Unbounce, Inc.

Since 2009, Unbounce has helped marketers and digital agencies increase website and campaign conversions. Unbounce’s landing page and conversion marketing platform allow marketers to quickly create, launch and test high-converting landing pages, popups, and sticky bars without developers. With unrivaled customer support, global hosting and 99.95% server uptime, Unbounce has powered over 250 million conversions for marketers around the world.

Tim Fitzgerald is a Systems Administrator at Unbounce. He is responsible for developing and managing Unbounce’s macOS deployment for a rapidly growing user base, which currently consists of multiple office locations and a number of remote employees. Tim’s guidance and skills have been instrumental in successfully moving Unbounce’s deployment onto MDM as well as implementing and maintaining their Munki infrastructure.

Tim’s Goals

  • A fast, secure, and touchless deployment process
  • An end-result that provides users immediately with all the software and accounts they need
  • The ability to reliably deploy Macs for remote employees without the need for an on-site technician

Tools Used

Unboxing to Enrollment

Like many others, Tim’s goal for his macOS deployment is to set up devices quickly and with as little end-user interaction as possible. The deployment process starts with devices being enrolled using Apple DEP as soon as they are unboxed and activated. As specified by the DEP enrollment settings, many of the initial Setup Assistant panes are skipped, a local administrator account is created automatically and hidden from other local user accounts, and the end user is prompted to interactively create an administrator account.

Bootstrapping Configurations & Software

During the enrollment via DEP, devices are assigned to a “bootstrap” device group, which applies an initial Munki configuration profile, a wireless network profile, and installs the InstallApplications package.

The InstallApplications package installs a variety of items during the Setup Assistant stage, including Munki tools, an AWS CloudFront Middleware package, certificates, and a DEPNotify package. The certificates are used for authentication via CloudFront when accessing the Munki repository on AWS. This CloudFront Middleware provides an additional layer of security so that only MDM-enrolled devices can access the company’s Munki repo, as well as reduces potential costs by limiting the number of requests made to the AWS-hosted repository.

When the user account is created and the user logs in, the DEPNotify package runs a script to launch a DEPNotify window. This window includes Unbounce’s branding and a greeting message welcoming the user to Unbounce. This script reads from the Munki logs to retrieve information about package/application download statuses and then updates the DEPNotfiy window to keep the user informed about the setup progress. While this is happening, a second script runs that automatically configures the dock settings/icons. Upon completion, DEPNotify provides the user with contact information for the Unbounce IT team in case they have any questions or issues.

Role-Specific Device Configuration

At this point, the main bootstrapping process is finished. From here, an MDM administrator will assign the device to its destination device group which is determined based on who will be using the Mac. This group then assigns a variety of additional configuration profiles, including a FileVault profile, Passcode Policy profile, a custom configuration to enforce ‘Always-On’ Firewall, a custom Energy Saver configuration, and a second Munki configuration based on which department the device will be used in. This second Munki profile specifies which additional software will be installed via Munki – for example, Mac assigned to developers will receive development-specific apps/software, designers will receive their design software, etc.

Upon completion, the machine is prepped and ready for the employee to start working on immediately, with all the software they need to complete their job tasks.

Have a question about this deployment? Leave a comment below and we’ll do our best to address it.

The post Customer Spotlight: How Unbounce, Inc. Onboards Their macOS Fleet appeared first on SimpleMDM.


Customer Spotlight: XING’s Move To SimpleMDM

$
0
0

The goal of our Customer Spotlight series is to share the unique strategies our customers are using for their Mac deployments and to provide insight into the different ways that Mac Admins are solving common problems.

David Schöfberger & Christopher Maack of XING SE

XING SE is a premier social network company that focuses on business networking, career search, and other business/career-related services. XING was founded in 2003 in Hamburg, Germany and currently has over 1500 employees and serves upwards of 15 million members, primarily in Europe.

David and Christopher are both IT System Administrators at XING, located in Vienna and Hamburg respectively. Together they are responsible for the management of in-house Macs and many more iOS devices. David was nice enough to share XING’s internal processes and configurations currently being used.

David Schöfberger
Christopher Maack

Their Goals

  • Migrate from an older system that required many manual processes to a more scalable, automated solution
  • Unify the deployment system across all company locations
  • Reduce the time necessary to deploy/configure a new Mac

Tools Used

The Move To SimpleMDM

David and Christopher were in search of a future-proof solution that they could deploy across multiple locations. When they came across SimpleMDM, they were confident that it could effectively manage a large number of Mac and iOS devices in a unified manner.

Though working towards a touchless deployment, XING currently involves an on-site IT technician in the setup process to handle a few quick tasks for reasons relating to macOS reliability, such as ensuring FileVault encryption was successful. XING plans to move toward a zero-touch deployment in time.

From Purchase To User Delivery

XING purchases Macs from their vendor, who is responsible for adding the devices to their DEP account. Once the Macs are received, they are unboxed, connected to the internet, and activated using DEP. The technician proceeds through the DEP-customized Setup Assistant screens and the device is enrolled into it a default device group. This group only applies a few basic profiles and certificates.

After the initial enrollment is complete, the technician renames the device and re-assigns it to the destination group via the SimpleMDM interface. The destination group applies additional configuration profiles, some of which are based on the office location and employee’s role. The native profiles include:

  • FileVault profile
  • Firmware Password profile
  • Privacy Preferences profile to automatically configure permissions for certain software
  • Kernel Extensions profile to automatically permit certain kernel extensions

Several custom configuration profiles are also applied via the destination group:

  • Region-specific Active Directory profiles for binding accounts. this allows users to log in with known credentials.
  • One or more profiles for each required Munki catalog.
  • A profile to configure the Dock on macOS.
  • A Google Chrome profile that enables integrated authentication with a web proxy.
  • A Login Window profile that hides the “Guest” login option and displays the full name of user accounts.

When the login window is displayed, the technician logs in to the admin account that was auto-created during enrollment with DEP. They confirm that Munki – Managed Software Center is installed and showing in the Dock. The technician then logs out of the admin account, is prompted to enable FileVault and does so, then reboots the device. The reboot kicks off a script that runs to ensure the Managed Software Center automatically installs all required software. After logging out of the admin account, the option to log in with an Active Directory user is shown. They log in to Active Director with new user credentials and set the secure token for FileVault. The device is then passed off to the user. After logging in, the user can reset their own password for the account.

Prior to using SimpleMDM, David states that the deployment process took more than 30 minutes. With SimpleMDM, the time has been cut down to less than 10.

API & Webhook Integrations

David and Christopher have created a handful of custom integrations. To help with their migration process onto SimpleMDM, they used a script deployed via Munki to check if the SimpleMDM management profile was installed on their Macs, and if one was not present, Munki would install the enrollment profile which added the device to their default group.

Additionally, David and Christopher use the SimpleMDM API to send information to Nagios and Icinga, the internal systems they use for reporting. These integrations allow them to: check for certificate expiration dates and send notifications, monitor their usage of device licenses in MDM, and ensuring their users’ Macs are assigned to the appropriate device groups.

David and Christopher are also writing integrations that utilize SimpleMDM’s webhooks to send custom notifications based on events, such as new device enrollments. These integrations help their device administrators keep a closer eye on their deployment and stay on top of any potential issues before they arise.

Have a question about this deployment? Leave a comment below and we’ll do our best to address it.

The post Customer Spotlight: XING’s Move To SimpleMDM appeared first on SimpleMDM.

How to Enroll an Apple TV in MDM – 4 Methods

$
0
0

The integration of Apple TVs into non-consumer environments has grown considerably in recent years, serving varying roles across many industries. Common use-cases include conference room displays, learning tools in school environments, wall-mounted dashboards for corporate environments, and much more. As a result, the need to manage Apple TVs remotely with an MDM has increased similarly. Recent Apple tvOS updates have included support for significantly more remote management capabilities.

The enrollment process for tvOS, which runs on Apple TV, is slightly different than for iOS. In this article, we will discuss the different ways that Apple TVs can be enrolled in SimpleMDM, including the following methods:

  • Enrollment by link (manual enrollment)
  • Enrollment with Apple Configurator
  • Enrollment via the Apple Device Enrollment Program (DEP)
  • Provisional Apple DEP enrollment using Apple Configurator

Enrollment By Link (Manual Enrollment)

This method does not require any other accounts or technologies so it can be the fastest in some regards, but it is also the most limited because it does not enable Supervised mode or allow for automated enrollment.

Instructions

After completing the standard set up of the Apple TV, generate an enrollment URL in SimpleMDM.

On the Apple TV, navigate to Settings > General > Device Management and select ‘Add Profile’. Enter the full enrollment URL manually. Select ‘Done’ when finished.

Select ‘Install’ when prompted to confirm the profile installation. When prompted to confirm that the profile is trusted, select ‘Trust’. Select ‘Done’ to complete the enrollment.

Enrollment with Apple Configurator

Apple Configurator is a free app available in the Mac App Store so it will require the use of a Mac computer. This method is recommended if you do not have access to an Apple DEP account but still want to enable Supervised mode. The steps that take place within Apple Configurator are similar to the process for preparing and enrolling iOS devices.

Instructions

The first step is to connect your Apple TV to the internet via an ethernet cable and ensure that it is on the same LAN as your Mac computer.

Next, pair the Apple TV with your Mac via Apple Configurator. If the device has not yet been setup, turn it on and pause on the ‘Pair Your Remote’ screen. If it has already been setup, go to Settings > Remotes and Devices > Remote App and Devices.

Open Apple Configurator on your Mac. At the top of your screen, click the ‘Apple Configurator 2’ menu option and select ‘Paired Devices’ – the Apple TV should appear. Select the Apple TV and click “Pair”. A 6-digit code should appear on the Apple TV screen and you should see a prompt on your Mac – enter the 6-digit code here.

After pairing the devices successfully, the Apple TV should now be shown in Apple Configurator; select the Apple TV and click the “Prepare” button. On first “Prepare” screen in Configurator, we advise checking the boxes labeled “Supervise devices” and “Allow devices to pair with other computers”.

Do not check the “Add to Device Enrollment Program” box unless you want to enroll devices with Apple DEP / Business Manager – the steps for this will be covered later in this article. Click “Next” when you are done.

At this point, login to SimpleMDM and copy an existing group enrollment URL or generate a new enrollment URL and copy it. On the “Define an MDM server” screen in Apple Configurator, select “New Server”, enter a name, and paste the SimpleMDM enrollment URL into the “Host name or URL” field. Alternatively, you can select an existing server if you have already configured one for SimpleMDM.

On the next screen, select “*.simplemdm.com” and click “Next”. Enter your organization information as needed on the “Assign to Organization” page.

The following screen labeled “Configure tvOS Setup Assistant” allows you to select which setup options you want to show / skip during the initial device setup process. Configure these as desired and continue by clicking “Prepare”.

If the initial enrollment process in Apple Configurator was successful, a screen will be shown on the Apple TV asking if you want to apply the configuration. Accept this prompt to complete the enrollment and proceed with the setup.

Enrollment via Apple DEP

DEP enrollment provides the most functionality and automation of all the enrollment methods. You can read more about Apple DEP and its benefits here: Explained: The Apple Device Enrollment Program (Apple DEP)

This walkthrough assumes that your devices have already been registered in Apple DEP / Business Manager and that DEP / Business Manager is connected to SimpleMDM.

Instructions

First, in Apple DEP, assign the device to the server that you have connected to SimpleMDM. Then, in SimpleMDM, go to Settings > DEP and click ‘Sync with Apple’. To confirm the assignment and sync was successful, click the server name on the DEP Accounts page, click the ‘DEP Devices’ tab, and then verify the device’s serial number is appearing.

Once that is confirmed, connect Apple TV to the internet via ethernet and activate it. Within the initial Setup Assistant screens, select ‘Apply’ when prompted to apply the configuration to complete the enrollment. Then proceed through any remaining setup screens.

Provisional DEP enrollment using Apple Configurator

Apple Configurator also allows you to add devices to Apple DEP while enrolling them in MDM using Apple Configurator. The process is similar to the ‘Enrollment with Apple Configurator’ instructions mentioned earlier in this article, with a few additional steps.

On the “Prepare Devices” screen shown immediately after clicking ‘Prepare’, check the boxes labeled “Add to Device Enrollment Program” and “Activate and complete enrollment”.

After clicking “Next”, you will be prompted to sign in to the Apple Device Enrollment Program – enter your Apple DEP / Business Manager credentials here. Proceed through the remaining screens in Apple Configurator as needed, similar to what was discussed early in this article.

If you are using LDAP authentication for DEP enrollment, the screen shown in Apple Configurator prior to completing the preparation that will allow you to enter your authentication credentials. If you are not using LDAP, you can ignore this and click “Prepare”.

Tips & Troubleshooting

“This device has already been prepared” Message

During enrollment with Apple Configurator, you may be shown a warning prompt with a message similar to “this device has already been prepared”. To erase the device and complete the enrollment process, click “Erase”.

Trouble Pairing Apple TV with Apple Configurator

In our testing, we found that it was helpful to wait a few moments on the “Pair Your Remote” screen before attempting to pair an Apple TV with a Mac/Apple Configurator. We also noticed that it was best to avoid using the Apple TV remote after activating the Apple TV but prior to pairing the devices.

The post How to Enroll an Apple TV in MDM – 4 Methods appeared first on SimpleMDM.

A macOS MDM Primer. What’s Possible?

$
0
0

While Apple’s MDM protocol has supported iOS for some time, macOS support is slightly newer and offers a modified set of functionality. This article is intended to provide a general overview of some of the capabilities that are available with native Apple MDM on macOS.

Please note that, while this article will be updated from time to time, it is not intended to cover the complete macOS MDM functionality provided by SimpleMDM.

Onboarding

One of the most notable benefits of using MDM for macOS is how it can help with onboarding new users. Traditionally this involved the tedious and time-consuming process of imaging machines or configuring them manually, and generally requires an IT technician to be present for hands-on setup.

With the help of MDM and the Apple Device Enrollment Program (DEP) and  Apple Business Manager, device administrators can drastically reduce onboarding time and improve the overall experience. When a Mac is registered in Apple DEP and assigned to SimpleMDM, it will automatically enroll in MDM once connected to the internet, immediately after device activation. Enrollment through Apple DEP allows many of the initial Setup Assistant settings to be skipped for a faster setup. It also allows local admin accounts to be automatically created during initialization. After completing the enrollment via DEP, the device receives all the configurations, apps, and accounts that have been assigned to its group in SimpleMDM.

SimpleMDM provides out-of-the-box DEP integration. For more advanced setups, SimpleMDM allows for additional extensibility with third party tools. You can read more about how some of our customer’s have used SimpleMDM to improve their onboarding process here: Customer Spotlight: Tom Bridge’s macOS Deployment Playbook

Is DEP not an option for your organization? Existing devices and non-Apple DEP devices can be enrolled by simply visiting an enrollment URL sent by an administrator through the SimpleMDM interface. This enrollment link can be delivered by email or entered manually into a web browser.

Security

MDM makes it easier to implement and enforce secure practices across your deployment. SimpleMDM offers many features to help. First, passcode policies can be enforced to ensure that devices have passcodes set and that those passcodes meet specified parameters. Second, firmware passwords can be enabled and stored within the admin interface. Additionally, the FileVault profile allows you to force users to enable FileVault encryption with the option to escrow the key to MDM. This allows you to easily retrieve firmware passwords and FileVault keys for managed devices.

Preferences and Permissions

Recent updates have brought some significant changes to macOS and MDM; two of the most notable additions are third-party kernel extension whitelisting and privacy preferences policies.

Many third-party apps require access to other programs on your computer. For example, a meeting app may need to access the Apple Calendar or Mail apps. After downloading the third-party app on macOS, typically a user/admin will need to provide these apps with permission to access other apps. If the app doesn’t have the proper permissions, it can be problematic to the end-user who may not understand why they can’t use an app they need. Luckily, this can be avoided by using a Privacy Preferences Policy profile within SimpleMDM. This profile allows you to specify certain apps that have pre-approval to access other apps so no end-user interaction will be necessary.

Some apps require special access to devices in order to function. This access typically must be granted manually by the user. The Kernel Extension Policy profile allows administrators to configure whitelists to pre-approve kernel extensions for third-party apps, making devices (and apps) another step closer to being completely user-ready.

Software & App Deployment

SimpleMDM supports Apple Volume Purchase Program (VPP) app deployment as well as the ability to deploy macOS PKGs to Macs. By using SimpleMDM, you can ensure that your devices have all the software they need at deployment. Installed software inventory can also be viewed on a per-device basis within the admin interface.

Additionally, SimpleMDM pairs quite well when used alongside open-source Munki for more extensive software management capabilities. We’ve written more on this topic here: Munki Deployment Using Apple DEP And MDM

Other configurations and remote actions

If a Mac is suspected to be lost, some admins may not have a specific course of action. With MDM, admins have the ability to remotely lock and wipe devices by sending a command from the interface, rather than requiring some user interaction to do so.

SimpleMDM allows both device-specific and group-wide accounts to configured remotely on devices. For Macs, this includes Email Accounts, VPNs, and Wireless Networks. A Restrictions profile can be used to enforce restrictions on users’ capabilities relating to the App Store, iCloud accounts, camera access, and more.

Custom certificates and configurations can be uploaded via the admin interface and deployed to devices as well. For more technical users, this provides room for much more capabilities and flexibility to create and use their own configurations. Our post here demonstrates how custom profiles, especially when combined with custom attributes, can used to one’s advantage to customize the experience on macOS: How To Use Custom Configuration Profiles With Custom Attributes

Finally, much of what cannot be done using only out-of-the-box features in MDM can be achieved through the use some combination of open source tools with MDM. SimpleMDM provides administrators with the flexibility to utilize their choosing of alternative tools alongside MDM; we’ve discussed many popular open-source pairings for Mac management here: Popular Open Source Tools for Mac Admins

For a more detailed look at what can be done with MDM on macOS, we encourage you to start a free trial with SimpleMDM.

The post A macOS MDM Primer. What’s Possible? appeared first on SimpleMDM.

Notarization and MDM

$
0
0

macOS 10.14.5 and later requires that “all new or updated kernel extensions and all software from developers new to distributing with Developer ID” as of April 7th, 2019 is notarized in order to run. Notarization will be required of all kernel extensions and software in some future version of macOS.

Gatekeeper is a technology included in macOS that prevents unsafe or unverified software from running on your Mac. When running software downloaded from a third-party source rather than the Mac App Store, Gatekeeper checks the software to ensure that it had been signed using a valid Apple Developer ID. Going forward, Gatekeeper will include an additional verification of non-App Store software known as notarization. The intended result of this change is that users can be more confident that they are running safe third-party software on their Macs.

What is notarization?

Notarization is a security verification performed by Apple that will check to make sure there isn’t any malicious code present and that there are no issues with the code-signing of Developer-ID-signed applications and kernel extensions. Per Apple’s documentation:

“The Apple notary service is an automated system that scans your software for malicious content, checks for code-signing issues, and returns the results to you quickly. If there are no issues, the notary service generates a ticket for you to staple to your software; the notary service also publishes that ticket online where Gatekeeper can find it.”

After the code has been scanned and passed, Gatekeeper will provide additional information in the prompt when attempting to run the software. This will notify the user that the code has been scanned for malicious content and passed.

Notarization also helps developers protect their software from unauthorized distribution by providing an audit trail for the usage of a developer’s signing key.

How does notarization impact my MDM deployment?

For administrators of Mac deployments with MDM, in-house macOS PKGs and kernel extensions will need to be notarized before being distributed via MDM. If your organization is using custom written kernel extensions, software, or is signing and distributing your own instances of popular open source software like Munki, you will need to add notarization to your build process.

Using an MDM does provide some flexibility with kernel extensions, however. Notarization is not required for kernel extensions that are specified in a kernel extension whitelist profile, delivered by MDM.

Need to notarize? Here’s how.

Apple’s documentation explains that notarization can take place automatically in the process for preparing your application for distribution via Xcode. This process is described in more detail in the Xcode documentation.

Apple has also produced additional documentation on the notarization process, including an up-to-date list of the requirements.

The post Notarization and MDM appeared first on SimpleMDM.

New MDM Features Coming in iOS 13 & macOS Catalina 10.15

$
0
0

With the advent of the Apple Worldwide Developer Conference (WWDC), Apple has made public the changes coming in both the latest release of iOS 13 and macOS 10.15 (named “Catalina”). As information is still incomplete and, at times, unspecific, we will be updating this page as we learn more.

An additional note: Though Apple has branched iPadOS off of iOS, for brevity this document uses “iOS” as the OS for iPhone, iPad, and iPod Touch.

DEP: User Account Setup, SAML Auth

The MDM protocol, in conjunction with the Device Enrollment Program (DEP) has supported configuration options around the initial macOS user setup process for some time. For instance, whether an account can be created interactively by the user and whether it receives an administrator or standard user permissions can be specified.

Starting with macOS Catalina, MDM can specify the primary account name and username, as well as whether the user is allowed to change it or not. This is a helpful feature for environments that have standardized username formats.

Additionally, devices can now authenticate against a third-party identity provider (IdP) using a protocol such as SAML.

Bootstrap Tokens

The MDM protocol has been expanded to support setting and retrieving bootstrap tokens for a macOS device. Bootstrap tokens enable mobile accounts to sign in on Macs that are utilizing FileVault. In previous versions of macOS, administrators often needed to build complicated workflows for their users in order to avoid restrictions related to the SecureToken mechanism.

Optionally, the device can be instructed to require a network tether (assumed to be an ethernet connection provided through a dongle connection) in order to complete these operations.

User Enrollment

iOS introduces a new management concept referred to as “User Enrollment”. This mode is intended for bring-your-own-device (BYOD) deployments and shifts the usual balance of IT control and user privacy towards the user.

User enrollment relies on the use of Managed Apple IDs. A Managed Apple ID is associated with a device during enrollment. Configurations, apps, and actions that are delivered by MDM are cordoned off from personal data, protecting the privacy of the user while still allowing an organization to use MDM to manage work-related functions on the device.

macOS will include limited support of Managed Apple IDs for the sake of providing the user with access to cloud-based content.

SecureBoot, Remote Desktop Info

The MDM protocol provides informational data about devices such as battery level, current OS version, and whether a device is supervised or not. Starting with iOS 13 and macOS 10.15, two new keys are returned: The secure boot level and the external boot level.

Additionally, the device will state whether remote desktop is enabled.

macOS Activation Lock

Like in iOS, macOS will now include activation lock functionality when running on computers with the Apple T2 security chip. An MDM will be able to retrieve and clear a bypass code.

Enterprise eSIM Cellular Plan Updates

Using MDM, administrators will be able to trigger the device to refresh its eSIM plan with a carrier.

Profiles

A number of new configuration profiles and additions to existing profiles can be found in iOS 10.14 and macOS 10.15.

SSO Related

Apple has added profiles that allow for additional SSO configurations in both iOS and macOS. These profiles associate certain domains, apps, and operations with an SSO provider. The SSO provider is specified as an app, plugin, or URL.

A feature called Associated Domains in macOS allows administrators to link an app to a service like an extensible app SSO, universal links, or password autofill.

App Lock

iOS app lock can now enable or disable voice control functionality, as well as disallow the user from changing the setting.

Certificates

Certificates can now be designated as not extractable from the keychain.

Exchange ActiveSync

An administrator can selectively enable or disable the calendars, contacts, mail, notes, and reminders portions of the account, as well as whether the user is able to override these settings. ActiveSync now supports OAuth as well.

Content Caching

For macOS, an administrator can disable the user’s ability to delete the cache, whether alerts are displayed, and whether the cache is “kept awake”.

Network Policy

For iOS, the device can be restricted to only allow usage of a specified list of SIM cards (based on ICCID).

One of three WiFi Assist policies can also be specified. WiFi Assist is the iOS feature that determines when the cellular network is used in lieu of an available WiFi network due to poor WiFi coverage or service.

WiFi

The wireless network configuration now allows for explicit configuration of WPA3 networks.

Privacy Preferences (TCC)

Privacy preferences in macOS are being expanded to support a number of new privacy keys, including:

  • File Providers
  • Event Lists
  • Input Devices (like a trackpad or keyboard)
  • Media Library
  • Screen Capture
  • Speech Recognition
  • System Policy: Desktop Folder
  • System Policy: Documents Folder
  • System Policy: Downloads Folder
  • System Policy: Network Volumes
  • System Policy: Removable Volumes

Restrictions

The restrictions profile has added a number of keys that the administrator can disable. These keys are for iOS supervised devices (with the exception of “Device Sleep”):

  • Continuous Path Keyboard
  • Device Sleep: Specifically for tvOS, keep the device from sleeping.
  • Find My Device: Remove the feature from the “Find My” app.
  • Find My Friends
  • WiFi On/Off (referred to in other places as “power modification”)

Software Update

Administrators can now force macOS devices to automatically install macOS updates and app updates, when available.

Dock

In macOS, three dock configuration options have been added:

  • Double click behavior: Maximize, minimize, or do nothing.
  • Window tabbing: Manual, always, or full screen.
  • Show recents: disallow modification of recently used items.

VPN

VPN configuration options have been expanded to include a number of new settings, allowing administrators to specify whether local networks and/or all networks are tunneled over the VPN. VPN traffic can also be tunneled at the packet or higher level application layer.

Further configuration options have been added around certificate settings for certain VPN connection types.

Web Content Filter

The web content filter configuration now includes settings for a filter data provider. This appears to be for both macOS and iOS.

 

The post New MDM Features Coming in iOS 13 & macOS Catalina 10.15 appeared first on SimpleMDM.

Viewing all 51 articles
Browse latest View live