If you have used Microsoft NPS or IAS for radius service and looked at Event Viewer to troubleshoot user denied access, it was probably a pain because Event Viewer lacks crucial information to identify the problem. On the other hand, CPPM Access Tracker is overwhelming with the amount of information it gives. But if you have a better understanding of this information, it will help to identify the problem quickly.
In this troubleshooting guide, I will show you what I have seen in my enviroment and point out the meaning of the message in Access Tracker Request Details.
CASE #1: Fail, account not present in Authentication Sources
I am using CPPM to authenticate all logins to controllers, CPPM and AirWave, thus the service name ARUBA_LOGIN_ SVC. “clearpass” is the generic logon domain account for AirWave to logon to controllers who were denied.
Figure 1: Start with Access Tracker Summary. By looking at Authentication Source and Roles you can tell this user was denied by DC1.boystown.org
Figure 2: Move to the next tab Input/RADIUS Request. This tab shows the request sent from the controller to CPPM. Called-Station-Id is the mac address of the client, which is my computer trying to ssh to the controller; Calling-Station-Id and Framed-IP-Address are the IP address of the client; NAS-IP-Address is the controller ip address
Figure 3: Scroll down to Input/Computed Attributes: Dest-IP-Address is the CPPM doing the authentication; not useful information for this case.
Figure 4: not much information here, we already know the user was denied in Summary tab
Figure 5: My authentication sources include two domains and Local User Repository; CPPM could not find this user in all three sources.
Conclusion: CPPM performed LDAP query two ADs and Admin User Repository for this user account. It found no user “clearpass” in any of them, so the authentication failed. User received default Deny Access Role.
Tips: If user was not found in AD, CPPM moved to the next Authentication Sources, but if user found and failed authentication, CPPM stopped and denied access immediately after the first Authentication Source.
CASE #2: User did not update password in smart devices
Our AD requires that users change their passwords every three months. We support user’s smart devices for syncing with Outlook, but when they change passwords on their desktops, they forget to update password in their phones.
Figure 6: This Summary tells me user JOEDOE was denied by DC1. I am using certificate, so the Authentication Method EAP-PEAP, EAP-MSCHAPv2 indicates this is NOT a domain computer. If it is a domain computer, the Authentication Method is EAP-TLS
Figure 7: This Input/RADIUS Request has many useful information about this JOEDOE user:
- End-Host Identifier: user device mac address
- Access Device IP/Port: the controller that user and AP were terminated at
- Aruba-AP-Group: what ap-group the AP that user associates belong to
- Aruba-Device-Type: it is an iPhone, as I mentioned earlier, this is not a domain computer
- Aruba-Location-Id, Called-Station-Id: the name and wired mac address of the AP
- NAS-IP-Identifier and NAS-IP-Address: these are local controller and master controller respectively.
Tips: This tab lays out very nicely the authentication processes from user device to AP to local controller and finally to master controller. You can configure local controller to bypass master controller and send authenticate directly to CPPM by configure “ip radius source-interface” and “ip radius nas-ip” at the local controller.
Figure 8: CPPM shows User authentication failure.
CASE #3: The “Time-Out” Failure
In Access Tracker you want to see a lot of black (ACCEPT). It is usually not a good sign if you see a lot of red (REJECT) or orange (TIME-OUT). The reason for REJECT is usually easy to find, but the TIME-OUT is not clear. The CPPM alert for TIME-OUT is “Client did not complete EAP transaction”, it could be anything!!!
Figure 9: The Summary, Input and Output tabs are the same as the other cases, the only difference is in Alerts tab where CPPM indicates the client did not complete EAP transaction.
By default, each transaction has 10 seconds to complete or the client will time-out. The complication is where did the time go? Client took too long? Server is too busy? CPPM has bad configuration (it is never the problem with CPPM right?)?
- The problems I have seen with client supplicant taking too much time to authenticate are the following: outdated driver, bad wireless card, wrong EAP type, low RSSI (too far from AP).
- The problem with severs and domain is the System guys problem; a few times it was the server update the night before. But you can pinpoint this case quickly, because you will experience many domain issues along with slow LADP query, and you can blame another department for this.
- Bad CPPM configuration: It happened to me once. My CPPM configured with the wrong DNSs. The DNSs were supposed to be for different domain, so CPPM jumped to another domain for DNS then went back to its domain for LDAP queries. Adding to the complication, the problem was intermittent and only happened during peak 30 min to an hour.
CPPM is a wonderful product; if you have used it you probably agree it is the best NAC for wireless. But it is a monster. If you take some time to work with it, you will find it is useful to help you with your daily task as a network engineer, either for its quick and secured configuration for wireless access or troubleshooting the issues with authentication.