cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8857
Views
3
Helpful
2
Replies

Allow AD password change via AnyConnect

scottsanderstof
Level 1
Level 1

I'm looking for some help getting AD password change via AnyConnect and Cisco ISE 2.2 working.

I'm manually migrating from an old Cisco Secure ACS installation to Cisco ISE 2.2.  The old ACS service acts as our RADIUS server for third party vendor VPN authentication and access.  We use it for its ability to push DACLs and limit what the vendors have access to once connected to the VPN.

One thing we are doing different in ISE vs ACS is using Active Directory for the user store.  In ACS, we just created local accounts for each vendor.  I'd like to provide the vendors the ability to change their password when it expires or if we mark their account to ask for a new password on password change; however, I'm having problems.  I already have "Enable Password Change" marked on the external AD identity store.  It's due to my configuration on the Authentication and Authorization profiles.

I had to change the default configuration because I was noticing that the default policies were allowing access to our entire network as long as there was successful authentication using the account credentials of any account in our AD domain.  It was defaulting to the "Default Rule" Authentication Policy with the default of "All_User_ID_Stores" and it was hitting the "Basic_Authenticated_Access" default Authorization Policy which had an action of "PermitAccess".  We don't want that.  We only want people in certain AD groups to be able to connect, and when they do we want each of them to get a DACL associated with the particular ISE-related AD group they are a member of.

Here's what I did to mitigate the behavior of allowing everyone total access:

Changed the "Default Rule" Authentication Policy so that "use" is set to "DenyAccess".

Duplicated the "Basic_Authenticated_Access" Authorization Policy and set the permission to "DenyAccess" and disabled the built-in "Basic_Authenticated_Access" rule.

Unfortunately, due to the conditions I have configured on my AnyConnect-and-AD-group-related Authentication and Authorization Policies, this seems to break the password change behavior.  When logging in using the AnyConnect web interface, the user is prompted to enter a new password, but they get the error "You have no dial-in permission" when they try to submit the new password.  In looking at the ISE RADIUS logs, I see that the Failure Reason is "15039 Rejected per authorization profile", which is "DenyAccess" from my duplicated "Basic_Authenticated_Access_copy" Authentication Policy.

I am sure this is at least partly due to the conditions I have selected on my custom Authorization Policies.  I have all of them configured to look at individual AD groups, the source of the authentication request (using the Device-Type attribute), and the RADIUS client Type (either "Clientless-SSL-VPN" or "AnyConnect-Client-SSL-VPN").  I'm sure it's the latter part that is resulting in the password change traffic not matching and then hitting one of the default rules further down in the policy list.

How can I configure these policies to limit the conditions of the traffic matched, but still allow for the use of the DACLs based on AD group membership?  In the session trace of the failures, I didn't see any attributes I could really use except that Microsoft.MS-CHAP-NT-Enc-PW has a lot of hexadecimal data.

Help!  Thank you!

1 Accepted Solution

Accepted Solutions

Scott, instead of sending DenyAccess for the default rules, try crafting a new AuthZ profile that sends PermitAccess with dACL that simply denies everything 'deny ip any any'. This way, you are not allowing any access to the network, yet it provides access for the password change to happen.

View solution in original post

2 Replies 2

scottsanderstof
Level 1
Level 1

The VPN authentication itself works great.  I'm just having trouble with the password change portion concurrently with policies that attempt to really narrowly match the traffic.

I can get all of the VPN authentication, DACL, and password change working if I remove the conditions that look at the "Cisco-VPN3000.CVPN3000/ASA/PIX7x-Client-Type" attribute to see if it matches either "Clientless-SSL-VPN" or "AnyConnect-Client-SSL-VPN".  I'd be glad to add a condition like "Password-change" or whatever in addition to the client type if I could, but I don't see anything like that in the session trace.

Scott, instead of sending DenyAccess for the default rules, try crafting a new AuthZ profile that sends PermitAccess with dACL that simply denies everything 'deny ip any any'. This way, you are not allowing any access to the network, yet it provides access for the password change to happen.