topic Why ACS Ignore New Network Access Authorization Policy in Network Security

Why ACS Ignore New Network Access Authorization Policy

Prin12345 — Fri, 21 Feb 2020 13:28:32 GMT

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

You connections are passing

nspasov — Sun, 17 May 2015 06:17:37 GMT

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!

Thanks for your attention

Prin12345 — Tue, 19 May 2015 01:40:14 GMT

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.

Thanks for the info! (+5 from

nspasov — Tue, 19 May 2015 02:01:27 GMT

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

Sorry, Neno, I didn't get the

Prin12345 — Tue, 19 May 2015 03:50:05 GMT

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.

No problem! Thanks for the

nspasov — Wed, 20 May 2015 02:44:19 GMT

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