Requirements

Components Used

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

• Cisco Identity Services Engine (ISE), Release 1.1.1

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.

Create an Authorization profile

The screenshot below displays the Authorization Profile configuration user interface:

Figure 1. Authorization Profile

1. Click Policy, and click Policy Elements.

2. Click Results.

3. Expand Authorization, and click Authorization profile.

4. Click the Add button in order to create a new authorization profile for central webauth.

5. In the Name field, enter a name for the profile.

6. Choose ACCESS_ACCEPT from the Access Type drop-down list.

7. Check the Web Authentication check box, and choose Centralized from the drop-down list.

8. In the ACL field, enter the name of the ACL on the switch that defines the traffic to be redirected.

9. Choose Default from the Redirect drop-down list.

The Redirect attribute defines whether the ISE sees the default web portal or a custom web portal that the ISE admin created. For example, the redirect ACL in this example triggers a redirection upon HTTP or HTTPS traffic from the client to anywhere. The ACL is defined on the switch later in this configuration example.

Create an Authentication Rule

The screenshot below displays the Authorization Profile configuration user interface:

Figure 2. Authentication Rule

1. Under the Policy menu, click Authentication.

   The following image shows an example of how to configure the authentication policy rule. In this example, a rule is configured that triggers when MAB is detected.

2. Enter a name for your authentication rule.

3. Select the plus (+) icon in the If condition field.

4. Select Compound condition, and then select Wired_MAB.

5. Click the arrow located next to and ... to expand the rule.

6. Click the + icon in the Identity Source field, and select Internal endpoints.

7. Select Continue from the If user not found drop-down list.

This option allows a device to be authenticated (through webauth) even if its MAC address is not known. Dot1x clients can still authenticate with their credentials and should not be concerned with this configuration.

The screenshot below displays the Internal Endpoints user interface:

Figure 3. Authentication Rule-Internal Endpoints

Create an Authorization Rule

Note	There are several rules to configure in the authorization policy. When the PC is plugged in, it goes through MAB; it is assumed that the MAC address is not known, so the webauth and ACL are returned. This MAC not known rule is shown in the following image and is configured in this section:

Figure 4. Authorization Rule

1. Create a new rule, and enter a name.

2. Click the plus (+) icon in the condition field, and select create a new condition.

3. Select Expression from the drop-down list.

4. Select Network Access and expand.

5. Click AuthenticationStatus, and select Equals operator.

6. Select UnknownUser.

7. On the General Authorization page, select CentralWebauth.

   Note

   This step allows the ISE to continue even though the user (or the MAC) is not known. Unknown users are now presented with the Login page. However, once they enter their credentials, they are presented again with an authentication request on the ISE; therefore, another rule must be configured with a condition that is met if the user is a guest user. In this example, If UseridentityGroup equals Guest is used, and it is assumed that all guests belong to this group.

8. Click the actions button located at the end of the MAC not known rule, and choose to insert a new rule above.

   Note	It is very important that this new rule comes before the MAC not known rule.

9. Enter a name for the new rule. Example, IS-a-GUEST.

10. Choose a condition that matches your guest users. Example, InternalUser:IdentityGroup Equals Guest. This is because all guest users are bound to the Guest group (or another group you configured in your sponsor settings).

11. Select PermitAccess in the result box (located to the right of the word then).

    When the user is authorized on the Login page, ISE restarts a Layer 2 authentication on the switch port, and a new MAB occurs. In this scenario, the difference is that an invisible flag is set for ISE to remember that it was a guest-authenticated user. This rule is 2nd AUTH, and the condition is Network Access:UseCase Equals GuestFlow. This condition is met when the user authenticates via webauth, and the switch port is set again for a new MAB. You can assign any attributes you like. This example assigns a profile vlan90 so that the user is assigned the VLAN 90 in his second MAB authentication.

12. Click Actions (located at the end of the 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.

15. Select Network Access, and select UseCase.

16. Select Equals as the operator.

17. Select GuestFlow as the right operand.

18. On the authorization page, click the (+) icon to select a result for your rule.

    In this example, a preconfigured profile (vlan90) is assigned; this configuration is not shown in this document.

    Note	You can use the Permit Access option or create a custom profile in order to return the VLAN or attributes.

Enable the IP Renewal

Note	This task is optional.

If you assign a VLAN, the final step is for the client PC to renew its IP address. This step is achieved by the guest portal for Windows clients. If you did not set a VLAN for the 2nd AUTH rule earlier, you can skip this task.

1. Click Administration, and select Guest Management.

2. Click Settings.

3. Select Guest, and expand Multi-Portal Configuration.

4. Click DefaultGuestPortal or the name of the custom portal you have created.

5. Select the Vlan DHCP Release check box.

   Note	This option works only for Windows clients.

The following screenshot displays the IP Renewal user interface:

Figure 5. IP Renewal

Task Result

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

When the authentication of the Login page is successful, the ISE bounces the switchport through Change Of Authorization, which starts again a Layer 2 MAB authentication.

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

In the ISE authentication logs, the MAB authentication appears at the bottom of the log. Although it is unknown, the MAC address was authenticated and profiled, and the webauth attributes were returned. Next, authentication occurs with the user's login credentials (at the Login page). Immediately after authentication, a new Layer 2 authentication occurs with the username as credentials; this authentication step is where you can return attributes such dynamic VLAN.

Important Note about Router SVIs

The router needs a switch virtual interface (SVI) in order to reply to the client and send the web portal redirection to the client. This SVI does not necessarily have to be on the client subnet/VLAN. However, if the router has no SVI in the client subnet/VLAN, it has to use any of the other SVIs and send traffic as defined in the client routing table. This typically means traffic is sent to another gateway in the core of the network; this traffic comes back to the access switch inside the client subnet.

Firewalls typically block traffic from and to the same router, as in this scenario, so redirection might not work properly. You can allow this behavior on the firewall or create an SVI on the access router in the client subnet.

Important Note about HTTPS Redirection

Routers are able to redirect HTTPS traffic. If the guest client has a homepage in HTTPS, the redirection occurs correctly.

The whole concept of redirection is based upon the fact that a device (in this case, the router) replaces the website IP address. However, a major issue arises when the router intercepts and redirects HTTPS traffic because the router can present only its own certificate in the Transport Layer Security (TLS) handshake. Since this is not the same certificate as the website originally requested, most browsers issue major alerts. The browsers correctly handle the redirection and presentation of another certificate as a security concern. There is no solution for this, you cannot use the router to replace your original website certificate.

Related Documents

Technical Assistance

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.