iOS 9 payloads, options missing

[St0rMl0rD]

Hi everyone,

With the recent JSS 9.8 update, we see the new iOS 9 payloads are there, but some features are still missing that were announced (we're probably misunderstanding something or have missed it). We don't see a way to:

• block the user to update iOS
• force to download and update iOS
• block the user to update apps
• change the lock passcode for an iOS device

Is this still coming, or have we misunderstood something?

[bentoms]

@St0rMl0rD do you have any supervised or DEP devices?

I think those options are only available to those devices that are DEP &/or supervised.

[jarednichols]

To clarify:

• There is nothing in MDM to block iOS updates, including in iOS 9.
• Caching and Install iOS update MDM commands require support from the MDM solution. 9.8 does not have it, not sure if 9.81 will.
• Exists now by disabling App Store. iOS 9 and supporting MDM allows deployment and update of apps while App Store remains disabled.
• Nothing in MDM provides to ability to set a particular passcode. MDM can clear pass codes and require them. User must set it.

[bentoms]

@jarednichols i wondered if the MDM spec had changed regards to some of this for iOS 9 as it seems lightspeed are advising that they can block OS updates.

[jarednichols]

If lightspeed's advising that, I'm not sure how they're accomplishing it aside from some voodoo snakeoil black magic. It'd likely have to occur at the network level. I'd be curious if you could share details.

[udopigorsch]

@jarednichols in fact there is something to block/force iOS Updates, it was introduced on the WWDC 2015 - with iOS 9.
It should be part of the session "What's New in Managing Apple Devices" ( https://developer.apple.com/videos/wwdc/2015/?id=301 ) if I recall correctly.

@St0rMl0rD JAMF answered on that by promising to implement that in an old Feature Request ( https://jamfnation.jamfsoftware.com/featureRequest.html?id=386 )

[St0rMl0rD]

Yeah I see, but we're more interested in blocking the iOS updates than forcing them. Oh well.

[Emmert]

If lightspeed's advising that, I'm not sure how they're accomplishing it aside from some voodoo snakeoil black magic. It'd likely have to occur at the network level. I'd be curious if you could share details.

We're currently sort-of blocking it using a proxy-auto-config file on all of our iPads. It's a profile that contains "Global HTTP Proxy" settings that point at a file in our inhouse folder. That config file blacklists mesu.apple.com.

It's not perfect, but it's working for 99% of our iPads.

[St0rMl0rD]

Is mesu.apple.com used for anything else? That tip sounds amazing.
EDIT: which port and credentials does one use for this?

[Emmert]

They check mesu.apple.com on port 80.

[jarednichols]

@udopigorsch No, nothing for blocking. What was introduced at WWDC for iOS 9 is the ability to MDM command a device to cache and (separately, if desired) install iOS updates. These additions were important for customers in retail in particular who wanted to be able to push out iOS updates without having someone touch the glass.

There is currently still no iOS update blocking within MDM. (Have a look at the MDM Protocol Reference if you like.

There are things do-able at the network level (such as blocking mesu.apple.com) but keep in mind that these are completely unsupported and off the reservation. Do they work? In most cases, yes. However, I'd caution in blocking mesu for terribly long. For instance, if you were blocking it for iOS 9, finally tested it and open up mesu later this month, devices will see 9.1 which you hadn't tested. Blocking mesu is all or nothing. There's no granularity to picking which update you want to allow to devices. Also, if devices roam off your network (or have cellular capabilities) they will see mesu at some point. Should they see the catalog at some point, they'll be able to download updates from the CDN, even if they roam back to a network where mesu is blocked.

For instance, user takes iPad home, iPad is in sight of mesu. iPad begins download from the CDN. User goes back to work, is on work network where mesu is blocked. iPad completes download, user installs update. iPad is on an OS you didn't intend. Yes, you can resolve this by using Global Proxy or always-on-VPN, but do you have infrastructure to handle that?

iOS updates are critical for maintaining device security. Un-patched flaws are the #1 attack point.

[St0rMl0rD]

And keeping iPads being useful is our #1. If it happens like last year, when after iWork for iOS update users with Mavericks couldn't read iWork files, created on iOS 8, things are gonna go ballistic.

[jarednichols]

@Emmert

We're currently sort-of blocking it using a proxy-auto-config file on all of our iPads. It's a profile that contains "Global HTTP Proxy" settings that point at a file in our inhouse folder. That config file blacklists mesu.apple.com. It's not perfect, but it's working for 99% of our iPads.

Yup. Network level.

[St0rMl0rD]

Hi everyone,

I tried using a profile with mesu.apple.com on port 80 as the global HTTP proxy, but the iPad still shows iOS update as available to download and install in the Settings. Am I missing something?

EDIT: just figured it out, specifying the proxy server will send ALL traffic of the iPad through that server..looks like we won't be doing this

[Emmert]

Here are the contents of the pac.js file I have ours pointing to:

function FindProxyForURL(url, host) {
if (dnsDomainIs(host, "appchina.com")
  ||dnsDomainIs(host, "iemulators.com")
  ||dnsDomainIs(host, "mesu.apple.com")
  ||dnsDomainIs(host, "vshare.com")) {
return "PROXY 8.8.8.8:53";
}
else {
return "DIRECT";
}
}

It does do all traffic by default, but not if you use some "if" statements.

[St0rMl0rD]

Oh, nice. Where do you put this pac.js file? So the traffic, that isn't going to one of those 4 servers, will not even go through the proxy?

[Emmert]

Correct. I'm hosting the pac.js file in our inhouse folder, and the config points to it:

https://jss.yourdomain.org:8443/inhouse/pac.js

[St0rMl0rD]

Thanks, we'll give this one a shot.

[cdenesha]

Hi @Emmert this is good info. I have two questions about the DIRECT.

1) Does the proxy server (your jss) end up forwarding the traffic or does the iPad handle it all?

2) Do you know if the pac.js settings are cached on the iPad at all, or does every single http request (browser, app, update check, etc.) have to go to the pac.js first?

I'm trying to implement a temporary iOS Software update block in case iOS 9.3 comes out during the middle of SBAC testing. Our JSS is hosted, but if I could put a pac.js on a Google Site page...

thanks!

chris

[cdenesha]

I have just completed my own testing, using OS X Server to host a pac.js that is identical to the above but for just mesu.apple.com.

It works to block iOS update checks. For the following explanation, please remember that I am not a network person.

Every time the iPad restarts it sends three to four connections to the web server, for processes configd, networkd, and securityd; sometimes there is also a locationd (I see this in /var/log/apache2/access_log). The settings are then cached locally, and as the file uses DIRECT there are no further connections as I navigate to different web pages and use various apps. I can install apps, get lists of updated apps, and store data in iCloud Drive. I get an immediate 'Unable to Check for Update' error when I check for an iOS upgrade. If I put the iPad to sleep and open it again the next morning, the information is still cached. When the iPad is restarted it connects to the web server and downloads pac.js again.

chris

[cdenesha]

Hi all,

I thought I had fully updated the thread with my last post, but I guess I did not.

I successfully deployed a configuration profile with a Global HTTP Proxy payload to my 7th graders using SBAC this past spring and they were unable to update iOS.

The pac.js file was uploaded to a Google Site but did not overload it due to the way it works (see previous post). It contained this code:

// created by chris denesha for GPS iOS Update blocking 03/2016
// copied from Emmert at https://jamfnation.jamfsoftware.com/discussion.html?id=17096
// I tried changing 8.8.8.8:53 (a DNS request) to 127.0.0.1 but it took longer for a timeout
function FindProxyForURL(url, host) {
if (dnsDomainIs(host, "mesu.apple.com")) {
return "PROXY 8.8.8.8:53";
}
else {
return "DIRECT";
}
}

Screenshot of config profile configuration:

chris

[damienbarrett]

Chris, this is an interesting solution. If I point all my iPads to a global proxy to block an iOS update, does this also affect the iPads from getting the latest App updates?

[cdenesha]

@damienbarrett Nope, if you use just the URL above you just block the ability to check for iOS updates.

[cnelson]

@cdenesha I would also like to block updates when they first come out and I followed your steps using a google site and everything seems to be working great. I was still a little confused on the caching part. Would every site that I go to on the iPad potentially have to go to the proxy first and then to the site? I don't know if we can have every iPad in our environment go to the proxy every time they browse to a website. Any clarification will be helpful. Great fix, though! I really do appreciate reading your insights on these discussions.

[cdenesha]

Hi @cnelson - no the iPad goes there on startup to get the settings and then it retains them until the next startup. It uses those settings for all web traffic not just web access which is why I couldn't use a profile for Content Filtering.

I'm currently blocking iOS 10 for all supervised devices in district until I complete my testing. I'm also in the middle of a deployment for K-6 so it is taking awhile.. :)

[jtaylor1]

I know this is an old(ish) thread, but we have testing coming up and for the secure browser, they are saying that iOS 10.3 is scheduled but they might not be compatible with 10.3 in time for testing. This has Academic Services worried, so I decided to try what @cdenesha suggested here, and it seems to be preventing ALL traffic on the device I scoped it to.
Well actually, the first thing I tried was to create the pac.js file copied directly from your example and uploaded that to a google site, pointing to that pac.js within the global proxy, it didn't do anything at all. My bad, I realized, there's nothing telling it to run the script. So I created an html page that just called the script and then uploaded that html to the google site (you can't directly edit html on a google site page with the new and improved google sites?!), and then aimed my global proxy at that url. Screenshot of what what I did:

This was when everything stopped working. Once that profile was pushed to the device, it definitely stopped it from updating, but it also stops everything else! I can't send commands to the device, I can't remove the profile, the device can't use the internet at all. It tells me that it is not connected to the internet even though it plainly is connected. In the end, the only thing I can do is put the device into recovery mode and use iTunes to wipe and restore the device. For some reason, "Erase all content and settings" is missing as an option on these iPads now, as well. Not sure what's going on with that, either...

Any thoughts? Ideas? I am not really a javascript person so I fully recognize that I simply failed to understand the instructions, but I'm hoping I can get this to work and make Academic Services happy.

[rknowles]

I am also seeing the same behavior you are seeing taylor1. I get the message "Unable to check for update". But the iPad becomes basically unusable as you wrote.

Selecting the Allow Direct Connection if PAC is Unreachable option allows the iPad to keep functioning in case it can't reach the PAC. Anyone have any feedback?

MCAS testing coming up and I need to get this working. Thanks for any help.

[cdenesha]

Hi @jtaylor1 and @rknowles.

It has to be a hosted file with View permissions. I Shared the file and put the link in the configuration profile. As a test, if you paste that link into your computer's browser it should download the pac.js file.

I did NOT have 'Allow direct connection if PAC is unreachable' checked. Google just shut us down for 'Unusual traffic' and none of the iPads with the proxy were able to browse the internet, although they could use apps with their own connection. I immediately unscoped the profile but.. the iPads couldn't connect to the JSS. <sigh> So I'll be implementing that change!

I'm also testing now why iPads are acting differently in iOS 10 than iOS 9.. where they only contacted the pac.js file on restart and remembered the setting after that. I'll update this thread with my results if I learn anything.

chris

[jtaylor1]

Yep, when I upload it as just a viewable pac.js file or even as an html url with the script in it, either way, navigating to it downloads the file (both the .html and the .js files) as expected. When trying either approach it then shuts down the iPad when I scope it to that iPad. No traffic to it at all, even though it has a connection and then I have to put it in recovery mode and wipe the device to get it usable again. If you check the "Allow direct connection if PAC is unreachable" box then it lets everything through, again, even the iOS updates. Thanks for the keeping us updated, @cdenesha, I'll keep fiddling with it a little as well, probably.

[rknowles]

I ended up putting it on our server where we host the JSS, as others in this thread had mentioned trying.

We created "inhouse" folder in /Library/JSS/Tomcat/webapps/ROOT
Created "noiosupdate" folder in it, placed pac.js inside.
URL: https://<jss>.<schooldomain>:8443/inhouse/noiosupdate/pac.js

It works to block iOS updates, but allows all other app updates and internet traffic.
I do keep Allow Direct Connection if PAC is unreachable checked just in case it goes down. I don't want to end up with bricks for iPads again.

[cdenesha]

@jtaylor1 can you post the text of your pac.js?

[jtaylor1]

I purely copy/pasted yours precisely. The one thing I hadn't tried is uploading JUST the pac.js and trying it with the Allow Direct Connection option checked- I tried it with the .html and it just let the updates happen, but I'll try just the pac.js later today and then post as to how that worked out.

[jtaylor1]

I had two iPads that were both 9.3.x in my vault and I pushed out the config profile to both. One already had the update 10.2.1 downloaded, the other didn't. Both updated without a hitch from 9.3.x to 10.2.1 but now that they are both iOS 10 they can no longer check for an update! Additionally, they CAN do everything else. I can push commands to them, they can download apps and use apps all without issue so far.
So apparently doing it this way does not stop 9.x iPads from updating but does stop iOS 10 from updating. THANKS everyone!

[jtaylor1]

Sadly, although this did work on my test devices here at the DO, once I tried to push them to the devices they'd be needed on, I ran into a new problem: Only one instance of a Global HTTP Proxy can be scoped to a device at a time, and since these devices are take-home devices, the web-filter proxy takes priority. Just a heads-up for anyone wanting to do this that also has another proxy already on a device!

[cdenesha]

Update:

Now with the 30-90 day iOS upgrade deferral option, there is another address you need to block (in addition to mesu.apple.com) if you are going to do it at the network level: gdmf.apple.com.

This is from page 185 of the latest MDM Protocol Reference.

chris