For an offline or printed copy of this document, simply choose ⋮ Options > Printer Friendly Page. You may then Print, Print to PDF or copy and paste to any other document format you like.
Author: Jason Kunst
Table of Contents
Figure1: Cisco Identity Services Engine
Cisco ISE is a leading, identity-based network access control and policy-enforcement system. It is a common policy engine for controlling end-point access and network device administration for enterprises. ISE allows an administrator to centrally control access policies for wired, wireless, and VPN endpoints in a network.
ISE builds context about endpoints, including users and groups (Who), device type (What), access time (When), access location (Where), access type (Wired/Wireless/VPN) (How), threats, and vulnerabilities. By sharing vital contextual data with technology partner integrations and the implementation of a Cisco Software Defined Segmentation policy, ISE transforms a network from a conduit for data into a security enforcer that accelerates the time-to-detect and time-to-resolution of network threats.
About This Guide
This guide describes the process and best practices for configuring ISE with a Cisco Wireless LAN Controller (WLC) or a Cisco switch to provide guest access.
This guide is designed to be used in an environment where WLC and ISE have already been set up.
The purpose of this guide is to help you with common setup and deployment questions, and to describe
configurations with a Cisco WLC, Cisco switch, and ISE. Note that the guide does not cover more complex configurations, such as configuring load balancing or foreign/anchor controllers.
Figure2: ISE for Guest Implementation Flow
There are four major sections in this document. The Define section shows how to define problem areas, plan for deployment, and other considerations; the Design section shows how to design a guest access network; the Deploy section provides guidance about the various configurations and best practices; and lastly, the Operate section shows how to manage a guest network controlled by Cisco ISE.
This guide provides information about the following configurations:
This guide does not cover the following topics:
When people outside your company attempt to use your company’s network to access the internet or the resources and services in your network, you can provide them with network access using Guest Access portals. Guests typically include authorized visitors, contractors, customers, or other temporary users who require access to your network.
The two types of Guest Access portals supported by this guide are:
A Hotspot Guest Portal provides network access to guests without requiring usernames and passwords. This type of guest access eliminates the overhead required to manage each individual guest account. When guests connect to a network, they are redirected to the ISE Hotspot Guest Portal where they must accept an Acceptable Use Policy (AUP) to gain access to the network, and eventually, the internet.
Guest Access with Credentialed Guest Portals
A Credentialed Guest Portal requires guests to have a username and password to gain access. Using a self-registration portal, guests can create their own account credentials, which they can then use to log in to the Guest portal. Credentials can also be created for a guest by a sponsor. A sponsor can be an employee or a lobby ambassador. When guests connect to a network, they are redirected to a portal. They log in to that portal using the credentials that they created through self-registration, or were provided by a sponsor. After guests log in, they may be required to accept an AUP before they can access the network, depending on the portal. Access can also be set up using a Sponsored Guest Portal, which requires users to have the credentials created by a Sponsor.
For more information about Guest portals and features, refer to the “Cisco Guest Access” section in the Cisco Identity Services Engine Administrator Guide.
ISE guest access requires base license for each guest endpoint. For more information about licensing, see the community page for ISE Licensing.
A frequent question that is asked is about safely deploying an ISE Guest portal in DMZ. While multiple options exist, it is the customers' prerogative to determine the best approach, based on their requirements. The following are some general guidelines:
|ISE PSN in the DMZ — You must enable communication between the PSN and the PAN and MNT nodes for database synchronization. Note that in this context, this PSN is only used for Guest portals. You should use more than one PSN for redundancy. Your sponsors connect to a PSN inside the network to create guest accounts.|
|ISE PSN with an interface in the DMZ - You will have a separate interface on the internal ISE PSN for Guest portal traffic by having an interface in the DMZ. Here, you will only allow communication to the PSN from the wireless controllers and clients for RADIUS and the Guest portal. This same PSN can be utilized to offer the Sponsor portal. Two PSNs with interfaces in the DMZ are recommended for redundancy.|
|Separate ISE deployment in the DMZ – For customers who are extremely security-conscious, you can dedicate a separate ISE deployment for handling guest access. Depending on how many locations you want to service, you could start with a high-availability standalone setup with 2 PAN +MNT/PSNs located in your DMZ.|
If a PSN loses contact with the PAN, you will see one of behaviors listed below. This list provides an overview of the major issues you may encounter. We recommend that you plan for WAN redundancy to mitigate these risks.
The wireless controller team has incorporated configuration options in their GUI in order to implement best practices for quicker configuration of ISE. These changes were introduced in Version 8.5, which is the version referred to in the configuration sections of this document. In the WLC GUI, see the following options and associated shortcut information:
Please reference TAC Recommended AireOS Builds for best code version.
|Note: The NAC State setting of ISE NAC (RADIUS NAC, prior to AireOS Version 8.5) enables ISE to send a CoA request, which allows a user to authenticate and access the network. Essentially, this setting gives ISE the ability to change the state of a client on the fly, without requiring a new session. For example, after being redirected to ISE for portal authentication, the client is authenticated and allowed access to the network. Please reference TAC Recommended AireOS Builds for best code version.|
For more information about best practices and timers with Cisco Wireless Controller, refer to How To: Universal Wireless Controller (WLC) Configuration for ISE.
When connecting to guest networks with Apple iOS devices, Apple uses a mini pseudo browser called the Captive Network Assistant (CNA). This browser is not the native Safari browser. The CNA pops up automatically when the device gets into a captive portal situation. Sometimes, the CNA window is hidden behind a splash page, such as a hotspot or Guest portal, and the users cannot see it, and cannot gain access to the internet. Cisco ISE supports CNA only for basic guest access. The CNA browser may be limited in its capabilities to support BYOD (device onboarding), social login for guest access, and SAML SSO-based logins. Hence, it is not recommended for these workflows.
If you have to suppress the Apple CNA, you can do so per WLAN, or globally, using the captive portal bypass feature on WLC. For most guest use cases, you do not have to enable the bypass feature. For more information, see the following links:
Another frequently asked question is whether you can change the IP addresses of the guests after they log in to the portal, for example, if you have distinct VLANs for guests, contractors, and employees. ISE has no control over the endpoints when it is connected to an open network because there is no supplicant involved. In 802.1x networks, the supplicant has the intelligence to release/renew the IP address on the machine. However, we recommend that you do not change the IP address after login, for the following reasons:
In order to support network separation, we recommend that you set up a Guest WLAN with 802.1X, set up guest types as Guests and Contractors, and allow them to bypass the web login. However, note that you will not be able to utilize the settings in the guest types, such as allowed login hours, or how many times a user can log in to the portal with different devices.
If it is absolutely necessary to separate guest traffic with web authentication and not 802.1X, we recommend that you set up a low DHCP timer for initial network access so that when a device switches networks, it can renew its IP address in the new VLAN. Alternatively, you can use Cisco Software Defined Segmentation solution, and deploy scalable group tags for segmentation.
At the time of publishing this document, we have the following caveat:
We recommend that your deployment model use wireless auto-anchor mobility (also called guest tunneling), where guest traffic is tunneled through the anchor controller. This model requires the controller to be in the DMZ.
This document describes a high-level recommendation; it does not discuss the different wireless models. For more information about wireless design and WLC auto anchor, see the following sections in the How To: Universal Wireless Controller (WLC) Configuration for ISE.
Because of the caveat specified in CSCul83594, you cannot enable RADIUS accounting on two WLCs. Both WLCs sending accounting start and stop messages with different session IDs, will confuse ISE. When this occurs, an "Error 500" message is displayed to end users (typically, when they are redirected to the ISE portal). This issue occurs on a per WLAN basis. If you have other WLANs that are not using ISE services, this issue might not occur. The issue lies with the new simplified configuration check box on the WLC named “Apply Cisco ISE Default Settings”. When enabling the check box, it automatically configures an authentication server and an accounting server with the same IP and settings. The same settings are ported to the WLAN configuration too. The problem occurs when you configure enable the checkbox on both WLCs. Accounting needs to be configured on the foreign controller.
In WLC version 8.6+, the session id will be shared between anchor and foreign controllers and accounting will then be possible to enable on both.
Please reference TAC Recommended AireOS Builds for best code version.
If you are using FlexConnect, we recommend that you use central switching mode. Local switching does not support URL-based DNS ACLs. If you want to use FlexConnect Local switching, for example, branch, be aware of the following caveat:
Without using URL-based ACLs, you cannot easily implement ACLs that open up cloud-based SSO providers, such as SAML or social media access. One workaround is to permit access to all the internet and enable URL-redirect only for internal sites (for example, for employee SAML SSO). Writing IP ACLs for social media access could be cumbersome because they typically resolve to several IP addresses.
This section shows how to configure the necessary security settings on the WLC to work with ISE. If you are working with a switch, see Configure a Switch for Guest Access.
|Note: This section provides information about how to set up a single controller. If you want to create a configuration using a foreign anchor model, see the documents listed under Wireless Deployment Models.|
The RADIUS Authentication Server window is displayed, as shown in the following figure:
|Note: Checking the “Apply Cisco ISE Default Settings” check box enables support for CoA, which is required for ISE. It also duplicates this setting for RADIUS Accounting.|
ISE will be automatically configured as a RADIUS accounting server, as shown in the following figure:
From the drop-down list on the right side of the window (see the figure below) choose Create New and click Go.
From WLC Version 8.3.102, ISE guests with WPA+PSK are supported. This is not related to Identity PSK (IPSK). For more information, see Release Notes for Cisco Wireless Controllers and Lightweight Access Points for Cisco Wireless Release 188.8.131.52.
Please reference TAC Recommended AireOS Builds for best code version.
This allows enterprises to protect their network from users on other floors or in the parking lot from connecting to your OPEN SSID, and exhausting the DHCP pools or ISE base licenses. To enable this feature, perform the following procedure:
If you are using local switching (see Wireless Deployment Models), leave this enabled.
When you apply Cisco ISE Default Settings, it enables Captive Portal Bypass, which suppress the Apple mini browser. We recommend that you disable Captive Portal Bypass to make the mini browser (Captive Network Assistant) pop up automatically when connecting to a guest network, and use it for guest access.
This section describes how to configure an ACL on the WLC. The objective is to configure an ACL that allows guest clients to access guest services.
198.18.133.27 is the IP address of ISE in this example. We recommend that you use your ISE IP address, and add all the PSN nodes that are servicing the Guest portal with this ACL. If you change the TCP port number for your Guest portal, make the same change here (from 8443 to the new port number).
In the above example, 198.18.133.0/24 is the internal network that guests cannot access. If your guest network is in a DMZ, you will not have to limit access to your internal network since the DMZ is outside the internal network.
This section covers the minimal required configuration on a Catalyst Series switch to work with ISE guest. This was validated with IOS and IOS-XE platforms.
When using network devices with ISE, make sure they are running the minimum code version provided in the corresponding compatibility guide. If you need a higher code revision, you should test it in a lab before going into production. The ISE team does not test all the devices with all the code versions. If you need additional support, reach out to the respective device teams at Cisco.
If your switch is not listed, and you have a question about its compatibility with ISE, see the community post, Does ISE Support My Network Access Device?
Additionally, if deploying with SGT’s then review the validated hardware and software versions within the latest capability matrix.
Use the following links for information about general best practices on Cisco Catalyst switches with ISE.
Your switch must meet the following requirements to work in an ISE guest setup:
This sample configuration gives full network access even if the user is not authenticated; therefore, you might want to restrict access to unauthenticated users.
In this configuration, HTTP and HTTPS browsing does not work without authentication (per the other ACL) since ISE is configured to use a redirect ACL (named redirect). Here is the definition on the switch:
ip access-list extended ACL_WEBAUTH_REDIRECT
deny ip any host <ISE ip address>
permit TCP any any eq www
permit TCP any any eq 443
This access list must be defined on the switch in order to define on which traffic the switch will perform the redirection. (It matches on permit.) In this example, any HTTP or HTTPS traffic that the client sends triggers a web redirection. This example also denies the ISE IP address so traffic to the ISE goes to the ISE and does not redirect in a loop. (In this scenario, deny does not block the traffic; it just does not redirect the traffic.) If you use unusual HTTP ports or a proxy, you can add other ports.
Another possibility is to allow HTTP access to some web sites and redirect other web sites. For example, if you define in the ACL a permit for internal web servers only, clients could browse the web without authenticating but would encounter the redirect if they try to access an internal web server.
The last step is to allow CoA on the switch. Otherwise, the ISE cannot force the switch to reauthenticate the client after the login to the guest portal.
aaa server radius dynamic-author
client <ISE ip address> server-key <radius shared secret>
This command is required for the switch to redirect based on HTTP traffic:
ip http server
This command is required to redirect based on HTTPS traffic:
ip http secure-server
These commands are also important:
radius-server vsa send authentication
radius-server vsa send accounting
Here is the switchport configuration
description ISE Port
switchport access vlan 100
switchport mode access
authentication order mab dot1x
authentication priority dot1x mab
authentication port-control auto
authentication timer reauthenticate server
authentication timer inactivity server
authentication violation restrict
dot1x pae authenticator
dot1x timeout tx-period 10
spanning-tree bpduguard enable
Now that you have configured your network access device to work with ISE web authentication, you must complete the necessary steps on ISE.
Perform the following procedure to add a wireless controller or switch to ISE:
If software defined segmentation is deployed then enable the Advanced TrustSec Settings and complete the details as explained in the following guide: Cisco TrustSec Quick Start Configuration Guide.
From ISE 2.3, the only way to configure authentication and authorization rules is to use Policy Sets. By default, sample authorization rules are available for credentialed guest access. This section describes how to enable these rules.
|Note: Like other built in policies, an SGT is applied to the Guest Access by default. This can be utilized in your Software Defined Segmentation story, for more information please see the Segmentation and group based policy resources community.|
Guest-access authorization with ISE happens in two stages. The initial flow is a MAC authentication Bypass (MAB), where ISE authorizes the endpoint for URL redirect to itself. This results in the web traffic from the guest user’s device to be redirected to the ISE Guest portal. Note that at this stage, the network device (switch or WLC) and ISE will track the endpoint’s network connection with a common session ID. When a guest user logs in with guest credentials, the guest user ID is merged with the existing MAB session. This part of the process is termed as Guest Flow, where an existing MAB session gets guest user context appended to it. Therefore, there are two authorization rules for guest access; the Wi-Fi Redirect to Guest Login rule redirects unknown endpoints to the Cisco_WebAuth profile for presenting to a Guest portal, and the Wi-Fi Guest Access rule is used after users enter their credentials (Guest Flow). This grants them internet access (permit access).
The following figure shows central web authentication:
Guest user accounts can be created with several attributes that determine their roles and responsibilities in the network. ISE has 3 built-in guest types. As an administrator, you can create your own custom guest types. The following are the built-in guest types:
The following figure depicts guest user experience:
Note that if the device goes to sleep or if users leave the network and come back, they will be required to go through the login process again.
Guest users are required to log in to the ISE Guest portal every time they connect to the network. For example, users may put their device to sleep, resume from sleep mode, or get a new wireless session ID. The default wireless user Idle Timeout value on the WLC is 180 seconds. This user experience can be avoided with the Guest Remember Me feature on ISE.
This section describes how to allow a guest to access the network without being redirected to ISE every time after the initial login. With the previous rule set (Guest_Flow), when a device leaves the network and comes back, the device is redirected to the login process again.
The Remember Me feature works by using the endpoint group to track users. Currently, there are caveats, with ISE granting access based on the endpoint group. This is because there is no user logging into the Guest portal. Instead, access is based on MAB, using the MAC address. Be aware of the following:
Restrict access times by utilizing the authorization policy conditions.
Instead, you can restrict the number of devices that are allowed to register under Guest Type for wireless.
|Note: Another way to remember guests is to use the Sleeping Client feature in the wireless controller. This feature keeps the wireless session cached in memory. The potential problem with this is that only a certain number of sessions can be stored in the controller’s memory. However, this document does not cover that feature.|
|Note: This is the same configuration that is used for a hotspot portal. The only difference is that with hotspot, you redirect guests to a hotspot portal instead of to a self-registered Guest portal.|
|Note: Clicking on Save with allow you to use the Guest Endpoints MAB condition again in another rule if you like, since its not complex you don’t need to re-use so instead we go direct to Use.|
|Note: For wired guest access, the policy can be modified in two ways. The WiFi_Redirect_to_Guest_Login policy can be duplicated, and in the new rule, the endpoint’s session can be matched with Wired_MAB instead of Wireless_MAB. Alternatively, the WiFi_Redirect_to_Guest_Login policy can be edited to match Wireless_MAB or Wired_MAB with an “OR” condition check.|
The Remember Me feature is a simple MAB function based on the GuestEndpoint Endpoint Identity group. The MAC address of any guest user’s device that is authenticated once will automatically be registered under GuestEndpoint within ISE. A user has to accept an Acceptable Use Policy (AUP) for hotspot access, or enter certain credentials for credentialed guest flows only once. From then on, access is based on the guest device’s registered MAC address. Thus, the guest will not be redirected to the ISE portal for AUP or login, on subsequent network connections, until the MAC address is purged from the GuestEndpoint group. The default purge period is 30 days and can be customized for individual environments. Note that this is not guest account purging, just a guest device’s MAC address. To change the endpoint purge period, perform either of these tasks:
As explained in Understanding Guest Flow, when endpoints first access the network, they are authenticated with MAB, and must be redirected to the Guest portal for authorization. ISE comes with a built-in profile called Cisco_WebAuth that references a built-in self-registered Guest portal. This section shows you how to modify this authorization profile to use other portals and URL-redirect ACLs.
The following configuration can be used for both wireless and wired environments. The WLC and switch require a preconfigured redirect ACL which you completed earlier in this document.
|Note: The ACL is case-sensitive and must match the definition in the Network Device exactly.|
Example: Authorization Profile for Hotspot Guest Access
Example: Authorization Profile for Self-Registered Guest Access
In a typical scenario, the guest Wi-Fi traffic is isolated in the DMZ, and the guest wired traffic is segmented using a Guest VLAN, as shown in the figure below. In some environments, the guest wireless traffic may be within a campus with separate SSID and VLANs too. How you want to manage your guest network is up to you. However, note that controlling guest traffic from accessing internal resources is important.
While VLAN segmentation helps in keeping the traffic separate, as explained in the IP Address and VLAN changes section, it is not a good idea to change VLANs dynamically for guests. The use of IP ACLs and/or SGTs can be a remedy for this issue. For guest traffic segmented on DMZ, an ACL and/or SGT policy to permit all IP traffic can be applied, and for the guest traffic within a campus network, an IP ACL and/or SGT to deny access to private IP addresses will suffice in most of the cases. This section describes the optional tasks of authoring and authorizing an ACL for a guest user connecting internally.
Overall the recommendation would be to consider using segmentation using Scalable Group Tags (SGTs) in your deployment to help reduce the overall management costs and help with your organization segmentation story.
For more information please see the Segmentation and group based policy resources community.
permit tcp any host 192.168.133.27 eq 8443
deny ip any 192.168.0.0 0.0.255.255
deny ip any 172.16.0.0 0.15.255.255
deny ip any 10.0.0.0 0.255.255.255
permit ip any any
|Note: AireOS does not support downloadable ACLs. Therefore, ACLs must be configured locally on the wireless controller (or access points in FlexConnect mode). The ACL names must match in both ISE and in AireOS. The Guest ACL configuration on the WLC is very similar to the DACL configuration on ISE.|
This completes the steps required to get a portal up and running with your network device (switch or WLC).
If you are using a hotspot portal for guest access, you can go to the Configure Basic Portal Customization section.
If you are using the self-registration or sponsored flows (Credentialed Guest Access), then additional configuration is required. Continue with the next section, Configure the Minimum Settings for Self-Registered Guest Flow.
The default portal settings for self-registered guest access redirects guest users to the login window after successful account creation. This is a cumbersome task for the guests. For ease-of-use, we recommend that you allow guest users to log in to the network directly after registration. The following steps show you how to configure this:
|Note: This setting is highly recommended for use with “Remember Me” functionality. This allows the device to be remembered after the user initially logs into the Guest Portal. Using this flow is a better user experience as they only have to log in once per device until the device is purged.|
In ISE 2.1, the option of From first login was introduced in the Guest Type. This option improves the ISE Guest Access setup. However, by default, the From sponsor-specified date option is selected for all guest types. We recommend that you switch all your guest types to use From first login.
From first login enables a guest account immediately after a sponsor creates that account, or when the user self-registers on the Guest portal. This is particularly useful for those who want simple guest access that is activated immediately and lasts for a specific amount of time. The account can be valid for a day or a week, and you do not have to worry about limiting access to a set time of day or a specific amount of time.
With the From first login option, you do not have to worry about creating location and associated time zones unless you want to limit the time range during which a user can log in to the Guest portal. If you want to set strict limits on access hours, you should set up locations and time zones. However, if you only want guests to be able to use the account starting at a specified time, you will have to work with the sponsor-specified date. For more information about this, see Working with Locations and Time Zones.
Instead of the From first login option, if the sponsor-specified date option is chosen for guest account start time, the location and time zones corresponding to the locations where the guests will be accessing the network, must be configured. Your guest or sponsor can easily choose the time zones when the accounts are activated. Use this setting if you require a specific set of times during which your guests can use their account for network access. Unlike the From first login option that activates an account immediately, this setting activates an account at a specific time, which is when the account is registered by the guest, or when the sponsor sets its start time.
|Note: If you do not configure a location, the account will not get activated at the correct time, and the user will not be able to log in.|
Ensure that the time on your ISE server is correct. Even if it is only a few minutes faster than your browser, you may notice that it takes a few minutes for the accounts created using self-registration or sponsored flows to start working. When this happens, an Authentication Failed message is displayed to the end user using the Guest portal.
Also, under Operations > RADIUS > Live Logs in ISE, you can see failure entry details stating that the account is not yet active.
If you need to restrict access to certain times of the day, you must configure locations and time zones. If only one location is configured in your portal and sponsor group, guests and sponsors will not be presented with the option to select a location.
Since only one location, San Jose, is available out-of-the-box, there is a problem with new setups in other time zones. For example, when an ISE administrator sets up a system in Boston, it is 9. a.m. there. The admin goes to the self-registration window or the Sponsor portal window to create an account, thinking that he/she is working with the local time. However, the time zone is PST. The account (unless the admin is using From First Login) will not be activated for another 3 hours, and the guests will not be able to log in. Unless the guest users connect to the network in PST time, a separate location configuration must be done in ISE to cater to those users in different time zones.
Deployments in the PST time zone can use the San Jose location that is built into ISE. If that time zone is acceptable to you, skip to the Configure Settings for the Sponsored Guest Flow section.
|Note: You cannot change the name of the default San Jose location. However, you do not have to remove it because it will not be displayed if you do not choose to use it.|
For more information about location and SSIDs, see Assign Guest Locations and SSIDs in the Administrators guide.
To configure guest locations and time zones, perform the following steps:
The Guest Locations and SSIDs window is displayed.
Do not delete the San Jose Location.
From a guest user’s perspective, there are a couple of options to provide sponsored guest access:
Configure Self-Registered Guest Access with Sponsor Approval
The default self-registration portal can be used for both self-registered and sponsored guest access. The following table explains the options for both the scenarios:
|Guest Type||Guest Can Create Own Accounts||Sponsor Role||Guest Portal|
|Self-registered guest user||Yes||(Optional) Can approve or deny guest access||Self-Registered Guest Portal|
|Sponsored guest user||No||Must create guest account and share credentials to guest user||
Sponsored Guest Portal
Self-Registered Guest Portal
If you are looking at only sponsored guest access, and do not want to allow guests to self-register, perform these steps:
|Note: The Guest Flow for both Self-Registered Guest Portal (with the Allow guests to create their own accounts option unchecked) and Sponsored Guest Portal is exactly the same. The default sponsored Guest portal is available under Work Centers > Guest Access > Portals & Components > Guest Portals.|
Set up your sponsors by either creating an internal account or configuring ISE to integrate with Active Directory. If you are integrating with Active Directory, skip to the
Using Sponsor Accounts from Active Directory section
To create an internal account, perform the following steps:
Perform the procedures described in this section and the Setup the Active Directory Sponsor Group in All_Accounts only if you are integrating your Guest Access system with an Active Directory server that contains your sponsor groups.
To create sponsor accounts from Active Directory, perform the following steps:
A “Would you like to join all ISE Nodes to the Active Directory Domain?” message is displayed.
|Note: The domain credentials are not saved by ISE. The credentials are used only once to create a machine account for ISE in the Active Directory.|
You have now completed the task of setting up Active Directory Groups that can be mapped to your sponsor groups.
The following steps show how to associate the group containing your sponsors or employees to the sponsor group. In the example described here, we use Domain Users.
The Sponsor Group window is displayed, as shown in the figure below:
A Sponsor portal allows a sponsor to create temporary accounts for guests, visitors, contractors, consultants, and so on. It also allows you to view the accounts that guests create for themselves.
The following are the three options that are available to access the Sponsor portal; the first two methods require no special configuration, and can be accessed via the ISE admin GUI:
This window is reserved for administrators to quickly see what is going on with guests. However, we recommend that you do not use this to manage guests and sponsors. Use it only to quickly access the guest listing, mainly for deployments that do not use a Sponsor Portal. We highly recommend that you set up an easy-to-use Sponsor portal.
We recommend that you provide your sponsors with an easy Sponsor Portal URL, for example, Error! Hyperlink reference not valid..
Perform these steps to provide easy access to the Sponsor portal:
The Portal Settings pane appears, as shown in the figure below:
The Portal Test URL window is displayed.
Clicking Portal test URL displays the Sponsor portal with a complicated URL that can be sent to your sponsors. However, if you continue with the subsequent steps, a simpler URL can be generated.
Sample Portal test URL from an ISE deployment:
Note that this is an optional task. It is not critically necessary to get your system up and running for Guest access. It is an optional process to help familiarize with the basic customization options for your new Guest portal. If you are not interested in customizing your portal, skip this procedure and continue to the Setting up a Well-Known Certificate section of the Cisco Identity Services Engine Administrator Guide.
For more information about guest customization, see the Customize End-User Web Portals section of the Cisco I, and the HowTo: ISE Web Portal Customization Options section in the ISE Guest & Web Auth community page.
To customize a Guest portal, perform the following steps.
The active portal is indicated by a check mark in a green circle, as shown in the figure below:
ISE provides you with the advantage of basic customization built into the product. ISE also makes it easy to see what changes you are making in real time. Notice that the top of the window provides you with options to change logos, the banner, and main text elements. You can also choose from built-in color themes. Depending on your portal settings and portal type, you will see different options on the left side of the window. You can tweak the text in the different areas too.
|Note: Portal testing provides a real end-user experience and helps you validate a certain configuration, without the need for a real endpoint or network access session.|
You have now completed basic customization of your Guest portal. You can do the same with your Sponsor portal if you are using Sponsored Guest Access. To do this, navigate to Work Centers > Guest Access > Portals & Components > Sponsor Portals > Select the default portal, and follow the same steps you used to customize your Guest portal.
Note that this is an optional task. It is not required to get your system up and running for guest access for basic testing, but is highly recommended. To ensure that your users will not have to accept an invalid certificate when connecting to the Guest, Sponsor, or Administrator portals via their web browser, use a certificate that has been signed by a well-known Certificate Authority (CA). We recommend that you do not use self-signed certificates.
In the example described in this section, a certificate from SSL.com is used as an example of a provider that will work correctly with ISE. However, we do not recommend any specific provider. We only recommend that before purchasing a certificate, you get a test certificate from the CA to test with.
|Note: Each certificate provider may refer to a certificate type by different names. It often helps to call the company, or use their online contact options to explain what is needed in the SAN fields. Tell them that you are looking for a certificate containing a wildcard and FQDN in the SAN field, and a FQDN in the CN= field.|
For more information about wildcard certificates and certificates in general, see the following section in these documents:
The steps listed here show an example of how to set up a Unified Communications Certificate (UCC) with a wildcard in SAN from SSL.com, which is a subordinate of Comodo:
|Note: Some CAs might email the signed certificate to you. The resulting download or email attachment is often in the form of a zip file that contains the newly signed certificate and the public certificates of the CA. Save the digitally signed certificate, root CA certificate, and other intermediate CA certificates (if applicable) to the local system running your client browser in order to be imported. For more information about importing, see the section below, Import Certificate to the Trusted Certificate Store.|
This section shows you how to import the necessary certificates to ensure trusted client and server communication. Along with the server certificate, ISE also presents the root and intermediate (if required) certificates to the client when communicating.
|Note: Not all providers have intermediate certificates that are required to be installed. Intermediate certificates come from the subordinate CAs. The example provided here uses SSL.com, which is a subordinate of Comodo. Comodo is a subordinate to the AddTrust root CA. Therefore, this example shows how to import a root certificate as well as certificates for the two subordinates.|
To import all three certificates, perform the following steps:
The Import a new Certificate into the Certificate Store pane is displayed, as shown in the figure below:
The values specified above are specific to this example. Otherwise, the values vary according to your service provider's chain.
Now that you have received the digitally signed certificate from your CA, and imported the CA certificates, the next step is to bind the certificate signed by the CA to the CSR, from ISE. This pairs the certificate and private key that was used to generate the CSR.
Figure x Bind Signed Certificate
This completes the task of setting up ISE with a well-known certificate for ISE. For more information about working with certificates, see the Managing Certificates section of the Cisco Identity Services Enginer Administration Guide.
After configuring your ISE server, use the following steps to validate your deployment:
|Note: For guest flows, you can use the Portal Test URL at the top of the Portal Settings window to quickly test the flow, without having any network device or real clients.|
If, for some reason, your portal does not load, here are a few tips:
From this point, you can go through the complete flow. Note that the final success redirection to a static or originating URL needs a real session for this to work completely.
If, however, you are going to perform different flows with the same device, you should do the following between each flow test:
If you want to switch between a hotspot portal and a credentialed portal using the same authorization rules, you can do so by going into your Authorization profile and switching between the two.
For Hot Spot Guest Flow
Here is an example of what you will see when going through a flow with an endpoint.
Look at the image below, from bottom to top, the flow the device or user goes through is depicted:
Note that if you did not enable sign-on from the Self-Registration Success window, you should copy the username and password information to enter in the same login window.
The following procedure shows how a guest credentialed access will present itself. Look at the image, from bottom to top, the flow the device or user goes through is depicted:
Navigate to Work Centers > Guest Access > Manage Accounts.
The Managed Accounts is reserved for administrators to quickly see what is going on with guests. Note that we do not recommend this to manage guests and sponsors. It should be used only to quickly access guest listing, mainly for those systems that do not use a Sponsor portal. We, however, recommend that you set up an easy-to-use Sponsor portal.
For additional configuration and customization options, visit our Guest Web Auth community page.
My apple mini-browser is not working. I am getting error that the server can’t be found or I cannot connect to the internet. What maybe causing this?
Using Wired my endpoints aren’t being redirected.
If guest clients simply are not getting a DNS response for your ISE servers due to the network design. There are a few options here, but each have their own caveat.
2. open a hole for your guests to hit your internal DNS server. This way they can get a proper response.
3. Create a DNS server just for the guest environment.
For technical questions about ISE, please reach out to the ISE Support community page, your partner or local account team.
For advanced troubleshooting issues and outages, contact the Cisco Technical Assistance Center.