WebVPN

You are currently browsing articles tagged WebVPN.

Yet another cool feature of the the WebVPN is the ability for the user to browse CIFS shares.  If policy permits, users can openly browse shares and networks.  You can create URL lists which you can then  associate with a specific group policy.  Configuring this access is again pretty straightforward.  A prerequisite to this is that your file server needs to support CIFS/SMB.  On my Windows Server 2003, all that I needed to do to ‘enable’ this feature was add it under ‘add or remove programs’.  Once it was installed, the ASA was able to open up CIFS shares on it for users to access through the portal.  I will not be covering the installation of WINS.  If you need assistance doing that, give it a quick Google.

Getting CIFS running on the WebVPN portal requires the following configuration steps.
-Configure shares on the server and ensure the shares have appropriate permissions
-Configuring a WINS/NetBIOS server on the ASA
-Configuring a DNS server on the ASA
-Configuring an ‘Auto-Signon’ server on the ASA
-Configuring URL list object for the CIFS shares

Configure shares on the server and ensure the shares have appropriate permissions
Again, I’m not going to dive into this one.  Usually, I just ensure that the ‘Everyone’ group has full share permissions and that the specific group has full security permissions.  Test it out from a domain workstation to ensure that the user you are logging into the ASA with can get to the shares locally before we try it on the ASA.

Configuring a WINS/NetBIOS server on the ASA
I’m operating under the assumption that we are using a single tunnel group with multiple group policies.  The RADIUS server is still doing the work of ensuring that at logon, a user gets assigned the correct group policy.  Since we are using a single tunnel group I decided to use the default WebVPN group (DefaultWEBVPNGroup) as the default.  I usually don’t recommend using the default objects but due to the way the ASA handles tunnel group selection I’m forced to use the default group.  Recall that if we don’t give our users the ability to select the tunnel group from a drop down on the default WebVPN logon page, the default WebVPN group is used.  That being said, I will be configuring the WINS server under the default WebVPN tunnel group.

Notes
-Insert your relevant information between <>
-Console prompts are show in green

Configure a WINS Server in the default WebVPN tunnel group
ASA(config)# tunnel-group DefaultWEBVPNGroup webvpn-attributes
ASA(config-tunnel-webvpn)# nbns-server <WINS Server IP Address>
Note: There are other configuration parameters that are assumed as default when you configure the WINS server as done above.   Take a look at the running config after you execute these commands.  You’ll notice you configuration command now looks like this – nbns-server 10.20.30.249 timeout 2 retry 2

Configure a DNS server for a tunnel group
ASA(config)# dns server-group DefaultDNS
ASA(config-dns-server-group)# name-server <DNS Server IP>
Note: If you already have a DNS server defined and you execute the above command the DNS server you specified will be added as a secondary.  If you want to remove the old server issue the ‘no name-server <IP address>’ command prior to specifying your new DNS server.

Configure an Auto-Signon server
This isn’t a required step; however, if you don’t specify your file server as an auto sign-on server, your users will have to logon a second time when they try to open a CIFS share.  Auto sign-on servers are specified on a per group policy basis.  That being said, it makes good sense to define these within the default group policy and allow other policies to inherit this setting.  Word of warning here: If you haven’t noticed, the default group policy (DfltGrpPolicy) does not appear under the running config.  If you weren’t aware of this, you could spend a lot of time trying to find where all of your settings are going!  We will configure this setting in the default group policy and our other policies will inherit it by default.

Assign a auto-sign in server to the default group policy
ASA(config)# group-policy DfltGrpPolicy attributes
ASA(config-group-policy)# webvpn
ASA(config-group-webvpn)# auto-sign allow ip <IP of the server> 255.255.255.255 auth-type ntlm

Configure a URL list for portal page
Unfortunately, this is another item that you can’t configure via the CLI.  The URL list object can be imported, exported, and reverted in the same manner that customization objects can be.  The commands to do so are listed below.

Export WebVPN URL-Lists
ASA#
export webvpn url-list <Name of URL list to be exported> <Destination URL-List name>
Notes: If you simply enter this command, it will look in flash for the file name you specify.  If you’d prefer to do it all in one step insert ‘tftp://<tftp server name>/’ before the destination URL-List name.

Import WebVPN URL-Lists
ASA#
import webvpn url-list <URL-List name> <source URL-List name>
Notes: If you simply enter this command, it will look in flash for the file name you specify.  If you’d prefer to do it all in one step insert ‘tftp://<tftp server name>/’ before the path to source URL-List name.

Delete WebVPN URL-Lists
ASA#
revert webvpn url-list <Name of URL list to be deleted>

Beyond importing, exporting, and deleting the URL-Lists via the CLI, you’ll need to do the rest from the ASDM.  To configure the URL-Lists in the ASDM, open the configuration tab of the ASDM, expand ‘Clientless SSL VPN Access’, expand ‘Portal’, and select ‘Bookmarks’. 
image

As with customizations, there will be a ‘Template’ file by default.  Let’s walk through how to add a bookmark (URL-List).  The list ,as its name implies, is a list of different bookmarks.  The bookmarks can be for a variety of things: CIFS, HTTP, FTP, RDP, VCN, SSH, Telnet, etc…  As of right now, we will just be talking about CIFS bookmarks.  Click the ‘Add’ button at the top of the window.  The ‘Add Bookmark List’ window will appear as shown below.
image

Give the URL list a name and then press the ‘Add’ button on the right-hand side of the screen.
image

This window allows us to define the actual name of the bookmark as well as the location path.  This list is going to be for our marketing group, so we’ll define a bookmark for their share on the file server.  Note, here we are using the DNS domain name of the server.  Make sure DNS is working properly, if the ASA can’t resolve the file server name this won’t work at all.  Enter the bookmark’s name in the ‘Bookmark Title’ text box, select ‘cifs’ from the URL drop-down and then complete the path in the URL text box.  If we wanted to, we could give the URL a subtitle that would be displayed beneath the bookmark title on the portal page.  Additionally, if we wanted an icon to appear next to the bookmark, we could select it from the ‘Thumbnail’ drop-down.  The drop-down will display any available objects that have been uploaded to web content on the appliance.  Press OK to finish adding the bookmark, and then OK again on the ‘Add Bookmark List’ window to finish adding the list.  Make sure to hit ‘apply’ at the bottom of the ASDM window once you are done configuring the list.

Alright, now that we have the URL-list defined let’s add it to our group policy.

Define a URL-List for a Group Policy
ASA(config)# group-policy <Group Policy Name> attributes
ASA(config-group-policy)# webvpn
ASA(config-group-webvpn)# url-list value <URL List Name>

That was the last step, now let’s try it out to see if it works.  Go ahead and login to the portal.  When I login to my marketing user on the main portal screen, I see the bookmark shown below.
image

When I click on the ‘Marketing Share’ link it opens the web-based network browser as shown below.  You’ll notice that our bookmark path is displayed in the address bar and I can see all of my files that are in the marketing share on the server.image

I’m not going to go through what all of the icons on the top of screen do, but I will point out one.  The 9th icon from the left is called ‘Web Folder’.  When you click that icon, it opens a Windows Explorer window for the current directory you are in.  Once it’s open, you can do any and all of the normal file actions that you could do as if you were browsing a mapped network drive.  I will also note that AD file/folder permissions are in effect when you browse the shares through the ASA portal.

Play around with some of the other icons and options in the CIFS viewer.  It’s a pretty cool system and since it’s very straight forward, it can be easy for remote users to understand.

Tags: , ,

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.image

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

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

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

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.  image

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.

Tags: , , ,

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. image

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. image

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

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

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’image

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

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.  image

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’ image

Press NEXT on the welcome screenimage

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. image

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

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

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.image

image

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. image

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

On the next screen press the EDIT PROFILE buttonimage

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

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

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

Press Next on the wizard window
image

Then press FINISH to create the policyimage

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.

image

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. 
image image 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. image

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.image

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.  image

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.

Tags: , , ,

« Older entries