We’ve done some pretty neat stuff with the ASA so far.  If you have been following along you probably have a couple of tunnel groups configured and possibly some RADIUS authentication against a MS AD database.  Now it’s time for the curve ball.  We are going to create a single tunnel group that all WebVPN users will use and apply different group policies against each.  In previous examples we configured customization, assigned the customizations to tunnel groups, and then assigned aliases and group URLs to the tunnel groups.  This worked well and there isn’t anything wrong with configuring this way.  In most cases, it works best with local authentication as you can configure each user with  group-lock for their specific tunnel group.  You can even use RADIUS for authentication, but if you do there isn’t a very good way to lock a user into a specific tunnel group.  So, rather than configure separate tunnel group’s for each group of users we are going to define separate group policies for each group of users.  Why would we do this?  Because we can configure IAS and the ASA to log a user into a specific group policy and customization based on their AD group membership.  How cool is that?  Let’s get right into it.  We’ll keep the IAS configuration that we have thus far but I’m going to start over with tunnel groups and group policies on the ASA.

Configure IAS with attribute 25
The first step is going to be to modify our current remote access policy and add another one.  We’ll stick with our sales and marketing example.  So at this point in AD (Active Directory, you knew that already right?) we should have the following users and groups.

GroupSales – Security Group
GroupMarketing – Security Group
Sales – Sales user that is a member of GroupSales
Marketing – Marketing user that is a member of the GroupMarketing

Let’s start by modifying our existing sales remote access policy in IAS.  If you don’t know how to create the remote access policy, refer to my last post called “Configuring RADIUS authentication for WebVPN”.  So open up IAS on the server and locate your sales remote access policy, right-click on it and open up properties.

We want to add an attribute so click on the ‘Edit profile’ button.

On the profile window select the ‘Advanced’ tab and click the ‘Add…’ button.

On the ‘Add Attribute’ window select the ‘Class’ attribute and press the ‘Add’ button

On the ‘Attribute Information’ window you need to add the group policy name for the group that you are working on.  For instance, later we will create two group profiles, one called GP_Sales for the sales group and another called GP_Marketing for the marketing group.  Since we are working on sales and we want users of the sales group to use GP_Sales, we’ll specify that as attribute 25 (class) here in IAS.  If you are confused, just stay with me for a moment; I’ll summarize shortly.  When you specify the group policy name you NEED to make sure that you enter it in correctly.  The string value needs to be entered as shown below in this format ‘OU=<Group Policy Name>;  After you have entered your value press OK, close the ‘Add Attribute’ window, press OK to close your edit profile window, and OK one more time to close the Edit Remote Access Policy window. 

That’s the entire configuration for a single remote access policy.  Now you need to follow these exact same steps to create/modify your marketing remote access policy.  So now that we have at least two remote access policies configured, I’ll review how this works from the IAS side of things.  You have two remote access policies, one for sales and one for marketing.  Each remote access policy is looking for a particular attribute about a user so that it can make a decision as whether or not to grant access.  If you’ll recall both of our remote access policies specify the windows group name as their policy conditions.  When an authentication request comes into the IAS server it runs through its list of remote access policies to see if it can find a match.  The policies are evaluated in a similar manner to how a router or firewall evaluates a ACL; it runs through the list, line by line, looking for a match.  If it can’t find one, there is an explicit deny waiting as the last line in the list.  Same deal with the remote access policies.  We have two policies that are looking for users, that are in either the windows group GroupSales or GroupMarketing.  If your AD user isn’t a member of either of those groups, they aren’t getting authenticated.  So why can’t we just add these all into remote access policy?  Because we need to specify separate class attributes in each remote access policy.  The ASA is going to see the class attribute that is specified for the policy and throw the user into that specific group policy.  Let’s continue with the ASA configuration. I’m going to build the group policies from scratch, but assume you still have a sales and marketing customization loaded on your ASA.  The notes section of each command with have the actual command I execute.

Notes
-Insert your relevant information between <>
-Console prompts are show in green
-Text in blue are variable names I made up, feel free to change them

Configure the group policies
ASA(config)# group-policy <Group Policy name> internal
Notes:group-policy GP_Sales internal
ASA(config)# group-policy <Group Policy name> attributes
Notes:group-policy GP_Sales attributes
ASA(config-group-policy)# webvpn
ASA(config-group-webvpn)# customization value <Customization name>
Notes:customization value Sales

Now configure your marketing group in the same way, with its respective group policy and customization name.  Since we will be using one tunnel group and we don’t want to give our users the ability to select which tunnel group they use, we need to do two more things.  Configure the DefaultWEBVPNGroup to use our MS IAS authentication group and tell the tunnel group not to display the tunnel group drop down

Configure the DefaultWEBVPNGroup to use you IAS authentication group
ASA(config)# tunnel-group DefaultWEBVPNGroup general-attributes
Notes:tunnel-group DefaultWEBVPNGroup general-attributes
ASA(config-tunnel-general)# authentication-server-group <Your IAS AA group name>
Notes:authentication-server-group WindowsIAS

Configure the tunnel group to no show the tunnel group drop down
ASA(config)# webvpn
ASA(config-webvpn)# no tunnel-group-list enable

And that’s it; time to test it out and see if it works!  Browse to your default WebVPN logon page (no group URLs if you still have some defined) and logon with the sales user.  You should see your sales customization on the portal page.  Logout and try logging in as the marketing user and you should see the marketing customization.  If you get the default logon page for WebVPN (no customizations) check to make sure you have your group policy names correct both in IAS and the ASA.  They are case-sensitive and you need the semi-colon after the attribute name.

In the next posts we are going to do some more advanced portal customization.

So we decided that we have too many users to keep track of locally on the ASA.  What are some other options?  There are a variety of AAA methods we can use.  My personal favorite is RADIUS attached to a Microsoft/Windows IAS (Internet Authentication Server).  In Server 2008 I believe it’s called NPS (Network Policy Server) which we will hopefully cover how to configure at some point.  Right now we are going to configure RADIUS with a 2003 domain controller for authentication.  Another option would be LDAP but I’m not a huge fan of it; It seems to work well until it breaks, then it’s a huge pain to troubleshoot and get working again.  So let’s get right into the configuration.

Notes
-Insert your relevant information between <>
-Console prompts are show in green
-Text in blue are variable names I made up, feel free to change them

Define an AAA server
ASA(config)# aaa-server WindowsIAS protocol radius
ASA(config-aaa-server-group)# aaa-server WindowsIAS host <IAS Server IP Address>
ASA(config-aaa-server-host)# key <IAS Key>

Configure RADIUS on the MS Server
The first thing we need is a server 2003 domain controller.  Once we have that, we need to install IAS on top of it.  IAS will do the RADIUS processing for us.  In order to install IAS go to Control Panel, Add or Remove Programs, and select ‘Add/Remove Windows Components’ from the left-hand side bar.  In the Windows Component Wizard scroll down to ‘Networking Services’ and double click on it.

Note: Prior to beginning this configuration I created two users in AD. One called marketing and one called sales.  Additionally I have two groups configured SalesGroup and MarketingGroup.  Each user is a member of their respective group.  If you want to follow along with the example please add these users and groups now.

Double clicking on ‘Networking Services’ should bring up a second window.  On the second window find IAS and select the check box next to it.  Then press OK to close the Networking Services window.  Back on the Windows Components Wizard window press NEXT to begin the installation.

Wait for the installation to complete.  Once the installation is complete press FINISH and close Add/Remove programs.

Now that IAS is installed we can begin configuring it.  To open IAS locate it under Administrative Tools.

The first thing to do is to configure a new RADIUS client.  In our case this client will be the ASA.  To configure the client right-click on RADIUS clients and select ‘New RADIUS Client’

On the New Radius Client window enter a name for the RADIUS client as well as the devices IP Address.  Then press NEXT.

On the next screen select ‘Cisco’ from the Client-Vendor drop down and then enter the secret you configured on the ASA when you defined the AAA server.  Then press FINISH. 

Technically the next step here would be to configure logging.  I usually don’t configure logging beyond what’s configured in the default settings.  All of the requests (approved and denied) are logged in the servers system event log.  That’s usually good enough for me.  So let’s jump right into configuring the remote access policy for our connection.  Select ‘Remote Access Policies’ from the left-hand side bar.  On the right you should see the two default policies.  Let’s start from scratch; right-click on each and select DELETE.  Then right-click on the Remote Access Policies and select ‘New Remote Access Policy’

Press NEXT on the welcome screen

On the next screen select the option for ‘Setup a custom policy’ and give it a name.  Keeping with our example, I’ll call this policy ‘Sales’.  Then press NEXT.

On the next window press ADD to add a new policy condition. 

In the Select Attribute window scroll down to ‘Windows Group’ and press ADD.

After you press ADD, a new window will pop up called ‘Groups’.  Click the ADD button once again and select a windows security group from Active Directory.

Press OK on the Select Groups window and OK on the Groups window to return to the New Remote Access Policy Wizard.  You should now see your group listed in the Policy Conditions window as shown below. Press NEXT.

On the next screen ensure that ‘Grant remote access permission’ is selected and Press NEXT

On the next screen press the EDIT PROFILE button

On the Edit Dial-in Profile window select the Authentication tab and ensure that ‘Unencrypted authentication (PAP, SPAP)’ is checked

Now select the Encryption tab and check the ‘No Encryption’ check mark.  Then Press OK

When you press OK, you will receive the following error message.  Just press NO to return to the wizard.

Press Next on the wizard window

Then press FINISH to create the policy

Now that we have successfully configured RADIUS let’s test it on the ASA to ensure that it’s working correctly.

Testing the RADIUS Configuration
ASA# test aaa-server authentication WindowsIAS username <username> password <password>
Server IP Address or name: <IP address of RADIUS Server that you defined>
INFO: Attempting Authentication test to IP address <IP you entered> (timeout: 12 seconds)
INFO: Authentication Successful

Checking the severs system log for IAS events
When you perform any sort of authentication (including the test we did above) against IAS it logs an event in the server’s System log.  Let’s take a brief look at a couple of events that can appear in the log and I’ll show you how easy it is to troubleshoot IAS/RADIUS issue.   The below screen shot is of my system log.

As you  can see there are two events from IAS.  Successful RADIUS authentication requests are logged as type informational and event ID 1.  Failures are logged as type warning and event ID 2.  Let’s look at both of the actual events and see why the first one failed. 
The failure is shown on the left.  To determine the cause of the failure, I scrolled down to the ‘Reason’ part of the event.  I simulated this error by checking the ‘User must change password at next logon’ attribute underneath the users AD account settings.  Once I unchecked the settings and ran the test on the ASA again, I got the event on the right.  The first line indicates my user was grant access.  Bottom line, if you are having IAS issues, check the system log.  If there aren’t any IAS events it’s most likely a misconfig on the ASA or the IAS server.  If there are events, it’s usually pretty easy to determine the issue.

As I mentioned in my last post, an advantage of using RADIUS configured with a MS domain is that you get it’s password policies along with it.  For instance a default domain group policy on a 2003 MS Server requires that the password uses ‘password’ complexity’.  In other words it has to meet certain standards such as containing a certain number of letters, numbers, and symbols.  Additionally, you get the password expiration policy which forces the user to change their password every so often.  The screen shot below shows the password policies that are available in the default domain policy on a MS Server.  I’m not going to dig into configuring group policies on a MS server on this blog, but I will give you piece of advice: download the ‘group policy management tool’ if you are working in server 2003.

However a problem does exist with this configuration.  If you have RADIUS setup on the portal and you have some users defined in AD just for portal authentication, they might never logon to a windows PC (on the domain) to see warnings about their password expiring.  At the very least, they wouldn’t have the facilities to change the password.  No fear, Cisco built this functionality into the ASA.  One simple command enables password management that processes all of the warnings and errors to the user at the logon prompt.  Password management is a function of a tunnel group.

Enable Password Management on the Logon page
ASA(config)# tunnel-group <Tunnel Group Name> general-attributes
ASA(config-tunnel-general)# password-management
OR
ASA(config-tunnel-general)# password-management password-expire-in-days <Days prior to expiration you want to warn the user>

If you just enable password management by simply entering ‘password-management’, the ‘password-expire-in-days’ value is defaulted to a value of 14.  If you want to warn the user on the day of expiration enter a value of 0 in the ‘password-expire-in-days’ value.

Now that we have all of this configured, let’s configure our tunnel group to use RADIUS.

Modify your tunnel group to add the AAA server
ASA(config)# tunnel-group <Tunnel Group name> general-attributes
ASA(config-tunnel-general)# authentication-server-group WindowsIAS

Now let’s browse externally to the ASA logon page and test it all out.  I applied the AAA server to my sales tunnel group.  Remember, AAA is defined per tunnel group.  If you want all of your users to use RADIUS and have multiple tunnel groups you need to define RADIUS in each.

After entering the credentials and clicking ‘Login’ I was able to successfully gain access to the portal page.  A quick check of the IAS server’s system log confirmed that my RADIUS request was granted access.  As a last note, try out the password management feature if you enabled it.  Go into AD and check the ‘User must change password at next logon’ under the sales user’s account settings.  Now let’s try logging in again. 

The ASA caught onto the fact that the users password was expiring in AD and is giving us the opportunity to change it now.  Additionally since it’s an AD password it needs to meet all of the AD password policies.  Pretty slick huh?  After I entered my new password, I confirmed that it changed on the AD side by logging in to a local computer on the domain with my new credentials.  In the next post we’ll be talking about pulling attributes from AD and processing them during logon.