cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3986
Views
5
Helpful
4
Replies

WSA applying incorrect policies

blroberts2
Level 1
Level 1

It identifies the user correctly, but applies the wrong policy.  More info:

 

Say we have 3 access policies: Global, Teachers, and Administrators.  The WSA identifies a user who belongs to the teachers group and should receive the 'Teachers' access policy, but does not and instead receives 'DefaultGroup'.  S680s running 8.5.2-103

4 Replies 4

kussriva
Level 1
Level 1

Hi,

Here are few things you can try:

1). Go to System Administration, Policy Trace. Enter the username which should be part of a specific group and check the result to make sure the  correct AD groups are being identified.

2). Go to the Access Policy created and any Advanced options are configured, try removing them matching just on the AD group.

 


Regards,

Kushagra Srivastava
Cisco PDI Technical Advisors
http://www.cisco.com/go/pdi

1 - Yes, it identifies the correct AD group that the access policy is matching against.  We've had many reports of this issue recently, where it identifies a user but doesn't give them their respective access policy.  We normally had issues where the user field would be blank and we would have to kick the proxies.

 

2 - The access policies are not advanced and are simply matching against an AD group.

 

 

It seems to come and go working/not working for users. 

Quite certain that the issue is hitting the known defect of CSCuu49389 (Race condition prevents authentication group matching) that exist in AsyncOS 8.5.x, 8.8 (version 8 in general).

The conditions of this defect is that it will not match any access policies that has authentication group membership configure in it even though WSA is getting the correct user credentials(information) and most likely will keep falling down to the access policy that does not has group membership in it (normally default group policy).

This situation can occurs if there are changes in the appliance that required the prox process to be restarted such as global config change, publish from SMA, reboot, updates, etc.

The immediate work around is to "kick" the proxy from CLI -> diagnostic -> proxy -> kick to refresh the connections.

This defect has been verified fixed in version 8.5.3, however this version still at ED release but available if you want to test it (create TAC case and request it for them to manually provision this version for you)

blroberts2
Level 1
Level 1

Updated to version 9.0.0-485 and seeing if the issue is corrected.