DEP Enrolled iOS devices - Profile - Wi-Fi

[chrisnenzel]

I had a few questions about adding the Wi-Fi configuration portion to a profile, opened a ticket with VMWare and finished the call with them a little more confused than I think I was when I started.

Background:  We're deploying 1200 DEP enrolled AW managed iOS devices for a project shortly... We have multiple SSID's in our Wireless environment.  I'm wanting to add the restrictions to a profile to send the configuration for one specific network to the devices and, then once this is tested and working properly, use Wi-Fi whitelisting to lock the devices to this network.  The network in question uses WPA/WPA2 Enterprise, PEAP.  On manual enrollment an active directory account can be used to authenticate and a certificate that is sent to the device must be trusted.

What I've observed is that after configuring HUB with an Active Directory account that CAN join the Wireless network when I configure this Wi-Fi network using {EnrollmentUserID} or {EnrollmentUser} the device refuses to connect - when the network is selected from the My Networks section the device prompts for a username and password.  Even when the correct username and password are entered the device will not connect. 

I fiddled with different lookup values and was able to use {FirstName} as for the account enrolled via Hub's first name field is the same value as it's AD account name. However the device still asks me for a username/password when I connect to the Wireless network for the first time.

The Airwatch support rep said this is expected behavior.  She essentially said that the Profile payload doesn't push this info to the device and that the device must be manually configured the first time.  After manually configuring the device to access the desired Wireless network then it uses these settings.  This sounds bogus to me - in fact, if this were the case I wonder why AW would allow me to configure these values at all? 

Shouldn't the device just connect to the network with the username/password provided in the profile???  And, if so, what is the correct lookup value so that device sends the Active Directory account?

I also asked her about pushing the certificate to the device with the profile but never received a clear answer.  If I have access to the SSL Cert and private key can I in some way add it to this profile so the device already trusts the WLAN Controller's certificate?

Appreciate some help on this as I don't think the answers I received from VMWare support were correct or helpful...

Thanks!

[JamieAndersonJa]

Chris, In regards to the cert, you can definitely push that with your WiFi profile. You add it to the credentials payload then in the WiFi payload make sure you check the box to trust it. You should also consider adding the issuing CA cert the same way and trust both. I believe what the tech told you about those values not pushing down is bogus to. I guess she doesn't understand how this stuff really works. From what i'm reading it sounds like your WiFi controller doesn't like the creds that are being passed from the device. It would go along way to look at the WiFi logs to see if a connection attempt is being made. You might also see what your controller doesn't like about the connection attempt. For lookup values your locked into to what WS1 can grab from the DB. Instead of using domain or username try UPN.

[AbrahamSanchez]

That sounds about right. We have the same issue. When a device connects to a secure network, the user is are prompted to enter their user credentials or shared account credentials.  The user is asked to accept the cert and you are connected.  When you try to connect to another SID, it will not connect.  We found that if you tell it to forget the initial WIFI connection, you are then able to connect.  We were told by AirWatch It's by design and working as intended.  Our confusion is, if the device is already being trusted why does the user need to accept the cert?  Either way, does not seem right.  Also, we are in the middle of switching from ACS to ISE. Well....that just opened up another bag of worms.  When we switch over the ISE it's not even connecting autumnally despite having the same trusted root. And while it's not pulling the new cert down, it's still asking for credentials. Makes absolutely no sense.  All I know is that we have Apple engineers looking into this, and so far no one has been able to provide clear direction explanation.  We have been at this for well over a month now. Will follow should we make some type of progress.