iDevice Clients Offered A Blank Certificate On Password Change When Connecting To Wireless Using RADIUS Authentication

Standard

We’ve been supporting iDevice clients for a few years now, but recently ran into an issue that even a Cisco TAC call & the ever helpful resources of JAMFNation & MacEnterprise we not able to resolve.

Our users authenticate to the wireless using their AD credentials, after a password change they should be prompted to enter their new password. Once done they should reconnect to the wireless.

Oddly, after a password change the iDevices started to be offered a blank cert such as that below:

BLANK-CERT

Plugging in the iDevices having the issues into a computer running iPhone Configuration Utility showed nothing in the Console log.

We use Cisco wireless hardware, so the next step was to look at the logs there. Below is an example (IP’s & MAC addresses have been xx’d out).

171
Thu Jan 23 11:34:00 2014
Client Deauthenticated: MACAddress:xx:xx:xx:xx:xx:xx Base Radio MAC:xx:xx:xx:xx:xx:xx Slot: 1 User Name: xxxx Ip Address: unknown Reason:Unspecified ReasonCode: 1

 

Not much there, but this was always followed a RADIUS server error:

172
Thu Jan 23 11:34:00 2014
RADIUS server xx.x.x.xx:xxxx failed to respond to request (ID 64) for client xx:xx:xx:xx:xx:xx / user ‘unknown’

 

For SSID the Wireless LAN controllers use a Windows 2K8r2 server  for RADIUS authentication. This server is running the  “Network Policy And Access Services.” Again though, nothing helpful was in the logs.

Over time we had users advise that if they reset their password one day, they would keep getting the blank cert until the following day. With this & the RADIUS message being the only things to go on, we started looking at the Windows 2K8r2 server.

Much googling ensued, eventually leading to the post here. With the pertinent part below;

I have narrowed the problem to any Apple client with 10.5 - 10.6 or the iPhone/iPod OS.  I noted that the internal errors do not occur when I change the number of PEAP MSCHAPv2 retries to 0 on the NPS server.  After this change, Apple clients behave exactly like Windows clients.  This has the unfortunate side effect that a single bad logon causes a wireless authentication failure on the client; requiring the user to restart the wireless connection.  This provides a work around, but it is certainly not an ideal configuration.

The NPS retries can be found under in the Server Manager MMC > Network Policy And Access Services > expand NPS Local > expand Network Policies > select the Network Policy in use > click Properties > Constraints > Authentication Methods > select the EAP Type > click Edit… > click Edit..

Ours had been set to 10, changing it to 0 as per the above post has seemingly resolved the issue for us.

 

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.