We have found in our environment that it is due to NPS 2008 silently discarding non PEAP authentication requests. The logs of the NPS server show:
Authentication Details:
Connection Request Policy Name: 1-Secure Wireless Connections Aruba
Network Policy Name: Secure Wireless Connections Aruba London
Authentication Provider: Windows
Authentication Server: MISRAD1.xxxx.domain-name.com
Authentication Type: EAP
EAP Type: -
Account Session Identifier: -
Reason Code: 1
Reason: An internal error occurred. Check the system event log for additional information.
A PEAP requiest shows:
Authentication Details:
Connection Request Policy Name: 1-Secure Wireless Connections Aruba
Network Policy Name: Secure Wireless Connections Aruba London
Authentication Provider: Windows
Authentication Server: MISRAD1.xxxx.domain-name.com
Authentication Type: PEAP
EAP Type: Microsoft: Secured password (EAP-MSCHAP v2)
Account Session Identifier: -
Quarantine Information:
Result: Full Access
Extended-Result: -
Session Identifier: -
Help URL: -
System Health Validator Result(s):
-
The server admins are still working with Microsoft to ascertain why it is not rejecting the request as opposed to just discarding the request. A WS capture on the controller will show the 3x10 rules and timeout. This is mainly caused by BYOD clients that are not policy enforced. I have also had lengthy conversations with an Aruba TAC engineer about this. The controller will mark any server down on a 3x10 rule *even* if there is other radius traffic passing (request/challenge/approve/reject) which to me does not make sense. Apprently this has been the source of some debate within Aruba.
What has made matters worse is that in 6.3.1.5 SNMP has been updated to send these traps out. I have since disabled them:
wlsxAuthServerReqTimedOut Yes Disabled
wlsxNAuthServerTimedOut Yes Disabled
....and also set my dead timers to 0
Global User idle timeout = 15300 seconds
Auth Server dead time = 0 minutes
Logon user lifetime = 5 minutes
User Interim stats frequency = 300 seconds
It's not ideal, but stops the reporting and automatic ticket generation.
The Radius RFS states:
http://www.ietf.org/rfc/rfc3579.txt
“On receiving a valid Access-Request packet containing EAP-Message
attribute(s), a RADIUS server compliant with this specification and
wishing to authenticate with EAP MUST respond with an
Access-Challenge packet containing EAP-Message attribute(s). If the
RADIUS server does not support EAP or does not wish to authenticate
with EAP, it MUST respond with an Access-Reject.”
We continue to work with Microsoft.