I spend the whole day installing and configuring a Mac Mountain Lion with the server app to provide some MDM capability to allow pushing of configuration profiles over-the-air to some iPhones to disable some functions like using camera and safari. Everything was set up and running till I encountered a very troubling problem.
Even though I have set a password for the restriction profile, there is no password set for the MDM profile. Effectively, anyone using the phone will be able to remove the MDM profile which would also removes every restrictions as well, rendering the whole process useless. I found out from some old posts that it is not possible to set a password on the MDM profile. Is this even real? What is the point of restrictions if anyone could remove it when they want.
That's specifically designed like it. Apple has this idea thata user should always decide what he/she wants. So, the user may enroll into MDM and unenroll from MDM any time.
However, in the case, if you remove MDM profile you loose both restrictions and access to your enterprise data (your exchange profile will be removed, if it was installed through MDM. The same is true for VPN access, WiFi access and so on).
It's described pretty well in MDM documentation.
Generally speaking, they weren't good in supporting devices which belongs to enterprise and which suppose to be restricted all the time. Now, they are gradually move into this direction.
BTW. Some new changes are coming in iOS 7 for supervised devices. I believe you may get what you are looking for. If you have an access to WWDC 2013 videos, take a look at managing mobile devices session.
Update 1
I haven't tried it, but as I understand, you can installed locked MDM profile on a supervised device, so this MDM profile can't be removed.
That seems slated to change. I was just reading this article about it yesterday.
Excerpt:
Most crucially, these management profiles can be made mandatory,
preventing users from uninstalling the profiles themselves.
According to the article it's going to allow us to force configure devices without ever needing the device in hand and preventing the users from removing the profiles. There are some nice new features, but it makes me wonder about the ability to force lock down anyone's device with just their serial number. It's something I'll need to spend more time looking into.
Related
We are building iOS apps for distribution in our own internal App Store using an Enterprise Developer Account from Apple. For building, we need to generate a provisioning profile, which expires 12 months from the creation. After expiration, the app doesn't work on the devices (crashes immediately because of expired Provisioning Profile), and each device needs to reinstall a new build of the app.
How can we provide our users an user friendly workflow in which they do not have to cope with crashing apps after 12 months?
Thanks in advance,
Bas
The expiration of provisioning profiles is a hassle with enterprise distributed apps. And it is something that will require ongoing maintenance from your internal development team, mobile support teams.
First, I want to point out that you don't mention certificates. Because they only expire every 3 years now (as of this writing - originally they expired every year), developers often forget about them. However, their expiration is actually more troublesome than the profiles. When a profile expires, you simply need to get another valid profile on the device. This can be done in multiple ways. You can use an mobile device management (MDM) solution to push just a new profile. Or if another app with a valid profile (that uses a wildcard ID) has been pushed to the device more recently, this can also get a valid profile on the device.
If the certificate expires, you will actually need to re-build the app with the new certificate. Old builds signed with the expired cert will not run unless. Technically, you can resign the old IPA, but the main thing to note is that the actual binary is invalid and will not work until a new binary with a proper code signing is generated. Fortunately this is only every 3 years, so it is less frequent, but I can almost promise you when it happens you will have a mess on your hands if you don't plan for it. Again, as with the provisioning profile, you could handle this by using MDM to push something new to the device. In this case, you would use MDM to actually replace the while app, not just the profile. A little more work, but it could be done.
Of course, there are reasons you may not want to use MDM. Cost could be a concern. Employees may not want the company to manage their personal devices (if these apps are going on personal devices). Ability to manage the MDM infrastructure / workload. If MDM is not a great solution for your organization, I would recommend another approach that isn't as ideal from a user experience, but could solve your problem. You could built your apps to be self-updating. In other words, on launch, your app checks a server to see if a new version is available. If so, it prompts the user to update. This wouldn't require the device to be managed, and you could easily build a shared framework to make this easy for app developers. One downside to this approach is if the user doesn't launch the app between the time you post the new version (with new profile / cert) and the time the profile or cert expires, the app will not launch, so the auto-update functionality can't run to tell the user to get a new version. It will just appear to the user as if the app is crashing. That is the one UX problem with this approach. But if you can manage that, it can provide an alternative to the MDM route.
You can manage this with an MDM server. Essentially the workflow looks something like this:
User installs MDM Profile and Accepts the prompts to allow the MDM Server to install apps.
The MDM Server is able to manage the device according to the permissions set in the MDM Profile. Apps managed by the MDM Server can then be installed and removed arbitrarily.
A quick google search for iOS MDM Server should get you headed in the right direction. Pricing for various paid options is somewhere around $15 / device / year, last time I looked into this (about a year ago). But there are one or two reasonable open source MDM Servers available as well.
I need to install an VPN configuration profile, which may be changed without user intervention at a later point of time. The straight way is to have the VPN profile installed, and installing the MDM profile so that the configuration can be changed at later point of time.
However, my requirement is only pertain to the VPN configuration and do not want to manage the device completely, and want to co-exist with other MDM vendor's profile installed.
Is there any less privileged way to do this? The main requirement is, I should be able to change my VPN configuration profile, though there is another MDM profile from different vendor is installed in the iOS device.
The only way to upgrade profiles without a user interaction is through MDM right now.
I would love to see iOS device being managed by multiple MDM (Which would alleviate interoperability problem). However, Apple doesn't support this.
We are a small IT team that needs to purchase between 20-100 iOS devices (iPhones) to hand out to external partners. These devices will be setup once, and then leave the premises to pretty much never ever come back physically.
The devices needs to be fully locked to our application. We won't allow surfing, emailing, phonecalls, text messages etc.
I need to set this up as easy as possible. Then I need to install our application (developed in-house) and once I create an update for this app all devices needs to be updated OTA. Updates to the iOS firmware should only be available if I say so. I don't want the user to be prompted to update iOS in case our application is not compatible yet.
From my understanding, I know I need some kind of MDM solution (Preferably Apple Configurator or the MDM server built into OS X Server in Yosemite) as well as an Apple Enterprise Developer account.
I'm looking for step by step instructions on how to set this up to be failproof. If any certificate is messed up, or expired at a later stage and the devices would end up "useless" it is nearly impossible for me to get to the devices physically.
Thank you for any responses, I'm in charge of quite a important part of the business, and I have no previous experience of this (I don't want to f' up)
Your question is very large, so I'm going to only address a few specific points that should get you going in the right direction.
If the devices are bought by a company or institution, you should look into supervising the device (a process which asserts that this device is owned by a company or institution and so certain restrictions normally unavailable to BYOD are available on this device for MDM). Ideally, you'll purchase your devices straight from Apple in the US and then enroll them in the Device Enrollment Program (https://www.apple.com/education/it/dep/). This will allow you to configure the devices so that every time they are erased, they will become supervised again and re-enrolled with your chosen MDM server and configuration (and also give you the option to lock MDM so that it is unremovable).
Configurator is not your friend if you're not going to have physical access to the device. You'll want to use a MDM server and should look at a third-party vendor for the best experience (see AirWatch and MobileIron to start with). An MDM server will be able to push install and update profiles and apps on the devices and so you should look heavily into this.
If the devices will be locked into a single application, look at Single App Mode. By pushing down a profile by MDM, you can lock the device into a single app, but only on SUPERVISED devices. You'll also want to look at the restrictions available for disabling things like Safari and such. The Mobile Device Management Protocol Reference and the Configuration Profile Reference are both your friends here.
You will NOT be able to prevent devices from updating iOS itself. This is a purposeful design choice from Apple and so you need to be testing your software against the developer betas to ensure it works before release or else you're out of luck.
Go check out the Apple Enterprise page (https://developer.apple.com/enterprise/). Some good videos are the WWDC 2014 "Managing Apple Devices" and "Building Apps for Business and Education".
A couple of days ago I was asked whether it is possible to record a conversation using an iPhone. Having heard of Apple’s disapproval of that given function, I have confirmed it was not possible. However, out of curiosity, I have googled the info on this issue. Surprisingly, it led me to a website offering a variety of dubious shady activities (wiretapping related).
I will leave all the details behind, just to tell you in a few words that out of desire to understand how it was even possible, using that site I easily managed to install an unauthorized third-party application onto my iPhone with iOS 8.0 bypassing the legal distribution channels and without me providing them the UDID of my phone so they could add it to their distribute certificate (eventually substituting the original messenger app (WhatsApp, Skype, etc.) with their almost identical clone that is collecting and submitting personal info).
As far as i understood the clean/not jailbreaked iOS has no distribution channels other than AppStore, Ad Hoc or Enterprise channels (with providing UDID in the latter two).
I don’t know if this is a system flaw or vulnerability, but this is supposed to not be possible. Maybe, though, my logic is missing something. That is why I am trying to address this issue here.
The aim of this post is to bring up your expertise and to find out collectively the mechanics of these activities to ultimately prompt Apple to eliminate the related shortcomings.
Again, I have the details and can provide them in case needed, but for the sake of not being deleted or, God forbid, banned I am keeping those to myself for the moment.
Thank you.
One can buy an enterprise account for 299$ per year to build in-house Apps, which can be distributed without knowing or adding any UDID.
These Apps should normally only be distributed to employees, but this restriction is often ignored and Apple bans those accounts then.
I have posted this question on SO since I think it is the most logical place to find people with a lot of experience with the iOS Enterprise program.
For my company, we are developing an in-house app. We would like to deploy this app with the minimum effort required on the user's side <1>, as it should be possible to quickly install it for incoming colleagues. Additionally, we can't always guarantee an up and running internet connection at install time <2>. The in-house app is to be downloaded on our premises from a webserver through wifi.
We are currently not enrolled in the enterprise program, as we're investigating whether or not our goals can be realized.
As for <1>, what we've found is that UDIDs are not necessary to include in the provisioning profile for enterprise deployment. What is needed, is a provisioning profile. Now, here are my first concrete questions:
are any additional steps necessary before a provisioning profile can be installed?
can the provisioning profile be embedded within the app as can be done for OTA betas? This would save a user the step of installing the profile.
For <2>, the following issues come to mind:
here it states that access is needed to ax.init.itunes.apple.com and ocsp.apple.com. The former for querying the max allowable GPRS app file size. It doesn't sound relevant when your goal is to distribute over wifi, but the page says "If this site isn’t reachable, installation may fail." so it does concern me a bit. The latter one seems less severe as it is stated that "Inability to contact or get a response from the OCSP server isn’t interpreted as a revocation", which means that it should be possible to not contact this server right away.
I'm assuming that I can use any URL scheme to point to a local server that provides the app bundle and that there are no restrictions on server configuration.
Summarizing the two: is it possible to install an in-house app from a local server without a functioning internet connection?
Thanks for the help; it's greatly appreciated. As I have no prior experience with Enterprise deployment, it is tough to be confident that I'm not missing out on the nitty gritty details in Apple's documentation.
Provisioning profile can be embedded.
Your employee's devices requires internet connection when they are downloading the app, so that the device can contact Apple servers you mentioned.