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.
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 am making an enterprise application for iPhone, it does not contain uninstall option how to make this application in ios. Lang:Objective c
There is no uninstall on iOS, you can just remove any app you installed. You press the app and after some time the icon wobble and a cross is show, click the cross and the app gets removed.
You however restrict device and disallow the user to remove some app, this is done with Mobile Device management MDM.
You can register devices to an MDM server and push setting to the device, allow/disallow install of apps, force install of apps, restrict apps, etc..
There is no way to create iOS app that could not be removed.
But, you can use iPhone/iPad/iPod settings to forbid uninstall:
https://support.apple.com/en-us/HT204396
Or you can use MDM to setup restrictions:
Configuring devices with MDM To enable management, securely enroll
your devices with an MDM server using a configuration profile—an XML
file that allows you to distribute configuration information to an iOS
device. These profiles automate the configuration of settings,
accounts, restrictions, and credentials; they can be delivered through
MDM if you need to configure many devices and prefer a low-touch,
over-the-air deployment. Profiles can also be sent as an email
attachment, downloaded from a web page, or installed on devices
through Apple Configurator 2.
Take a look at MDM docs:
http://images.apple.com/business/docs/iOS_Deployment_Overview_Business.pdf
The only way you can prevent Deleting ( uninstalling ) apps is to go to
Setting app->General->Restrictions
From there 'Enable Restrictions' and setting up a password for parental control,
Then turn off 'Deleting App' switch control.
This is usually good for devices belonging to a company or an organization in the hands of members or employees. Otherwise you can not prevent users from deleting an app from their devices they own.
Is it possible to have MDM profiles stored locally on a device and then switched dynamically? Preferably by an API so an App could do this. With an MDM such as Absolute Manage MDM and Meraki they say this can not be done.
I understand that any App is sandboxed and I myself feel like this is not possible but I need some answers to tell management rather than me just saying no.
Jailbreaking is an option but only if there is no other way.
Any help would be great. Thanks
You can do this, if your have local MDM server (meaning running on a device itself). This way you can switch profiles locally.
There is no public API to manipulate profiles for iOS. And as I remember private API's which are designed to do that are protected by entitlements. So, signing an app with enterprise cert isn't an option.
Jailbreak is an option.
P.S. I have no idea how Absolute Manage MDM and Meraki does what they claim to do.
After further research this was not possible with iOS. I called several MDM providers and spoke to qualified engineers that confirm it not possible without internet connectivity.
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.
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.