1

I am managing design, build/testing and deployment of 3,500 iOS devices into our Enterprise this Fall. We have been using Configurator .mobileconfig profiles to manage Wi-Fi payloads on a WPA2 Enterprise wireless network. The iPods are enrolled in MobileIron MDM and are running iOS 7.1.2. I have a "chicken & egg" problem concerning Wi-Fi authentication and long-term management of the connection process. I only hope I'm doing a good enough job of telling the story of the work I've done to try and hash this out on my own!

We use an Active Directory service account to connect to Cisco wireless controllers. Therefore, the domain\account and password are hardcoded into the .mobileconfig and reside on the device. We could just as easily specify these settings directly in MobileIron (MI) vs. using it to push this imported profile but I think the problem is the same.

For best-practice purposes, suppose I want (or even need) to change the password associated with this service account, and have a new profile loaded in MI ready to push out to the devices. Each device has a different state of 'readiness' at any given time, right? In other words, some may be in use, some may be locked, some may be dead and on the charger... so I cannot rely on devices receiving a new profile push from MI when it's "published" to that device group.

By changing the password, I sever that device's ability to connect to the MI server and receive that profile with the new credentials (absent any iOS-side caching that may linger, this also is not reliable). Sure, with a smaller population you could carefully time out this process so the profile with the new password is pushed and received before you change it in AD, but this would be next to impossible to monitor for thousands of devices.

After running this by a Sr. Engineer at Apple that I have access to, I thought I would create a profile that would consist of the following:

SSID: BananaStand
WPA2 Enterprise: EAP/TLS
Username: Domain\GOB
Password: Segway01

SSID: BananaStand
WPA2 Enterprise: EAP/TLS
Username: Domain\GOB
Password: Marta143

SSID: BananaStand
WPA2 Enterprise: EAP/TLS
Username: Domain\GOB
Password: T0nyW0nd3r!

Thinking, if the iPod was connected using the first password, once I changed it in Active Directory, the profile would "failover" to subsequent entries for this SSID until it successfully connected.

I tested this process with a Verizon hotspot (where I could easily control the environment) and the iPod tried three times and gave up. Toggling Wi-Fi and power-cycling had no effect.

Does anyone have any thoughts on how I might be able to "preload" passwords (almost like a list of "backup codes" for Evernote/Google/etc) in a profile or MI to enable the iOS device to already have knowledge of the next password BEFORE it gets booted from the network?

Btw, we may be ready for certificate-based WAP authentication in the future but not today.

  • did you ever solve this? i am facing a similar issue. – k1th Jun 20 '15 at 8:42
  • No - but I don't think it's because an answer was out there and no one jumped in. I think the method of authenticating an iOS device to an enterprise wireless network using an AD service account (or any user object) is best used short-term, if at all. We've been forced to abandon this approach (thankfully - for everyone knew it was a crutch) and look at machine certificates administered by MDM and using Cisco ISE as the front end to control who gets to connect (i.e., only Enterprise-owned assets, for starters). – Paul B Jun 22 '15 at 15:38

You must log in to answer this question.

Browse other questions tagged .