Monitoring, Management & Location Tracking

AirWave's 7.2 version has a solution to this problem (See AMP Setup -> PCI Compliance -> 4.1.1).

The following article describes limitations of the PCI 4.1.1 audit in AirWave versions 7.1 and earlier: (A patch for 7.1 is available from AirWave Support.)

1. Sometimes we don’t report that the authentication subtype is EAP. For the user we’ve looked at, that always happens when we just see the user for one poll. We are currently investigating this issue.

2. If the authentication type doesn’t include the term “EAP”, our PCI Compliance Report considers that a failure. Here’s a sampling 

id | authen_type | authen_subtype | connect_time | disconnect_time 
-------+----------------+----------------+--------------+-----------------
40880 | WPA2 (EAP-TLS) | EAP-TLS | 1268866820 | 1268867420
41462 | WPA2 | | 1268971289 | 1268971890
41384 | WPA2 (EAP-TLS) | EAP-TLS | 1268949074 | 1268949675
41372 | WPA2 (EAP-TLS) | EAP-TLS | 1268947873 | 1268949075
40924 | WPA2 | | 1268884832 | 1268885433
40842 | WPA2 | | 1268863217 | 1268863818

Our interpretation of the PCI rules is that they do need to use EAP to pass. So it’s correct that the report module considers these sessions failures. Really, the fact that these users’ sessions are causing compliance failures is a symptom of item #1.