Why ACS Ignore New Network Access Authorization Policy

[Prin12345]

I feel quite strange why ACS ignore my newly added authorization policy for vpn access. The ACS has been fully associated with Microsoft AD. I created the policy in the following steps:

1. Create AD group for VPN login on Microsoft AD.

2. Assign users to the new AD group. Users only belong to the new AD group and no relationship with other VPN group.

3. Select the newly added AD group into ACS with 'Active Directory'-> 'Directory Groups'

4. Greate Authorization Profile for the new VPN authorization policy in 'Policy Elements'->'Authorization and Permission'->'Network Access'->'Authorization Profile'.

5. Create network access authorization policy in 'Access Policies'-> 'Access Services'->'Default Network Access'->'Authorization'. Clicking new and select 'Contains any' in the new VPN group and select the newly added authorization profile in step 4.

6. Save the changes.

7. Configure Cisco Firewall to listen the VPN connect request and authentication in Radius.

When I test the vpn connection, I found that there is no way when I enter correct username and password, the vpnclient always deny and prompt again and again.

I checked on the ACS log and found that ACS success the AD authentication but fail to find an Authorization Policy so it choose default deny access policy.

I am an newer to Cisco ACS, I don't have much idea on solve it, Could you help me? Thanks.

11001  Received RADIUS Access-Request

11017  RADIUS created a new session

Evaluating Service Selection Policy

15004  Matched rule

15012  Selected Access Service - VPN ACCESS

Evaluating Identity Policy

15006  Matched Default Rule

15013  Selected Identity Store - AD1

24430  Authenticating user against Active Directory

24416  User's Groups retrieval from Active Directory succeeded

24402  User authentication against Active Directory succeeded

22037  Authentication Passed

Evaluating Group Mapping Policy

Evaluating Exception Authorization Policy

15042  No rule was matched

Evaluating Authorization Policy

15006  Matched Default Rule

15016  Selected Authorization Profile - DenyAccess

15039  Selected Authorization Profile is DenyAccess

11003  Returned RADIUS Access-Reject

[nspasov]

You connections are passing "Authentication" but are failing "Authorization". The connections are hitting the "default" authorization rule which which is to Deny Access. Thus, something is wrong with your Access Policy that you crated for the VPN based authentications. Something in the policy is not matching, thus the rule is skipped. 

Can you post screen shots of your Access Policies screen and then screen shot of the actual policy details. 

Thank you for rating helpful posts!

[Prin12345]

Thanks for your attention Neno.

The bug has been captured. It was caused by conflict between inner policies. For example, You have created an 'Access Service', for example "Cisco Access Control", and some Network Access Authentication Policy, for example "rule 1". Then some people thought the access service was no longer useful and disable it, but he forget to disable the active Authentication Policy 'rule 1' first. So when my problem happened, one of 'Access Service ' was disable, but the policy 'rule 1' was still enable. There was a conflct between Access Service and Access Policy.

When I restart the ACS, the main process runtime got into 'Not monitor' state, which means ACS start fail. I checked the log and found that RTDaemon start failure because can not read from policy database. After eliminating the conflicted error, and then start runtime. it successed.

I think there should be an imporvement from cisco developers to eliminate such kind of trouble happening. The bug caused our VPN service got down 2 hours.

[nspasov]

Thanks for the info! (+5 from me). Did you actually get a bug/defect ID? If so can you please share it here?

[Prin12345]

Sorry, Neno, I didn't get the bug/defect ID as I don't have the privilege to access some Cisco bug info. I wanted to get some log of errors for you but it has been over by the other logs.

[nspasov]

No problem! Thanks for the info! If your issue is resolved, you should mark the thread as "answered" :)