NAC 4.8 Passive re-assessment does not work

[Attila Horvath]

Hi,

After an upgrade to 4.8.0 we'd like to use the passive re-assesment feature with L2 OOB.

Everything is configured correctly according Cisco NAC docs (OOB Logoff enable, User Roles -> Enable Passive Re-assessment).

The OOB logoff feature however works well, eg. when Win user logoff, the user is logged out from NAC.

In the first times the PrA  works well, the CAM report shows failed re-assessment records with red flags, but now it shows nothing PrA related.

(I know, the reports shows only the failed PrA records.).

Try to reload all elements of CAM HA, CAS HA, but nothing has changed.

Any suggestion?

Thanks a lot

Attila

[Federico Lovison]

Hi Attila,

as you correctly say, the PrA reports only the failed re-assessments.

If the Agent doesn't send the PrA report after the re-assessment  interval+2*grace-period, then the user will be logged out from the  network, so if you don't see anything it would probably mean that the PrA was successful.

How did you configure the role, in regard to:

- PrA re-assessment interval

- PrA grace period

- PrA default action on failure

- session timeout

Please note that if the session timeout (role/timers) is shorter than the PrA interval, there will be no PrA reports.

I hope that this is helpful.

If you need for further help with this investigation you may open a TAC Service Request.

Thank you!

Regards,

Federico

--

If this answers your question please mark the question as "answered" and rate it, so other users can easily find it.

[Attila Horvath]

Hi Frederico,

Thanks for your answer.

The timers are now:

- PrA re-assessment interval  - now it's 60min, the minimal value

- PrA grace period  - 5 minutes

- PrA default action on failure - Continue

- session timeout - 5760 min (4 days)

Yes, we assume the PrA feature is OK at CAM/CAS side, because we saw several PrA related lines at CAS debug, like below,

but we are not sure that the agents are handle the PrA packets correctly. As you will see below, the non-compilant client answer in a PrA packet that  "I'm compilant".

Thanks in advance,

Attila

Attached the client log also, unfortunately it is an encrypted file, and we are not able to handle.

************************************************************

The debugs are:

CAS

[root@server logs]# tail -1000000 nac_server.log  | grep PrA

2010-10-07 13:15:29.630 +0200 DEBUG com.perfigo.wlan.web.admin.ClientLoginNACSManager  - ClientLoginNACSManager - processPrALoginRequest query:&user_key=172.18.206.23_49YBG00Y99NDGIC2&userip=172.18.206.23&clientmac=00:23:24:03:62:7E&clickmac=00:00:00:00:00:00&ssip=172.18.99.10&cm=iehvuitr&ops=1&avpid=MicrosoftAS%3A%21%3AeTrustAV&avpname=Windows+Defender%3A%21%3ACA+eTrustITM+Agent&avpversion=1.1.1593.0%3A%21%3A8.1.660.0&avpfeature=AS%3A%21%3AAV&agentversion=null&opswatversion=3.4.13.1&prarequirementversion=0

2010-10-07 13:15:29.631 +0200 DEBUG com.perfigo.wlan.web.admin.ClientLoginNACSManager  - ClientLoginNACSManager - processPrALoginRequest response:

2010-10-07 13:23:31.244 +0200 DEBUG com.perfigo.wlan.web.admin.ClientLoginNACSManager  - ClientLoginNACSManager - processPrALoginRequest query:&user_key=172.18.202.76_3CKCOLLCNPD79AMV&userip=172.18.202.76&clientmac=00:19:99:3B:F7:A1&clickmac=00:00:00:00:00:00&ssip=172.18.99.10&cm=iehvuitr&ops=1&avpid=MicrosoftAS%3A%21%3AeTrustAV&avpname=Windows+Defender%3A%21%3ACA+eTrustITM+Agent&avpversion=1.1.1593.0%3A%21%3A8.1.660.0&avpfeature=AS%3A%21%3AAV&agentversion=null&opswatversion=3.4.13.1&prarequirementversion=0

2010-10-07 13:23:31.244 +0200 DEBUG com.perfigo.wlan.web.admin.ClientLoginNACSManager  - ClientLoginNACSManager - processPrALoginRequest response:

2010-10-07 13:28:05.818 +0200 TRACE com.perfigo.wlan.web.admin.PrAReportEncManager     - PrA enforcement remove user 00:30:05:9A:80:7B

2010-10-07 13:28:05.818 +0200 DEBUG com.perfigo.wlan.web.admin.PrAReportEncManager     - PrA there are expired keys

2010-10-07 13:28:18.148 +0200 TRACE com.perfigo.wlan.web.admin.PrAReportEncManager     - PrA enforcement remove user 172.18.202.52

2010-10-07 13:28:18.149 +0200 TRACE com.perfigo.wlan.web.admin.PrAReportEncManager     - entering PrA enforcement addUser with parameters: 172.18.202.52, 00:30:05:9A:80:7B, false, 1, 4.8.0.32, NAC_WIN_AGENT, 2

2010-10-07 13:28:18.149 +0200 TRACE com.perfigo.wlan.web.admin.PrAReportEncManager     - entering isPrAEnforced with parameters: 4.8.0.32, NAC_WIN_AGENT, 2

2010-10-07 13:28:18.149 +0200 TRACE com.perfigo.wlan.web.admin.PrAReportEncManager     - PrA enforcement is not supported for this user 172.18.202.52 00:30:05:9A:80:7B

2010-10-07 13:30:32.100 +0200 TRACE com.perfigo.wlan.web.admin.PrAReportEncManager     - PrA enforcement remove user 00:30:05:E3:FD:B5

2010-10-07 13:30:32.101 +0200 DEBUG com.perfigo.wlan.web.admin.PrAReportEncManager     - PrA there are expired keys

2010-10-07 13:31:31.196 +0200 TRACE com.perfigo.wlan.web.admin.PrAReportEncManager     - PrA enforcement remove user 172.18.202.52

2010-10-07 13:31:31.196 +0200 TRACE com.perfigo.wlan.jmx.admin.OOBDelayTask            - OOBDelayTask: DONE addOobUser, agent type=NAC_WIN_AGENT proceed to PrA

2010-10-07 13:31:31.196 +0200 TRACE com.perfigo.wlan.web.admin.PrAReportEncManager     - entering PrA enforcement addUser with parameters: 172.18.202.52, 00:30:05:9A:80:7B, true, 7, 4.8.0.32, NAC_WIN_AGENT, 1

2010-10-07 13:31:31.196 +0200 TRACE com.perfigo.wlan.web.admin.PrAReportEncManager     - entering isPrAEnforced with parameters: 4.8.0.32, NAC_WIN_AGENT, 1

2010-10-07 13:31:31.196 +0200 TRACE com.perfigo.wlan.web.admin.PrAReportEncManager     - PrA enforcement adds user 00:30:05:9A:80:7B

Also in CAM debug:

2010-10-07 16:20:13.679 +0200 [TP-Processor21] INFO  com.perfigo.wlan.web.admin.ClientLoginNACMManager  - Received PrA report from nacadmin@corporate.com, 172.18.207.86, 00:23:24:03:BC:44. The report status is true

2010-10-07 16:24:34.513 +0200 [TP-Processor21] INFO  com.perfigo.wlan.web.admin.ClientLoginNACMManager  - Received PrA report from pong@corporate.com, 172.18.201.74, 00:19:99:13:34:81. The report status is true

Note that these users are NON-COMPILANT users, the status reported "true" is absolutely false.

[Federico Lovison]

Hi Attila,

I'll have a look at the Agent logs for the timestamps you pointed out from the CAM and CAS logs.

Just to be clear, what is the requirement you expect to fail on the client side?

After I do this quick check I'll let you know if this can be quickly solved.. if this is not the case and we need for further investigation or this is getting urgent on your side, I would strongly recommend to open a TAC case.

Thanks,

Federico

[Attila Horvath]

Hi Frederico,

At the passive check the requirements are an E-trust antivir running, and a Windows Defender spyware running.

Thanks in advance, we'll open a case if  your solution wont help.

Attila

[Attila Horvath]

Hi,

No, there is not any ACL to blocking SWISS.

As you can see at debugs, there are many SWISS packet received by CAS and CAM after moved client to OOB.

Furthermore the OOB logout feature - when you log out from workstation, it send swiss packets to CAS to log out from NAC - is working absolutely well.

Also when you close the client, it logs you aout from NAC,

So I think the swiss flow is ok.

Attila

[rosenhan]

This may be a dumb question, but do you have an ACL on the access VLAN blocking SWISS packets to the CAS untrusted interface, or the discovery host IP?  This was a recomendation in earlier versions to stop the agent from popping up after you move OOB, when doing the re-assessment you need to allow the SWISS packets through so it will work properly.

[Federico Lovison · Accepted solution]

Hi Attila,

From the Agent debugs I can see that the Agent reports the failure for the following requirements:

%NACAGENT-6-REQUIREMENT_PROC: %[sev=info][func=Rqmt::completeCheck]: Check result of rqmt, [MS: hianyzo Windows frissites WinXP (BKV)]:FAILED

That't the only requirement which fails and this is also reported on the "NACAgentReport.xml" file that is part of the package you uplaoded and it's not encrypted.

I think the problem is actually with the following setting "PrA default action on failure - Continue".

Please set it either to "allow user to remediate" or "logoff user immediately" and check if the behavior is different.

If this doesn't help, please open a TAC service request in order to further investigate this.

Thanks,

Federico

--

If this answers your question please mark the question as "answered" and rate it, so other users can easily find it.

[Attila Horvath]

The issue is resolved, thanks to all.

The PrA is worked everytime - with some restrictions.

We could see PrA related events (logging, kicking off user, force remediation) ONLY when the passive requirement is MANDATORY.

When optional, or audit, you will see nothing, and PrA will not working.