Workstations Stuck in NAC Authentication VLAN

[premiers-maps]

Hi there,

We are currently running NAC 4.8 in layer 3 real IP gateway mode with Active Directory single sign on. I recently renewed our CAS server certificate with Verisign and have since had some PC's which appear to remain in the NAC authentication VLAN after what looks like a successful authentication on the CAM. The NAC client currently in production running on Windows 7 is version 4.8.1.5.

The CAM logs report the user as successfully logged in and an SNMP trap is pushed to the switch to execute the VLAN change however the VLAN is not changed in the switch running configuration.

Before I start on my debugging journey I thought I would ask if anyone may have experienced this problem in the past and if so, how was it resolved?

Thanks in advance for any assistance.

Mark

[Tarik Admani]

Can you doublecheck the certs and make sure the manager cert didnt somehow get imported to the CAS? I have seen issues with AD when the wrong cert is installed the CAS.

Thanks,

Tarik Admani
*Please rate helpful posts*

[premiers-maps]

This problem has now been resolved. It was a combination of two issues.

Issue 1.

After further investigation it appeared as though the issue was related to the SNMP interface index being out of sync between the CAM and our access switches. The command,

snmp ifmib ifindex persist

was missing from one particular switch. Cisco TAC recommended that I remove the switch from the CAM device list, enter the SNMP persist command above then re-enter the switch into the CAM. I did this and it broke all NAC access on this particular switch.

Issue 2.

Once the above was completed NAC broke on that particular switch with the following NAC client error displayed on the workstation.

NAC Invalid switch configuration-OOB Error:OOB client "mac/ip" not found

Somehow, the snmptrapd daemon on the CAM had stopped listening for incoming traps so the CAM was unaware of the new workstation MAC. Via an SSH console session on the CAM, check that the snmptrapd daemon is listening on UDP port 162 as follows:

netstat -an | grep 162

The output should include the following:

udp        0      0 0.0.0.0:162                 0.0.0.0:*

From the CAM via the SSH console, snmpd and snmptrapd were restarted as follows:

/etc/init.d/snmpd restart

/etc/init.d/snmptrapd restart

The log file nac_manager.log was also used to help with this process located at

/perfigo/control/tomcat/logs/

Logging was turned up to the TRACE setting via the CAM web management interface under

Administration -> CCA Manager -> Support Logs

(Dont forget to turn your logging back down when done)

I hope this helps others who may run into this same issue.