Organizations frequently have another party write iOS apps for them. When doing so, the organization typically wants to sign the .ipa (how iOS apps are deployed) prior to deploying the app to users. To do so, you would sign the .ipa with your provisioning profile. To make doing so easier, here’s ipasign, a python script that does most of the work for ya’:
krypted September 27th, 2016
Profile Manager first appeared in OS X Lion Server as the Apple-provided tool for managing Apple devices, including Mobile Device Management (MDM) for iOS based devices as well as Profile management for OS X based computers, including MacBooks, MacBook Airs, Mac Minis, Mac Pros and iMacs running Mac OS X 10.7 and up. Profile Manager has seen a few more updates over the years, primarily in integrating new MDM options provided by Apple and keeping up with the rapidly changing MDM landscape. Apple has added DEP functionality, content distribution, VPP, and other features over the years. In El Capitan Server, there are plenty of new options, including the ability to deploy VPP apps to devices rather than Apple IDs.
In this article we’ll get Profile Manager setup and perform some basic tasks.
Preparing For Profile Manager
Before we get started, let’s prep the system for the service. This starts with configuring a static IP address and properly configuring a host name for the server. In this example, the hostname will be osxserver.krypted.com. We’ll also be using a self-signed certificate, although it’s easy enough to generate a CSR and install it ahead of time. For the purposes of this example, we have installed Server from the App Store (and done nothing else with Server except open it the first time so it downloads all of its components from the web) and configured the static IP address using the Network System Preferences. Next, we’ll set the hostname to odr using the scutil tool.
sudo scutil --set HostName odr.krypted.com
Then the ComputerName:
sudo scutil --set ComputerName odr.krypted.com
And finally, the LocalHostName:
sudo scutil --set LocalHostName our
Now check changeip:
sudo changeip -checkhostname
The changeip command should output something similar to the following:
Primary address = 192.168.210.201
Current HostName = odr.krypted.com
DNS HostName = odr.krypted.com
The names match. There is nothing to change.
dirserv:success = "success"
If you don’t see the success and that the names match, you might have some DNS work to do next, according to whether you will be hosting DNS on this server as well. If you will be hosting your own DNS on the Profile Manager server, then the server’s DNS setting should be set to the IP address of the Server. To manage DNS, start the DNS service and configure as shown previously:
Provided your DNS is configured properly then changeip should work. If you’re hosting DNS on an Active Directory integrated DNS server or some other box then just make sure you have a forward and reverse record for the hostname/IP in question.
Profile Manager is built atop the web service, APNS and Open Directory. Next, click on the Web service and just hit start. While not required for Profile Manager to function, it can be helpful. We’re not going to configure anything else with this service in this article so as not to accidentally break Profile Manager. Do not click on anything while waiting for the service to start. While the indicator light can go away early, note that the Web service isn’t fully started until the path to the default websites is shown (the correct entry, as seen here, should be /Library/Server/Web/Data/Sites/Default) and a View Server Website link is shown at the bottom of the screen. If you touch anything too early then you’re gonna’ mess something up, so while I know it’s difficult to do so, be patient (honestly, it takes less than a minute, wait for it, wait for it, there!).
Once the Web service is started and good, click on the View Server Web Site link at the bottom and verify that the Welcome to OS X Server page loads.
Setting Up Profile Manager
Provided the Welcome to OS X Server page loads, click on the Profile Manager service. Here, click on the Configure button.
At the first screen of the Configure Device Management assistant, click on Next.
Assuming the computer is not yet an Open Directory master or Replica, and assuming you wish to setup a new Open Directory Master, click on Create a new Open Directory domain at the Configure Network Users and Groups screen.
Then click on Next. At the Directory Administrator screen, provide the username and password you’d like the Open Directory administrative account to have (note, this is going to be an Open Directory Master, so this example diradmin account will be used to authenticate to various Apple tools if we want to make changes to the Open Directory users, groups, computers or computer groups from there). Once you’re done entering the correct information, click Next.
At the Organization Information screen, enter your information (e.g. name of Organization and administrator’s email address). Keep in mind that this information will be in your certificate (and your CSR if you submit that for a non-self-signed certificate) that is used to protect both Profile Manager and Open Directory communications. Click Next.
At the Confirm Settings screen, make sure the information that will be used to configure Open Directory is setup correctly. Then click Set Up (as I’ve put a nifty red circle next to – although it probably doesn’t help you find it if it’s the only button, right?).
The Open Directory master is then created. At the Organization Information screen, enter the name of the contact information for an administrator and click on the Next button. Even if you’re tying this thing into something like Active Directory, this is going to be a necessary step (unless of course you’re already running Open Directory on the system). Once Open Directory is setup you will be prompted to provide the information for an SSL Certificate.
At the Organization Information screen, enter your information and click Next.
At the Configure an SSL Certificate screen, choose a certificate and click Next.
This can be the certificate provided when Open Directory is initially configured, which is self-signed, or you can select a certificate that you have installed using a CSR from a 3rd party provider. At this point, if you’re using a 3rd party Code Signing certificate you will want to have installed it as well. Choose a certificate from the Certificate: drop-down list and then click on Next.
If using a self-signed certificate you will be prompted that the certificate isn’t signed by a 3rd party. Click Next if this is satisfactory.
If you do not already have a push certificate installed for the system, you will then be prompted to enter the credentials for an Apple Push Notification Service (APNS) certificate. This can be any valid AppleID. It is best to use an institutional AppleID (e.g. email@example.com) rather than a private one (e.g. firstname.lastname@example.org). Once you have entered a valid AppleID username and password, click Next.
Provided everything is working, you’ll then be prompted that the system meets the Profile Manager requirements. Click on the Finish button to complete the assistant.
When the assistant closes, you will be back at the Profile Manager screen in the Server application. Here, check the box for Sign Configuration Profiles.
The Code Signing Certificate screen then appears. Here, choose the certificate from the Certificate field.
Unless you’re using a 3rd party certificate there should only be one certificate in the list. Choose it and then click on OK. If you are using a 3rd party certificate then you can import it here, using the Import… selection. Then click OK to save your settings. Back at the Profile Manager screen, you will see a field for the Default Configuration Profile. If you host all of your services on the one server (Mail, Calendars, VPN, etc) then leave the box checked for Include configuration for services; otherwise uncheck it.
Profile Manager has the ability to distribute apps and content from the App Store Volume Purchase Program or Apple School Manager through Profile Manager. To use this option, first sign up on the VPP site. Once done, you will receive a token file. Using the token file, check the box in Profile Manager for Volume Purchase Program” or “Apple School Manager” and then use the Configure… button to select the token file.
Now that everything you need is in place, click on the ON button to start the service and wait for it to finish starting (happens pretty quickly).
The process is the same for adding a DEP token. If you’re just using Profile Manager to create profiles that you’ll import into other tools (Casper, Deploy Studio, Apple Configurator, etc) you can skip adding these tokens as they’re likely to cause more problems than they help with.
Once you’ve got everything configured, start the service. Once started, click on the Open Safari link for Profile Manager and the login page opens. Administrators can login to Profile Manager to setup profiles and manage devices.
The URL for this (for odr.krypted.com) is https://odr.krypted.com/profilemanager. Use the Everyone profile to automatically configure profiles for services installed on the server if you want them deployed to all users. Use custom created profiles for everything else. Also, under the Restrictions section for the everyone group, you can choose what to allow all users to do, or whether to restrict access to certain Profile Manager features to certain users. These include access to My Devices (where users enroll in the system), device lock (so users can lock their own devices if they loose them) and device wipe. You can also allow users to automatically enroll via DEP and Configurator using this screen.
Enrolling Into Profile Manager
To enroll devices for management, use the URL https://odr.krypted.com/MyDevices (replacing the hostname with your own). Click on the Profiles tab to bring up a list of profiles that can be installed manually.
From Profiles, click or tap the Enroll button. The profile is downloaded and when prompted to install the profile, click Continue.
Then click Install if installing using a certificate not already trusted.
Once enrolled, click on the Profile in the Profiles System Preference pane to see the settings being deployed.
You can then wipe or lock the device from the My Devices portal. Management profiles from the MDM server are then used. Devices can opt out from management at any time. If you’re looking for more information on moving Managed Preferences (MCX) from Open Directory to a profile-based policy management environment, review this article and note that there are new options in dscl for removing all managed preferences and working with profiles in Mavericks (10.9), Yosemite (10.10), and El Capitan (10.11).
If there are any problems when you’re first getting started, an option is always to run the wipeDB.sh script that resets the Profile Manager (aka, devicemgr) database. This can be done by running the following command:
Automating Enrollment & Random Management Tips
The two profiles needed to setup a client on the server are accessible from the web interface of the Server app. Saving these two profiles to a macOS computer then allows you to automatically enroll devices into Profile Manager using Apple Configurator, as shown in this previous article.
When setting up profiles, note that the username and other objects that are dynamically populated can be replaced through a form of variable expansion using payload variables in Profile Manager. For more on doing so, see this article.
Note: As the database hasn’t really changed, see this article for more information on backing up and reindexing the Profile Manager database.
Once you’ve got devices enrolled, those devices can easily be managed from a central location. The first thing we’re going to do is force a passcode on a device. Click on Devices in the Profile Manager sidebar.
Click on a device in Profile Manager’s admin portal, located at https:///profilemanager (in this case https://odr.krypted.com/profilemanager). Here, you can see:
The device screen is where much of the management of each device is handled, such as machine-specific settings or using the cog-wheel icon, wiping, locking, etc. From the device (or user, group, user group or device group objects), click on the Settings tab and then click on the Edit button.
Here, you can configure a number of settings on devices. There are sections for iOS specific devices, macOS specific settings and those applicable to both platforms. Let’s configure a passcode requirement for an iPad.
Click on Passcode, then click on Configure.
At the Passcode settings, let’s check the box for Allow simple value and then set the Minimum Passcode Length to 4. I find that with iOS, 4 characters is usually enough as it’ll wipe far before someone can brute force that. However, if a fingerprint can unlock your devices then more characters is fine as it’s quick to enter them. Click OK to commit the changes.
Once configured, click Save. At the “Save Changes?” screen, click Save. The device then prompts you to set a passcode a few moments later. The next thing we’re going to do is push an app. To do so, first find an app in your library that you want to push out. Right-click (or control-click) on the app and click on Show in Finder. You can install an Enterprise App from your library or browse to it using the VPP program if the app is on the store. Before you start configuring apps, click on the Apps entry in the Profile Manager sidebar.
At the Apps screen, use the Enterprise App entry to select an app or use the Volume Purchase Program button to open the VPP and purchase an app. Then, from the https:///profilemanager portal, click on an object to manage and at the bottom of the About screen, click Enable VPP Managed Distribution Services.
Click on the Apps tab.
From the Apps tab, click on the plus sign icon (“+”). At the Add Apps screen, choose the app added earlier and then authenticate if needed, ultimately selecting the app. The app is then uploaded and displayed in the list. Click Add to add to the selected group. Then, click on Done. Then click on Save… and an App Installation dialog will appear on the iOS device you’re pushing the app to.
At the App Installation screen on the iPad, click on the Install button (unless you’re using Device-based VPP) and the app will instantly be copied to the last screen of apps on the device. Tap on the app to open it and verify it works. Assuming it does open then it’s safe to assume that you’ve run the App Store app logged in as a user who happens to own the app. You can sign out of the App Store and the app will still open. However, you won’t be able to update the app as can be seen here.
Note: If you push an app to a device and the user taps on the app and the screen goes black then make sure the app is owned by the AppleID signed into the device. If it is, have the user open App Store and update any other app and see if the app then opens.
Finally, let’s wipe a device. From the Profile Manager web interface, click on a device and then from the cog wheel icon at the bottom of the screen, select wipe.
At the Wipe screen, click on the device and then click Wipe. When prompted, click on the Wipe button again, entering a passcode to be used to unlock the device if possible. The iPad then says Resetting iPad and just like that, the technical walkthrough is over.
Note: For fun, you can use the MyDevices portal to wipe your iPad from the iPad itself.
To quote Apple’s Profile Manager page:
Profile Manager simplifies deploying, configuring, and managing them all. It’s one place where you control everything: You can create profiles to set up user accounts for mail, calendar, contacts, and messages; configure system settings; enforce restrictions; set PIN and password policies; and more. Because it’s integrated with the Apple Push Notification service, Profile Manager can send out updated configurations over the air, automatically. And it includes web-based administration, so you can manage your server from any modern web browser. Profile Manager even gives users access to a self-service web portal where they can download and install new configuration profiles, as well as clear passcodes and remotely lock or wipe their Mac, iPhone, or iPad if it’s lost or stolen.
For the money, Profile Manager is an awesome tool. Apps such as Casper, AirWatch, Zenprise, MaaS360, etc all have far more options, but aren’t as easy to install (well, Bushel is… 😉 and nor do they come at such a low price point. Profile Manager is a great option if all of the tasks you need to perform are available within the tool. If not, then it’s worth a look, if only as a means to learn more about the third party tools and to export profiles you’ll use in other solutions.
krypted September 27th, 2016
In case you’re using DEP and haven’t noticed this, you need to accept the latest terms of service in the Apple license agreement for DEP if you’re going to continue using the service. I don’t usually post emails I get from Apple, but I can easily see orgs using accounts that don’t have email flowing to anyone that is capable of responding, so I strongly recommend you go in and accept the latest and greatest agreements so your stuff doesn’t break!
Here’s the email I got from Apple:
Apple Deployment Programs
Thank you for participating in the Device Enrollment Program. On September 13 Apple will release updated software license agreements. Your Program Agent must go to the deployment website and accept the following agreements to continue to use the program:
- iOS 10 Software License Agreement
- Software License Agreement for macOS Sierra
For more information please see this support article:https://support.apple.com/kb/HT203063.
Note: If you’re using Casper, then the errors you’ll see will be something along the lines of:
Unable to Contact https://mdmenrollment.apple.com
krypted September 12th, 2016
krypted September 10th, 2016
krypted September 9th, 2016
App Store Stats and Fun Stuff
iPhone 7: $629 with Plus starting at $729
iOS 10 drops on September 13th 2016, OS X on September 20th, 2016.
Things not discussed re: iOS 10:
krypted September 7th, 2016
Posted In: iPhone
When using Apple Configurator, you can assign an existing supervision identity to be used with devices you place into supervision. To do so, first open Apple Configurator and click on Organizations.
From Organizations, click on the plus sign (“+”).
From the Create an Organization screen, click Next.
When prompted to provide information about your organization, provide the name, phone, email, and/or address of the organization.
If you are importing an identity, select “Choose an existing supervision identity” and click on Next.
When prompted, click Choose to select the identity to use (e.g. exported from another instance of Apple Configurator or from Profile Manager).
Click Choose when you’ve highlighted the appropriate certificate.
krypted August 23rd, 2016
Looks like Sal et al posted a suite of Automator Actions to link the Casper Suite to Apple Configurator at https://configautomation.com/jamf-actions.html. In my limited tests so far they work pretty darn well!
Some pretty cool things here, like having the JSS rename a mobile device when managed through Apple Configurator, having Apple Configurator instruct the JSS to remove a device from a group, clear passcodes, update inventory, and other common tasks involved in workflows when leveraging Apple Configurator for en masse device management. Good stuff!
krypted July 14th, 2016
The practical uses of Wearables and Home Automation never cease to amaze me. I recently added a Kinsa thermometer to my collection of useful toys. This little device uses the 1/8th inch jack like the original Jawbone did. It works like a regular thermometer, but displays temperature on an app that runs on the iPhone. It’s simple to setup and once setup, works the same as any other thermometer.
Due to the power of the Internets, you can then select symptoms and check for common ailments that match.
You can also look at your history, tracking the rise and fall of your temperature.
Overall, a cool little device and a cool little app.
krypted July 4th, 2016
The increase in the use and complexity of technological assets in the healthcare sector has been on the rise in the recent past. Healthcare practitioners have moved from recording data manually to keeping Electronic Health Records. This eases the accessibility and the availability of data to the health practitioners. Further, electronically stored data makes it possible for patients to receive high quality and error-free care, improve decision making process because medical history is available and also makes it possible to provide safer and more reliable information for medication. Despite, the numerous advantages that the use of technology in healthcare has, there is also a threat of patients data leakage that lingers around. According to a research by Garrison and Posey (2012), medical identity theft has far more consequences in comparison to the typical identity theft. In average, every medical theft case can cost $20,000, and represents a substantial privacy violation. For this reason and more, it is important for healthcare institutions to protect patient data by securing technological assets within the institution. This article will explore the different methods used to secure the technological assets, with an emphasis on mobile devices.
The first method is limiting access to the electronic health records to only a few individuals. According to Gajanayake et al.(2014) suggests that there are different models of limiting access to the records. The first step is to ask for authentication, this will prompt them to verify their identity. This could be achieved by giving the authorized individuals unique passwords for identification and also by performing biometric scans of the individuals. This step will eliminate the possibility of unauthorized access to the technological access. The second step is to limit the type of information that one is supposed to access. This could be made possible using certain access models. Examples of models that have been proposed include Discretionary Access Control (DAC),Mandatory Access Control (MAC) and Role Based Access Control (RBAC). The DAC restricts access to certain commands such as’ write’, ‘read’ and ‘execute.MAC controls access by assigning information different levels of security levels. RBAC is based on the rights and permission that depend on the roles of an individual. These models normally apply to the security of electronic data. Other assets such as the hardware could be protected physically by limiting authorization to their storage rooms and also limit the location in which they are expected to be used at. Limiting access ensures that those that are not authorized to access the information are locked out of the database.Hence, this is an important strategy in protecting patients’ data.
The second method is through carrying out regular audits on the electronic system and the individuals handling the technological assets. Audit controls record and examine the activities that involve access and use of the patients’ data. This can be integrated into the Electronic Health Record (EHR) system or used to monitor the physical movements of the individuals that have access to the records. In addition, HIPAA requires that all health institutions that use the EHR system should run audit trails and have the necessary documentation of the same (Hoofman & Podgurski,2007). Some of the information collected during audits includes the listing of the content, duration and the user. This can be recorded in form of audit logs which makes it easy to identify any inconsistencies in the system (Dekker &Etalle ,2007). Further, monitoring of the area where the hardware have been placed for used should be done. This can achieve by use of recorded video, which monitors the activities of individuals who use the system. This can also be audited regularly and any inconsistencies noted (Ozair et al., 2005) Carrying out audits of the technology assets of the healthcare institution will help to monitor the daily use of the system which will enable the identification of any abnormal activities that may endanger patients’ data.
The third method is the setting up of policies and standards that safeguard the patients’ data. These policies may vary from one institution to another. For instance, the employees should be prohibited against sharing their passwords and ID and they should always log out their accounts after accessing the system. The authorized individuals would also be properly trained about these so that they are aware of their importance. In addition, these policies should be accompanied by consequences which will impact the users. This will ensure that they follow the policies to the letter. The set of policies and standards are to ensure uniformity in the protection of patients’ data (Ozair et al., 2005).
The fourth method that could be implemented to protect patients’ information is through the application of various security measures to the software and the hardware. The software can be protected through encryption of data, using firewalls and antivirus software’s to prevent hackers from accessing the data. Intrusion detection software can also be integrated into the system. These measures will protect the data from individuals who intend on hacking into the system online and accessing information for malicious purposes. The hardware could be protected by placing security guards at different stations where patients’ data is stored so that he ensures that no unauthorized person gets access to the area or no one tampers with the system or steals it. This step will ensure that the hardware is kept safe from intruders and people with malicious intent.
Protecting patient data starts with the software systems that house the data. The databases that warehouse patient data must be limited to only those who need access and access to each record must be logged and routinely audited at a minimum. Data should only reside where necessary. This means that data should not be stored on devices, at rest. For Apple devices, device management tools such as the Casper Suite from JAMF Software both help to keep end users from moving data out of the software that provides access patient data, and in the case of inadvertent leakage of data onto unprotected parts of devices, devices should be locked or wiped in case of the device falling outside the control of a care giver. Finally, the integrity of devices must be maintained, so jailbroken devices should not be used, and devices and software on devices should always be kept up-to-date, and strong security policies should be enforced, including automatic lock of unattended devices and strong password or pin code policies applied.
In summary, the protection of patients’ data in this technological era should be given a priority. In consideration of the frequency and losses that are experienced due to leakage or loss of private patients’ information, more should be invested in maintaining privacy and confidentiality of data. This can be achieved through controlling access to the electronic data and the gadgets that hold it, carrying out regular audits on the access of the system, creating policies and procedures that ensure that data is secures and finally through, putting in security measures that guard against loss and leakage of the information. All these measures will aid in alleviating the risk of patients’ data and maintaining their privacy and confidentiality which is the main agenda.
Dekker, M. A. C., & Etalle, S. (2007). Audit-based access control for electronic health records.Electronic Notes in Theoretical Computer Science,168, 221-236.
Hoffman, S., & Podgurski, A. (2007). Securing the HIPAA security rule. Journal of Internet Law, Spring, 06-26.
Garrison, C. P., & Guy Posey, O. (2012). MEDICAL IDENTITY THEFT: CONSEQUENCES, FREQUENCY, AND THE IMPLICATION OF ELECTRONIC HEALTH RECORDS AND DATA BREACHES. International Journal of Social Health Information Management, 5(11).
Gajanayake, R., Iannella, R., & Sahama, T. (2014). Privacy oriented access control for electronic health records. electronic Journal of Health Informatics, 8(2), 15.
Ozair, F. F., Jamshed, N., Sharma, A., & Aggarwal, P. (2015). Ethical issues in electronic health records: A general overview. Perspectives in clinical research, 6(2), 73.
krypted June 29th, 2016