After Upgrade ASA to 9.12 ASA assign wrong group-policy

[jewfcb001]

Hi All

I have plan upgrade ASA  from Version 9.6(4)40  to 9.12(4)37 but I found some issue about ASA assign wrong group-policy to client  . The scenario ASA get radius attribute from ise but asa not assign group-policy from ise . It assign default group policy to client . I'm not sure . It's bug on ASA version 9.12(4)37 or not ? because after rollback to version 9.6 .It's working fine.

Thank you.

[Rob Ingram · Accepted solution]

@jewfcb001 yes a bug on 9.12(4) https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwa08262

Upgrade to fixed version recommend

It's been mentioned before on this forum https://community.cisco.com/t5/vpn/bug-in-asa9-12-4-37-and-asa9-12-4-35/td-p/4517423

[jewfcb001]

@Rob Ingram 

Thank you so much for your information . Now I already open to Cisco TAC for confirm information again.

[Amen]

Hello, how was it with TAC? were they able to do any workaround to fix this issue? or the solution is fixed which is to upgrade to a fixed release , will much appreciate your Reply.

[jewfcb001]

@Amen 

He confirm It's bug and recommend me to upgrade software

[Amen]

I believe somewhere between ASA 9.12.4.4 and 9.12.4.38, there was a change in the order of execution of AAA queries.

We've been able to replicate this behavior with ASA 5585 and Firepower 4140 appliances.

Our AAA process is the following:

- Primary radius authentication + certificate

- LDAP authorization

- Secondary radius authentication

The LDAP authorization query is used to get user group membership, and is then enforced via DAP (if the user doesn't have the necessary group, the connection is denied).

The secondary radius authentication is used for a device compliance check. We get the device's Active directory name from the certificate CN, and query our ISE infrastructure to check the device compliance. If the device is non compliant, the ISE replies with an attribute Class that forces the ASA to apply a specific group policy to quarantine the device.

In previous ASA versions it works fine, because the secondary authentication happens in 3rd, so if a Class attribute is returned it will be properly processed by the ASA.

In the newer versions however, it seems that the order of the queries has changed: the secondary authent is 2nd, and the authorization query third.

This causes an issue for us because as the ldap query is always successful, any kind of attribute pushed by the ISE during the 2nd authent gets overridden and ignored by the ASA, which completely breaks our quarantining process.

I understand that it is the expected behavior that the latest query overrides the previous ones if they conflict, so it is necessary for us that the query order remains the same as before.

Basically what we would like to know is why this change of order happened, and if there is any way to circumvent it.

Could it be linked to this bug fix? https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwa08262

This is problematic for us as we are running a vulnerable version of ASA (9.12.4.4) that we can't upgrade without breaking one of our security processes.