Cisco Identity Services Engine

Document ID: 113362

PDF Downloads Central Web Authentication with a Switch and Identity Services Engine Configuration Example

Introduction

This document describes how to configure central web authentication with wired clients connected to switches with the help of the Identity Services Engine (ISE).

The concept of central web authentication is opposed to "local web authentication" which is the usual web authentication on the switch itself. In that system, upon dot1x/mab failure, the switch will failover to the webauth profile and will redirect client traffic to a web page on the switch.

Central web authentication offers the possibility to have a central device acting as web portal (here, the ISE). The major difference, when compared to the usual local web authentication, is that the Central web-authentication is shifted to layer 2 along with mac/dot1x authentication. The concept also differs in the way that it is the radius server (again, the ISE) that is returning special attributes indicating to the switch that a web redirection has to happen. The advantage here is to eliminate any delay that was previously necessary for web authentication to occur. Globally, if the MAC address of the client station is not known by the radius server (but other criteria can also be used), the server returns redirection attributes and the switch authorizes the station (via MAB) but places an access-list to redirect the web traffic to the portal. Once the user logs in on the guest portal, it is possible via Change of Authorization (CoA) to bounce the switchport so that a new layer 2 MAB authentication occurs. The ISE can then remember it was a webauth user and apply layer 2 attributes (like dynamic VLAN assignment) to the user. An activeX component can also force the client PC to refresh its IP address.

Prerequisites

Requirements

Cisco recommends knowledge on these topics:

• ISE

• Switch IOS^® configuration

Components Used

The information in this document is based on these software and hardware versions:

• ISE 1.0.4

• 3560 switch running 12.2.55SE3

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to the Cisco Technical Tips Conventions for more information on document conventions.

Configuration

ISE Configuration

ISE configuration is made up of these four steps:

1. Create the Authorization Profile

2. Create an Authentication Rule

3. Create an Authorization Rule

4. Enable the IP Renewal

Create the Authorization Profile

Complete these steps in order to create the Authorization Profile:

1. Click the Policy menu.

2. Click the Policy Elements submenu.

3. Click Results.

4. Expand Authorization, and then click Authorization profile.

5. Click Add in order to create a new authorization profile for central webauth.

6. In the Name field, enter a name for the profile. Here, we chose CentralWebauth.

7. Make sure that the access type is Access Accept.

8. Make sure that the Central Web Authentication checkbox is checked. In the corresponding ACL field, enter the name of the ACL on the switch that will define which traffic will be redirected. In this example, we use redirect. Leave the Redirect field as default. The Redirect attribute allows you to define if the ISE will act as a web portal or if another device will take care of that. For example, our redirect ACL will trigger a redirection upon HTTP or HTTPS traffic from the client to anywhere. We will see that ACL defined later on, on the switch.

   

Create an Authentication Rule

The Authorization profile created previously is used here. Complete these steps in order to create the Authentication Rule:

1. Click Authentication, under the Policy menu. This screenshot is just an example of how to configure the authentication policy rules:

   

   Here, we configured a MAB rule that will trigger when MAC Authentication Bypass is detected.

2. Name your Authentication Rule. Here, we named it MAB.

3. Select the + icon in the condition field to the right of the name. Select Compound condition, and then select Wired_MAB.

4. Click the arrow next to and ... in order to expand the rule further.

5. Click the + icon in the Identity Source field and select Internal endpoints. Below, you will have three combo boxes. Select continue for the line "if user not found". This means that even if a device is not known by its MAC address, it still has a chance to be authenticated (through webauth). Dot1x clients can still authenticate with their credentials and are not concerned by what we are currently configuring.

   

Create an Authorization Rule

If you now go to the authorization policy, there are several rules to configure. When the PC is plugged in, it will go through MAB and we assume that the MAC is not known so we return the webauth and ACL attributes. This is the MAC not known rule.

Complete these steps in order to create the Authorization Rule:

1. Create a new rule and give it a name (for example, MAC not known).

2. Click on the + icon in the condition field. Choose to create a new condition.

3. Expand the expression combo box.

4. Choose Session, and expand it. Click PostureStatus.

5. Select operator Equals.

6. Select Unknown in the right-hand field.

7. Back on the general authorization page, select CentralWebauth (Authorization Profile) in the field to the right of the word then.

   This basically means that the user, or the MAC to be precise, was not known, but since we configured ISE to continue nonetheless, it continues. We return to the CentralWebauth Authorization profile that we configured earlier.

   Unknown users will now be presented with the login page. However, once they enter their credentials and submit, they will come again for an authentication request on the ISE, so we need an extra rule.

   When the user logs in, he/she will hit the IS-a-GUEST rule. We have to define the condition so that it is met when the user is a guest user. In this example, we chose If UseridentityGroup equals Guest. We assume that all our guests belong to this group. As a result, we simply permit access.

8. Click on the actions button at the end of the MAC not known rule, and choose to insert a new rule above. It is important that the IS-a-GUEST rule comes before in the order.

9. Give it a name (for example, IS-a-GUEST).

10. Select a condition that will match your guest users. In this scenario, we chose InternalUser:IdentityGroup Equals Guest because all guest users will be bound to that group called Guest (it can be any other group you configured in your sponsor settings).

11. Select PermitAccess in the result box, to the right of then.

    

    When the user is authorized on the login page, ISE will restart a layer 2 authentication on the switchport and a new MAB will occur. This time, the difference is that an invisible flag is set for ISE to remember that it was a guest-authenticated user. This is the 2nd AUTH rule, and the condition is Network Access:UseCase Equals GuestFlow. This condition is met when the user authenticated via webauth and the switchport is set again for a new MAB. The difference is that now we can assign any attributes we like. Here, we assign the profile vlan90 so that the user will be assigned the VLAN 90 in his 2nd MAB authentication.

12. Click Actions at the end of your IS-a-GUEST rule, and select Insert new rule above.

13. Enter 2nd AUTH in the name field.

14. In the condition field, click the + icon and choose to create a new condition. Select Network Access and click on UseCase.

15. Select Equals as the operator.

16. Select GuestFlow as the right operand.

17. Back on the authorization page, select a result for your rule by clicking on the + icon in the box to the right of then. Here, we assign a profile called vlan90 that was pre-configured and not shown in this document. You can simply select a Permit Access or create a custom profile in order to return the VLAN or attributes that you like.

Enable the IP Renewal

The last point is that if you assign a VLAN, you will need the client PC to renew its IP address. This can be achieved by the guest portal for windows clients. If you did not set a VLAN for the 2nd AUTH rule earlier, you do not need to complete these steps:

1. Click the Administration menu.

2. Click Guest Management.

3. Click Settings.

4. Expand Guest.

5. Expand Mult-Portal Configuration.

6. Click DefaultGuestPortal or the name of a custom portal you may have created.

7. Enable Vlan DHCP Release. This only works for Windows clients.

   

Switch Configuration

interface GigabitEthernet1/0/12
    description ISE1 - dot1x clients - UCS Eth0
    switchport access vlan 100
    switchport mode access
    ip access-group webauth in
    authentication order mab
    authentication priority mab
    authentication port-control auto
    mab
    spanning-tree portfast
    end

!--- We can see a simple mab configuration.
!---Vlan 100 is a vlan giving full network connectivity.
!---We applied a default port ACL which is called webauth. 
!---It is defined as follows:


ip access-list extended webauth
    permit ip any any


!---This is a very poor example since it gives full network access 
!---even if you are not authenticated. You will probably want to restrict access 
!---to unauthenticated users. However, we will see that HTTP and HTTPS browsing 
!---will not work without authentication as per the other ACL. If you remember, 
!---we also configured the ISE to use a redirect ACL called "redirect". Here is 
!---its definition on the switch:


ip access-list extended redirect
permit tcp any any eq www
permit tcp any any eq 443
!
!

!--- This access list has to be defined on the switch and it defines on 
!--- which kind of traffic will the switch do an HTTP redirection. It matches on
!--- "permit". So, in this example, any HTTP or HTTPS traffic that the client  
!--- will send will trigger a web redirection. It could make sense to add other 
!--- ports in case you are using unusual HTTP ports or simply using a proxy. 
!--- Another possibility is to allow HTTP access to some website and only
!--- redirect on some websites. For example if you define in the redirect ACL a
!--- permit for internal webservers only, it means that the clients would be  
!--- able to browse the web without authenticating but would get the  
!--- redirection page if they try to access an internal web server.

If the user is not authenticated yet, the show authentication session int <interface num> will give:

    01-SW3750-access#show auth sess int gi1/0/12

                Interface:  GigabitEthernet1/0/12

              MAC Address:  0050.5600.0003

               IP Address:  192.168.100.13

                User-Name:  00-50-56-00-00-03

                   Status:  Authz Success

                   Domain:  DATA

          Security Policy:  Should Secure

          Security Status:  Unsecure

           Oper host mode:  single-host

         Oper control dir:  both

            Authorized By:  Authentication Server

               Vlan Group:  N/A

         URL Redirect ACL:  redirect

             URL Redirect:  https://w-ise-adm-1.wlaaan.com:8443/guestportal/

    gateway?sessionId=C0A865FE00000006EC31A48B&action=cwa

          Session timeout:  N/A

             Idle timeout:  N/A

        Common Session ID:  C0A865FE00000006EC31A48B

          Acct Session ID:  0x0000000B

                   Handle:  0x95000006

     
   Runnable methods list:

           Method   State

           mab      Authc Success

We can see that despite the successful MAB authentication, the redirect ACL is placed since the MAC was not known by ISE.

Final Result

The client PC plugs in, and performs MAB. The MAC address is not known, so ISE pushes the redirection attributes back to the switch. The user tries to go to a website and is redirected.

The ISE login portal is shown here:

Click Accept in order to accept the policy.

When the authentication of the login page is successful, the ISE, through Change of Authorization, bounces the switchport, which starts a layer 2 MAB authentication again. However, the ISE knows that it is a former webauth client, and authorizes the client based on the webauth credentials although this is a layer 2 authentication. This is the "new" side of things thanks to CWA.

If we look on the authentication logs of ISE, we can see first (at the bottom) the MAB authentication. Although unknown, the MAC address was authenticated and profiled and the web auth attributes were returned. Then, an authentication occurred with the username (this is the user typing his/her credentials in the web auth login page). Immediately, a new layer 2 authentication is performed with the username as credentials. This is precisely the authentication where you can return attributes like dynamic VLAN.

Cisco Support Community - Featured Conversations

Related Information

• Cisco Identity Services Engine
• Cisco Identity Services Engine Command Reference Guide
• Requests for Comments (RFCs)
• Technical Support & Documentation - Cisco Systems