No option to enter a WiFi password when creating a WiFi profile with wpa or wep security
Pushing out an iOS WiFi profile that contains wpa or wep security is useless without a password. When I attempt to create a WiFi profile and select wpa (any type) or wep I does not give me the option to enter a password. We have WiFi password that is shared among multiple sites and we do not want to distribute it to employees so they can't use it to connect personal devices.
Every other MDM I have used has the option to enter a password.
Is this expected or is this a bug??
This may be a make or break bug for our deployment.
from the week of Nov 6:
Wi-Fi connections support pre-shared keys on iOS
Customers can configure Wi-Fi profiles to use pre-shared keys (PSK) for WPA/WPA2 Personal connections on iOS devices. These profiles are pushed to user’s device when the device is enrolled into Intune.
When the profile has been pushed to the device, the next step depends on the profile configuration. If set to connect automatically, it does so when the network is next needed. When the profile is connects manually, the user must activate the connection manually.
stewart lawrie commented
Why on earth would you have a policy to allow configuring a Wifi profile but not allow you to enter/mange the password? Bonkers....
Have just been through creating a custom profile for IOS and Android. Is a bit cryptic, but this command was very helpful, to essentially output the configuration required for Intune.
1. Connected to the network with Windows
2. Run netsh wlan export profile name="<SSID>" folder=c:\temp
3. The file created from that command, can essentially be copied into the config, as referenced here.. http://www.theenterprisemobilityguy.com/2014/09/creating-a-wi-fi-profile-with-wpa-psk-and-wpa2-psk-to-windows-phone-8-1-via-windows-intune-and-configuration-manager-2012-r2/
OMA-URI path - ./Vendor/MSFT/WiFi/Profile/<SSID>/Settings
...beware special characters in your passphrase, these may need to be converted.
Sean DeLessio commented
Is there any update when this can be released? I'm running into the same issue and it seems kind of pointless to push a Wifi profile when the user still has to enter the password
@MSFT. What went wrong? Earlier this year you could add the password to a Wifi Profile for iOS but now it's gone... I'm due to start enrolling devices soon. We've decided to go ahead and push out Wifi profiles, but the password settings have gone. This is a going to be a massive pain. Can you please reinstate and perhaps apply some common sense. WiFi profiles without the ability to enter in a password are pointless.
Apple doesn't block this. I am running other MDM products that allow fully configuring WiFi
when pushing a wireless profile, include the ability to save the password in the profile. We don't want to publish wireless passwords for some ssids, if we can push these to mobile devices users do not need to know the password, can't give it out or lose it.
I was told that Apple does not allow the ability to create a wifi profiles with the username and password in it or with the client certificate in it. I am not sure if they just don't let Microsoft do it or what, but this is fully supported with Meraki.
This would be a great addition to the product but at least there's a viable work-around if you can either write XML code or you have a Mac.
Terry Lau commented
Please add password filed on Wi-Fi profile setting
Thank you for your reply. I used the method you suggested (thankfully we have 6 Macs in our environment) and I have a bit of feedback on it for any other users who are attempting to use this method.
At this point you need to have a Mac running Yosimite to download Apple Configurator. Attempted the download with Mavericks and I had to upgrade the machine to be able to use it.
Other than that, it worked without issue. Package deployed quickly to he device and when deleted from the portal, removed itself from the device.
Could this method also be used to push out other policies like restricting hotspotting? That is another feature I found that is missing from the configuration profiles that this could resolve.
Having either a UI wizard that supports all options customers need, or as for iOS, having an easy way to author custom payloads (without a Mac) would be great. The OMA-URI settings and custom payloads methods to deploy some types of Wi-Fi profiles are mostly temporary solutions or for corner cases. We have plans to add password for Wi-Fi creation wizard. I will share this feedback with the team and hopefully get it added sooner.
....... sooooo the Microsoft solution is to buy an Apple computer??
Thank you for that suggestion. Horrible way to have to do it but if that works, at least I can get around it until it gets fixed.
What would be even better......Microsoft making a tool that will create an XML file for this custom deployment where you can use a GUI to select the different security settings instead of having to use Apple Configurator. It shouldn't really be that hard to do and since this is a fairly big issue, that would definitely be a valid Windows focused solution instead of having to have access to a Mac.
It would be nice if we were given the option to determine what security features work best in our environment instead of external companies determining that for us.
Here is an example of creating a custom iOS payload for Wi-Fi profile with password.
Intune Hybrid and Intune Standalone support supplying the password in a WPA/WEP Wi-Fi profile using either imported Wi-Fi profile XML or OMA-URI setting which sets the Wi-Fi profile XML for Windows devices, and through custom payload for iOS devices.
Here is a TechNet article describing how to do OMA-URI method in Intune Standalone.
One more thing.
When you push out a profile WITHOUT a password on an iOS device, you actually get an error when enrolling that the password for the SSID that was in the wifi profile is incorrect. If the device is giving an error, this is a bug in InTune.
Can someone answer me why WPA and WEP are implemented in this manner? Engineers?
Having to distribute the password to users is far more of a security risk than someone attempting to sniff packets to get the password. If Microsoft if attempting to protect us from having our wifi password hijacked, this just opens a bigger hole as end users are the biggest security hole.
If a company is concerned with their wifi security, they wouldn't be using WPA or WEP with a password alone. They would be using additional layers. WPA and WEP are for low level encryption situations like small offices, retail settings, guest networks.
Not being able to enter a wifi password makes pushing out a wifi profile useless. This needs to be addressed. Can someone please reply to this issue.