Below is a sample of what we see in the IAS logs for these BlackBerry 8320 and 8820 users. This particular user works fine on a laptop or on a Windows Mobile 6 device (ie: T-Mobile Dash).
User <USER> was denied access.
Fully-Qualified-User-Name = example.com/Users-Developer/<USER>
NAS-IP-Address = 10.123.30.11
NAS-Identifier = WLC-1
Called-Station-Identifier = 00-0B-85-XX-XX-XX:wlan
Calling-Station-Identifier = 00-1C-CC-1C-XX-XX
Client-Friendly-Name = WLC-1
Client-IP-Address = 10.123.30.11
NAS-Port-Type = Wireless - IEEE 802.11
NAS-Port = 1
Proxy-Policy-Name = Use Windows authentication for all users
Authentication-Provider = Windows
Authentication-Server = <undetermined>
Policy-Name = Wireless Authentication - Allow
Authentication-Type = PEAP
EAP-Type = <undetermined>
Reason-Code = 23
Reason = Unexpected error. Possible error in server or client configuration.
The above info tells me the encrypted password portion of the authentication is not occurring because IAS can not determine the EAP type.
We next turned to a wireless sniffer to compare a Windows XP host with a BlackBerry 8320/8820. The only difference in the authentication process is that the BlackBerry device(s) respond with a SSL/TLS encryption error after the certificate is sent from the RADIUS server. Basically the PEAP process starts, the username get passed, and the IAS (RADIUS) server sends the certificate information for the SSL/TLS encryption. Once the last certificate packet is acked, the BlackBerry responds with SSL/TLS encryption failure and is then DeAuthed from the Access Point.
In the advanced Wi-Fi diagnostic tool on both BlackBerry devices it indicates a W010 Error: Wifi Association Failed.
I am down to two theories as to root cause at this time:
- BlackBerry 802.1X supplicant problem
- PEAP Misconfiguraiton on the BlackBerry devices
Another thing we tried was modifying the 'Server Subject' field format on the BlackBerry devices putting the fully qualified subject name of our server certificate (ie: CN=wifisecurity.example.com,OU=IT,O=Company, etc) but no change -- same errors. RIM support has indicated this field only needs to be populated with the hostname on the certificate (ie: wifisecurity.example.com or also known as the certificate "friendly name"). It was worth a shot...
Cisco TAC has also come back after analyzing our logs and sniffer traces and believes, at this time, the issue is with the BlackBerry device(s).
We really wish we could share our findings with some RIM engineers or developers. Someone somewhere knows what is going on or how to collect more detailed debugging information from the BlackBerry 802.1X supplicant.