I didn't even think that I would return to this case, but Cisco Open Air Wireless Marathon pushed me to remember and tell about my personal experience, when a little over a year ago I had a chance to spend quite a lot of time studying the problem with a wireless network based on Cisco and iPhones. I was instructed to sort out the question of one of the leaders: "Why, after restarting, the iPhone cannot automatically connect to the Wi-Fi network, and when manually connected, it asks for a username and password?"
Information about Wi-Fi network:
Wireless controller - AIR-CT5508-K9.
Controller software version - 8.5.120.0.
Access points - in the bulk of the AIR-AP3802I-R-K9.
The authentication method is 802.1x.
RADIUS server - ISE.
Problem clients - iPhone 6.
Client software version - 12.3.1.
Frequency 2.4GHz and 5GHz.
Finding the problem on the client
Initially, there were attempts to solve the problem with a swoop on the client. Fortunately, I had the same phone model as the applicant and was able to test at a convenient time for me. I checked the problem on my phone - indeed, immediately after turning it on, the phone tries to connect to the previously known corporate network, but after about 10 seconds it remains unconnected. If you select the SSID manually, the phone will ask you to enter your username and password. After entering them, everything works correctly, but after rebooting the phone again cannot automatically connect to the SSID, despite the fact that the login and password were saved, the SSID was listed in the list of known networks, auto-connection is enabled.
There were unsuccessful attempts to forget the SSID and add it again, reset the phone's network settings, update the phone via iTunes and even upgrade to the beta version of iOS 12.4 (the latest at that time). But none of this helped. Also, the models of colleagues - iPhone 7 and iPhone X were tested, the problem was also reproduced on them. But on phones with Android, the problem is not fixed. Additionally, a ticket was created in the Apple Feedback Assistant, but until now no response has been received.
Finding the problem on the wireless controller
After all of the above, it was decided to look for the problem in the WLC. In parallel, I opened a ticket to Cisco TAC. On the recommendation of TAC, updated the controller to version 8.5.140.0. Played around with various timers and Fast Transition. Did not help.
For testing purposes, I created a new SSID with 802.1x authentication. And here's a twist - the problem is not reproduced on the new SSID. The TAC engineer's question makes you wonder what changes we made to the Wi-Fi network before the problem manifested itself. I'm starting to remember ... And there is one clue - initially the problematic SSID had a WPA2-PSK authentication method for a long time, but to increase the level of security, we changed it to 802.1x with domain authentication.
Checking the lead - changing the authentication method on the test SSID from 802.1x to WPA2-PSK, and then back. The problem is not reproducible.
I need to think more sophisticated - I create another test SSID with WPA2-PSK authentication, connect the phone to it, and remember the SSID in the phone. I change authentication to 802.1x, authenticate the phone with a domain account, enable auto-connect.
Restarting my phone ... And yes! The problem repeated itself. Those. the main trigger is the change on the known SSID of the authentication method from WPA2-PSK to 802.1x. I reported this to a Cisco TAC engineer. Together with him, they reproduced the problem several times, took a traffic dump, in which it was seen that the phone, after turning on, starts the authentication phase (Access-Challenge), but after a while it sends a diassociation message to the access point and disconnects from it. This is a clear client side problem.
And again on the client
In the absence of a support contract with Apple, there was a long but successful attempt to reach their second support line in which I talked about the problem. Then there were many independent attempts to find and determine the cause of the problem in the phone, and it was found. The problem turned out to be in the enabled " iCloud keychain". Quite a useful feature, which I and the applicant did not want to disable on phones for workaround. In my assumption, the phone cannot overwrite information about the method of connecting to known SSIDs on iCloud servers. The find was reported to Apple, to which they admitted that There is such a problem, known to the developers, and will be fixed in future releases. Which one was not reported. I'm not ready to say how things are at the moment, but at the beginning of December 2019 the problem was still reproduced on the iPhone 11 Pro Max with iOS 13.
Conclusion
For our company, the problem was solved successfully. Since the company name was changed, it was decided to change the corporate SSID as well. And the new SSID was immediately created with 802.1x authentication, which was not a trigger for the problem.