Professional Documents
Culture Documents
Buy or Renew
Cisco Community
English Register Login
87632 102 7
VIEWS
HELPFUL
COMMENTS
Jason Kunst
03-26-2018 12:06 PM
Edited On: 01-14-2020 10:02 AM
For an oine 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.
Table of Contents
Introduction
About Cisco Identity Services Engine (ISE)
What is Covered in This Guide?
What is Not Covered in This Guide?
Dene
What is Guest Access?
Guest Access with Hotspot Guest Portals
Licensing
Design
ISE Deployment Model Considerations
Survivability
Conguration Best Practices for Cisco WLC
Apple Captive Network Assistant (CNA)
IP Address and VLAN changes
Caveats
Wireless Deployment Models
Deploy
Conguring the WLC for ISE Web Authentication
Congure ISE as RADIUS Authentication Server on WLC
Congure a Guest WLAN (SSID)
Congure an ACL to Redirect Guest Devices to the ISE Guest Portal
Congure a Catalyst Switch for Guest Access
Switch Capabiliities
Example Switch Conguration
Congure ISE for Guest Access
Add the Network Access Device to ISE
Policy Set for Credentialed Guest Access
Understanding Guest Flow
Using Guest_Flow to Match Guest User Type
ISE Authorization Policy for Contractor Guest Type
Guest User Experience
The Guest “Remember Me” Feature
Guest User Experience with “Remember Me”
Policy Conguration for the Guest “Remember Me” Feature
Using an Authorization Prole to Redirect Guest Endpoints to ISE
Access Control for Guest Trac
Congure the Minimum Settings for Self-Registered Guest Flow
Conguring Guest Type Access Times, Location, and Time Zone
Conguring From First Login
About the “From Sponsor-Specied Date” Option
Working with Locations and Time Zones
Congure Settings for the Sponsored Guest Flow
Guest Portal for the Sponsored Flow
Congure Sponsored Guest Access
Congure Authorization Prole and Policy for Sponsored Guest Access
Working with Sponsor Accounts
Using Sponsor Accounts from Active Directory
Set Up the Active Directory Sponsor Group in All_Accounts
Set Up ISE Sponsor Portal FQDN-Based Access
Congure Basic Portal Customization
Setting up a Well-Known Certicate
Create a Certicate-Signing Request and Submit it to a Certicate Authority
Import Certicates to the Trusted Certicate Store
Bind the CA-Signed Certicate to the Signing Request
Operate
Validation of ows
Testing Web Portals
Clearing Guest Endpoints
Monitoring Guest Connections
For Self-Registered Guest Flow
Viewing the Guest Users List
Access without Sponsor Portal
Access with Sponsor Portal
Troubleshooting Common Issues
Troubleshooting checklist
DNS issues
How Do I Get Support?
Introduction
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 Dened 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.
This guide describes the process and best practices for conguring 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
congurations with a Cisco WLC, Cisco switch, and ISE. Note that the guide does not cover more
complex congurations, such as conguring load balancing or foreign/anchor controllers.
Figure2: ISE for Guest Implementation Flow
There are four major sections in this document. The Dene section shows how to dene 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 congurations and best practices; and
lastly, the Operate section shows how to manage a guest network controlled by Cisco ISE.
Dene
What is Guest Access?
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 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.
Licensing
ISE guest access requires base license for each guest endpoint. For more information about licensing,
see the community page for ISE Licensing.
Design
ISE Deployment Model Considerations
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:
Survivability
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.
Sponsors are unable to create, update, or delete guest accounts related to users connecting to a
specic PSN.
Sponsor portal operations are severely impacted.
Hotspot and self-registration ows will fail.
Existing guest accounts will be able to access the network.
Please reference TAC Recommended AireOS Builds for best code version.
1. SECURITY > AAA > RADIUS > Authentication Servers > Apply Cisco ISE Default Settings —
Checking the Apply Cisco ISE Default Settings check box enables Change-Of-Authorization (CoA),
sets the RADIUS authentication port to 1812/UDP, and duplicates and creates the settings for a
RADIUS accounting server.
2. WLAN > Security > AAA Servers > Apply Cisco ISE Default Settings — Checking the Apply Cisco
ISE Default check box enables Allow AAA Override, sets NAC State = ISE NAC, and enables Radius
Client Proling for DHCP/HTTP Proling (Probes).
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 y, 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:
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:
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 dierent devices.
If it is absolutely necessary to separate guest trac 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 Dened
Segmentation solution, and deploy scalable group tags for segmentation.
Caveats
At the time of publishing this document, we have the following caveat:
This document describes a high-level recommendation; it does not discuss the dierent wireless models.
For more information about wireless design and WLC auto anchor, see wireless design guides:
Note:
Because of the caveat specied in CSCul83594, you cannot enable RADIUS accounting on two
WLCs. Both WLCs sending accounting start and stop messages with dierent 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
simplied conguration check box on the WLC named “Apply Cisco ISE Default Settings”. When
enabling the check box, it automatically congures an authentication server and an accounting
server with the same IP and settings. The same settings are ported to the WLAN conguration too.
The problem occurs when you congure enable the checkbox on both WLCs. Accounting needs to
be congured 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.
Deploy
Conguring the WLC for ISE Web
Authentication
This section shows how to congure the necessary security settings on the WLC to work with ISE. If you
are working with a switch, see Congure a Switch for Guest Access.
Note: This section provides information about how to set up a single controller. If you want to
create a conguration using a foreign anchor model, see the documents listed under Wireless
Deployment Models.
4. Click New.
The RADIUS Authentication Server window is displayed, as shown in the following gure:
5. Enter the ISE IP address for Server IP address and the RADIUS shared secret for Shared Secret
elds.
6. Check the Apply Cisco ISE Default Settings check box.
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.
7. Click Apply.
8. Click the Security tab and choose, Security > AAA > RADIUS > Accounting.
ISE will be automatically congured as a RADIUS accounting server, as shown in the following gure:
From the drop-down list on the right side of the window (see the gure below) choose Create New
and click Go.
2. Enter a Prole Name and SSID.
3. Enable the Status check box, and from the Interface/Interface Group(G) drop-down list, choose your
interface, in this case, guest.
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 8.3.102.0.
Please reference TAC Recommended AireOS Builds for best code version.
This allows enterprises to protect their network from users on other oors 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:
The following defaults are enabled when you selected Apply Cisco ISE Default Settings in the AAA
servers window:
Allow AAA Override – Enabled
NAC State – ISE NAC
Changes the state from a web redirection state to permit access state.
Radius Client Proling - DHCP Proling and HTTP Proling are enabled.
Used for identifying your device type, for example, whether you are using an iPad or iPhone; the
WLC packages the device-identifying data and sends it to ISE via RADIUS accounting packets.
11. Uncheck the FlexConnect Local Switching, Enabled check box.
Note:
If you are using local switching (see Wireless Deployment Models), leave this enabled.
Note:
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.
1. In the WLC GUI, choose Security > Access Control Lists > Access Control Lists.
The Access Control Lists window is displayed, as shown in the gure below. This window lists the
ACLs that are congured on the WLC. It also enables you to edit or remove any of the ACLs.
2. Click New to create a new ACL
3. In the Access Control List Name eld, enter ACL_WEBAUTH_REDIRECT as the ACL name, as shown
below:
4. Click the ACL name, to edit it
Note:
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).
Note:
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.
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.
Switch Capabiliities
Your switch must meet the following requirements to work in an ISE guest setup:
Layer 3 SVI for your guest network – the switch requires a routable Layer 3 interface that can
communicate with endpoints in order to redirect the browser to the ISE Guest portal.
Note: If the access layer switches are layer 2 only then this routable interface can exist on an
upstream device. Example your access switch only has an management network (port/SVI) and
cannot communicate with the endpoint networks.
For more information (this applies to many switching platforms) : ISE Trac Redirection on the
Catalyst 3750 Series Switch
Ip device tracking – usually enabled by default but critical on tracking the endpoint. For IBNS 2.0
device tracking please refer to the ISE Secure Wired Access Prescriptive Deployment Guide
Switch management IP – Communicates with ISE via RADIUS in order to control AAA functionality.
Global RADIUS and AAA congurations – The switch is congured for AAA using ISE.
Pre-Auth ACL – This is manually congured on the switch. When a user device initially connects to
the network, this ACL restricts what that device can access until authenticated by ISE. The device must
at least be able to communicate with ISE to see the Guest portal. You can also open access to a
company portal by adding a link to the Guest portal. For example, you might want to give access to a
hospital’s welcome page containing information about the hours of operation, a directory of
departments, and so on.
Redirect ACL – This is manually congured on the switch to identify trac that will be redirected to
the Guest portal. Here, you can also identify trac that is not redirected, for example, to the company
website mentioned previously.
Enable HTTP service – This conguration on the switch redirects the endpoint HTTP requests to the
Guest portal. Note: HTTPS redirection is not recommended. For more information about this, see ISE
Guest CWA and HTTPS redirection.
Change of Authorization (COA) – Cisco Network Access Devices utilize RADIUS COA to allow
changes in the Guest use case from a redirect state to a permit state. For example: A device connects
to the wire. When its rst authorized its based of simple MAB (MAC Authentication Bypass). ISE is
setup to redirect any basic MAB from unknown endpoints to the Central Web Authentication (CWA)
portal. This portal can host an Acceptable Use Policy (AUP) page like a hotspot or a credentialed login
portal. The user clicks to accept or enters their credentials. At this point ISE sends a COA to the switch
with a new authorization result. This time without a redirect ACL and likely with a permit ACL that
allows internet access. For more information on RADIUS COA see Chapter: RADIUS Change of
Authorization in the Authentication, Authorization, and Accounting Conguration Guide, Cisco IOS
Release 15SY
DOT1X System Auth Control required to enable authentication manager on a port.
In this conguration, HTTP and HTTPS browsing does not work without authentication (per the other ACL)
since ISE is congured to use a redirect ACL (named redirect). Here is the denition 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 dened on the switch in order to dene on which trac the switch will perform
the redirection. (It matches on permit.) In this example, any HTTP or HTTPS trac that the client sends
triggers a web redirection. This example also denies the ISE IP address so trac to the ISE goes to the
ISE and does not redirect in a loop. (In this scenario, deny does not block the trac; it just does not
redirect the trac.) 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 dene 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.
This command is required for the switch to redirect based on HTTP trac:
ip http server
ip http secure-server
dot1x system-auth-control
8. Click Submit.
If software dened segmentation is deployed then enable the Advanced TrustSec Settings and complete
the details as explained in the following guide: Cisco TrustSec Quick Start Conguration Guide.
Note: Like other built in policies, an SGT is applied to the Guest Access by default. This can
be utilized in your Software Dened 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 ow is a MAC authentication
Bypass (MAB), where ISE authorizes the endpoint for URL redirect to itself. This results in the web trac
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 prole 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 gure shows central web authentication:
Contractor — Users who need access to the network for an extended amount of time, up to a year.
Daily — Guests who need access to the resources on the network for just 1 to 5 days.
Weekly — Users who need access to the network for a couple of weeks.
4. When you complete this procedure, your policy will look like this. Remember to save the new policy.
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.
Reporting issues (MAC address is shown in the ISE reports instead of usernames.)
Guest Type options will not work if there is no portal login.
Time-based restrictions, for example, access only from 9 a.m. to 5 p.m.
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 conguration that is used for a hotspot portal. The only dierence is that
with hotspot, you redirect guests to a hotspot portal instead of to a self-registered Guest
portal.
7. Click Use.
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.
8. Click Save to save the policy set
Note: For wired guest access, the policy can be modied 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 ows 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:
For Hotspot, endpoint purge conguration can be done under portal settings.
For credentialed guest ow navigate to Administration > Identity Management > Settings >
Endpoint Purge
As long as the endpoint is in the Endpoint group called out in the authorization rule then the device
will have access without having to login to the credentialed portal. You can set the EndpointPurge
rule as low as 1 day. An example would be if GuestEndponts AND ENDPOINTPURGE: ElapsedDays
LESSTHAN 9999. This will remove all endpoints in the guest database when the purge runs on its
daily schedule.
For Credentialed guest accounts, the endpoint duration can be congured under the Guest Type
settings.
Note: The ACL is case-sensitive and must match the denition in the Network Device
exactly.
From the Value drop-down list, choose the appropriate default portal (Hotspot, Self-Registration,
or Sponsored).
5. Click Save.
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.
1. Navigate to Policy > Policy Elements > Results > Authorization > Downloadable ACLs.
2. Click Add.
4. The DACL on ISE can be validated by the Check DACL Syntax option.
5. Click Submit to save the ACL.
6. Click Authorization, then click Authorization Proles, and nally, click Add.
7. Congure the Authorization Prole, as shown in the following gures (the left gure indicates for a
wired guest and the right gure indicates for a wireless guest):
Note: AireOS does not support downloadable ACLs. Therefore, ACLs must be congured
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 conguration on the WLC is very
similar to the DACL conguration 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 Congure Basic Portal Customization
section.
If you are using the self-registration or sponsored ows (Credentialed Guest Access), then additional
conguration is required. Continue with the next section, Congure the Minimum Settings for Self-
Registered Guest Flow.
1. Navigate to Work Centers > Guest Access > Portals & Components > Guest Portals.
2. Click Self-Registered Guest Portal (default).
3. Under Portal Behavior and Flow Settings, select Self-Registration Success Settings.
4. Scroll down to the bottom of the window and check the Allow guests to log in directly from the
Self-Registration Success page check box.
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 ow is a better user experience as they only have to log in once per device until the
device is purged.
7. Expand Post-Login Banner Page Settings, and uncheck the Include a Post-Login Banner page
check box.
8. Scroll up and save the portal settings by clicking Save.
From rst 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 specic 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 specic amount of
time.
With the From rst 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 specied time, you will have to work with the
sponsor-specied date. For more information about this, see Working with Locations and Time Zones.
2. Change the following settings for a specic guest type of interest or all guest types (except
SocialLogin(default)).
Instead of the From rst login option, if the sponsor-specied 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 congured. Your guest or sponsor can easily choose the time zones when the
accounts are activated. Use this setting if you require a specic set of times during which your guests can
use their account for network access. Unlike the From rst login option that activates an account
immediately, this setting activates an account at a specic time, which is when the account is registered
by the guest, or when the sponsor sets its start time.
Note: If you do not congure 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
ows 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.
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
conguration must be done in ISE to cater to those users in dierent 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 Congure 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 congure guest locations and time zones, perform the following steps:
1. Navigate to Work Centers > Guest Access > Settings > Guest Locations and SSIDs.
2. Enter a Location Name and Time zone, for example, Boston (EST) using EST5EDT or America/New
York.
3. Click Add.
4. Click Save.
Self-registered guest access with sponsor approval – A guest user registers the account by lling
in all the mandated elds during the initial Guest Flow, and upon notication, the sponsor approves or
declines access.
Sponsored guest access – A guest user cannot register an account, but has to collect the credentials
from the sponsor via SMS or email to log in to the guest network. To congure this, see Congure
Sponsored Guest Access.
1. Navigate to Work Centers > Guest Access > Portals & Components > Guest Portals.
2. Click Self-Registered Guest Portal (default).
3. Under Portal Behavior and Flow Settings, select Registration Form Settings.
4. Check the Person being visited check box and the Require guests to be approved check box.
5. Scroll down and chose the notication methods applicable to your environment.
6. Scroll up and Save the conguration.
7. If you’re decided to use self-registration portal as congured above then next you will need to
conguration an Authorization Policy, Congure Authorization Policy
Or
If you are looking at only sponsored guest access, and do not want to allow guests to self-register,
perform these steps:
1. Navigate to Work Centers > Guest Access > Portals & Components > Guest Portals.
2. Click Self-Registered Guest Portal (default).
3. Under Portal Behavior and Flow Settings, select Login Page Settings.
4. Uncheck the Allow guests to create their own accounts check box.
5. On the right-hand side, when you click Guest Flow, the ow should appear, as shown in the gure
below:
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
FIND A C same. The default sponsored Guest portal is available under Work Centers > Guest
Buy o Access > Portals & Components > Guest Portals.
3. Ensure that the ISE authorization policy results for Cisco_WebAuth prole for guest user’s initial MAB
session. To do so, check the corresponding policy under Policy > Policy Sets: Default >
Authorization Policy > Wi-Fi_Redirect_to_Guest_Login.
For more information see the Active Directory as an External Identity Source section in the Cisco Identity
Service Engine Administrator Guide.
To create sponsor accounts from Active Directory, perform the following steps:
6. Click Yes.
7. You are asked to enter your credentials to join the domain. Note that the Specify the Organizational
Unit eld is optional. Click the information icons next to each eld for more details on what is required.
8. Click OK.
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.
15. After you choose your groups, the conguration will look, as shown in the following gure:
16. Click Save at the bottom of the window.
You have now completed the task of setting up Active Directory Groups that can be mapped to your
sponsor groups.
1. Navigate to Work Centers > Guest Access > Portals & Components > Sponsor Groups >
ALL_ACCOUNTS.
2. From the members list under Available User Groups, move the domain users under Selected User
Groups, as shown in the gure below:
3. Click OK.
4. Click Save.
It is important to congure correct locations that can be used when sponsors create your guest
accounts. If you are ne with using San Jose as the location, or do not have to use locations because
of your guest types, you can skip Steps 5-8.
5. From the Select the locations that guests will be visiting section, select the locations you want your
sponsors to use, as shown in the gure below.
The following are the three options that are available to access the Sponsor portal; the rst two methods
require no special conguration, and can be accessed via the ISE admin GUI:
Using the Manage Accounts button – Navigate to Work Centers > Guest Access > Manage
Accounts.
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.
Using the Portal Test URL - This URL can be sent to your sponsors so that they can easily bookmark
the site. This is the default option.
Using Sponsor Portal FQDN – This is an easy-to-remember URL that requires some additional
conguration.
We recommend that you provide your sponsors with an easy Sponsor Portal URL, for example, Error!
Hyperlink reference not valid..
1. Navigate to Work Centers > Guest Access > Portals & Components > Sponsor Portals.
2. Click Sponsor portal (default).
Note:
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.
https://ise.securitydemo.net:8443/sponsorportal/PortalSetup.action?portal=28981f50-e96e-
11e4-a30a-005056bf01c9
4. Close the Portal Test URL window as this was only to test its working.
5. In the Sponsor Settings and Customization window, click Portal Settings.
6. In the Fully qualied domain names (FQDN) and host names eld, enter a friendly Sponsor portal
FQDN:
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.
1. Navigate to Work Centers > Guest Access > Portals & Components > Guest Portals.
2. Click the portal you are using (Hotspot, Self-Registered, or Sponsored) to edit that portal.
The active portal is indicated by a check mark in a green circle, as shown in the gure below:
3. Click Portal Page Customization, as shown in the gure 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 dierent options on the
left side of the window. You can tweak the text in the dierent areas too.
4. To change the theme colors of your portal, use a built-in Portal Theme or the Tweaks option, as
shown in the following gure:
Note: Portal testing provides a real end-user experience and helps you validate a certain
conguration, without the need for a real endpoint or network access session.
In the example described in this section, a certicate from SSL.com is used as an example of a provider
that will work correctly with ISE. However, we do not recommend any specic provider. We only
recommend that before purchasing a certicate, you get a test certicate from the CA to test with.
Note: Each certicate provider may refer to a certicate type by dierent names. It often helps
to call the company, or use their online contact options to explain what is needed in the SAN
elds. Tell them that you are looking for a certicate containing a wildcard and FQDN in the SAN
eld, and a FQDN in the CN= eld.
For more information about wildcard certicates and certicates in general, see the following section in
these documents:
Cisco Identity Services Engine Administrator Guide - Wildcard Certicate Support in Cisco ISE
MovingPackets.net article - When SSL Certicates Go Wild
Aaron Woland’s Network World Blog - Wildcard certicates and how to use with ISE
Aaron Woland’s - HowTo: Implement Cisco ISE and Server Side Certicates
Create a Certicate-Signing Request and Submit it to
a Certicate Authority
The steps listed here show an example of how to set up a Unied Communications Certicate (UCC) with
a wildcard in SAN from SSL.com, which is a subordinate of Comodo:
1. Navigate to Administration > System > Certicates > Certicate Signing Requests.
2. Click Generate Certicate Signing Requests (CSR).
3. Enter the values for generating a CSR, as shown in the following gure:
Usage
Subject
Note: Some CAs might email the signed certicate to you. The resulting download or email
attachment is often in the form of a zip le that contains the newly signed certicate and the
public certicates of the CA. Save the digitally signed certicate, root CA certicate, and other
intermediate CA certicates (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
Certicate to the Trusted Certicate Store.
Note: Not all providers have intermediate certicates that are required to be installed.
Intermediate certicates 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 certicate as well as certicates for the two
subordinates.
The Import a new Certicate into the Certicate Store pane is displayed, as shown in the gure
below:
Click Browse
to select the
root CA
certicate.
Enter a
Friendly
Name.
Choose the
root certicate
returned by
your CA.
Under Trusted
For, check the
Trust for
Authentication
within ISE
check box and
the Trust for
client
authentication
and Syslog
check box.
Check the
Validate
Certicate
Extensions
check box.
Enter a
Description.
Click Submit.
3. Import all the CA certicates in the chain:
Root CA: AddTrustExternalCARoot.crt
Subordinate CA: SSLcomDVCA_2.crt
Subordinate CA: USERTrustRSAAddTrustCA.crt
The values specied above are specic to this example. Otherwise, the values vary according to
your service provider's chain.
1. Navigate to Administration > System > Certicates > Certicate Signing Requests.
2. Select the entry for your signing request.
3. Click Bind Certicate, as shown in the gure below:
4. Congure as follows:
Click Browse to choose
the CA-signed
certicate.
Specify a Friendly
Name for the certicate.
Under Usage, check the
Admin, EAP
Authentication, and
Portal check boxes.
From the Portal Group
tag drop-down list,
choose Default Portal
Certicate Group.
Click Submit to bind the
CA-signed certicate.
5. After you click Submit, the system will restart and be inaccessible for about 5 minutes.
This completes the task of setting up ISE with a well-known certicate for ISE. For more information about
working with certicates, see the Managing Certicates section of the Cisco Identity Services Enginer
Administration Guide.
Operate
Validation of ows
After conguring your ISE server, use the following steps to validate your deployment:
1. Navigate to Work Centers > Guest Access > Portal & Components > Guest Portals.
2. Choose the Guest portal you want to test.
3. Click the associated portal test URL.
If, for some reason, your portal does not load, here are a few tips:
The test portal always opens up with ISE’s real IP address. If the ISE node is behind a NAT router, its
public IP address must be replaced in the test URL.
If DNS is not resolving correctly, you can replace the ISE’s FQDN with IP address.
From this point, you can go through the complete ow. Note that the nal success redirection to a static
or originating URL needs a real session for this to work completely.
1. Turn o the Wi-Fi on the device, go to the device settings and click Forget SSID if you have multiple
proles set up.
2. On the WLC, clear the session for the device by navigating to Monitor > Clients.
3. On ISE, navigate to Context Visibility > Endpoints and remove guest devices.
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 prole and switching between the two.
Here is an example of what you will see when going through a ow with an endpoint.
Look at the image below, from bottom to top, the ow the device or user goes through is depicted:
6. Device connects to SSID and is authorized to be redirected to the webauth portal because the mac
address is unknown.
7. The user accepts the AUP or logs in to the portal, and the guest user device is added to the
GuestEndpoint group.
8. ISE initiates CoA for reauthentication.
9. The device is authorized (granted access) based o the endpoint group and permitted access.
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 ow the device or user goes through is depicted:
1. Device connects to SSID and is authorized to be redirected to the webauth portal because the mac
address is unknown.
2. The user logs in to the portal, and the guest user device is added to the GuestEndpoint group.
3. ISE initiates CoA for reauthentication
4. The user is authorized and permitted access per the guest ow.
Viewing the Guest Users List
Access without Sponsor Portal
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 conguration and customization options, visit our Guest Web Auth community page.
Cisco Switches require that a management vlan (SVI) exists on the switch. This management network
is used to communicate with the endpoints for redirection to the ISE guest portal (ISE is not an inline
appliance). Any routing or ACLs in your network will need to allow this communication to all IPs and
ports your PSN is setup to use.
Troubleshooting checklist
Is the client getting an IP address (and not an APIPA address)?
Is the switch seeing the IP address? (show authentication session interface x/y details)
Is the Client able to resolve the FQDN of the guest portal? (open cmd and try to do nslookup on the
FQDN of the portal)
Is the Client able to reach the PSN (to which the FQDN is resolving to)? Try pinging from the client to
the PSN, if ping is allowed in your network.
Is the Test URL option working for the guest portal?
Can you paste the FQDN of the guest portal in the URL of the client's browser and take captures on
the PSN with the lter of the client's IP? Are you seeing any packets coming in?
Do you have any proxy or a rewall in the path, which could possible aect the trac?
Miscellaneous - If multiple interfaces are selected in a portal which one will be returned? The rst one
in the list will be returned in any requests.
DNS issues
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.
If you can't resolve DNS of guest portal and are trying IP address of PSN (static URL for ISE) then the
certicate presented by ISE to the client needs to have ALL PSN IP Addresses serving guests in the
SAN of the well known certicate
You can set a static IP address under Policy > Policy Elements > Results, click your redirect. Check
the check box for static URL. Here, you can setup either DNS that is resolvable or an IP address. The
issue with using a static DNS entry, it breaks redundancy. If you use the IP address, the same issue
with redundancy comes in, but you also are going to start facing certicate issues because you can not
get a 3rd party cert for a private IP (depends on provider).
ISE with Static Redirect for Isolated Guest Networks Conguration Example
2. open a hole for your guests to hit your internal DNS server. This way they can get a proper response.
For advanced troubleshooting issues and outages, contact the Cisco Technical Assistance Center.
Tags: access deploy deployment guest guide ise prescriptive wired wireless
102 Helpful
Share
COMMENTS
06-23-2018 03:5
charleseapen Beginner
06-23-2018 04:08
Those all depend on the sms provider and are all listed on this page . Are you looking for something else? Then
please provide deep detail in a new community question
https://communities.cisco.com/docs/DOC-64018?mobileredirect=true#jive_content_id_SMS
07-25-2018 05:1
kamlenegi Beginner
Hello Jason,
I have gone through the guest deployment document and able to do wireless guest deployment in 2.3.
I am stuck in wired guest deployment and not able to push DACL from ISE to switchport which will allow user to
redirect. When user is connecting ISE congure switchport, nothing is happening, swithchport doesn't apply any acl.
Is there working snapshots for wired guest , what exact ACL, I need to congure.
Thanks
Kamlesh
07-25-2018 05:1
Please don’t ask troubleshooting on the post. Open a new thread and see how basic support back and forth may
help
Also might be in your best interest to open Tac case to quick resolution
08-13-2018 02:5
vivekkupekar Beginner
Hi Jason,
Is it mandatory requirement to have catalyst switch in Cisco ISE guest wi- setup.
My requirement is to only setup guest wi-. I understand that it only a Access Point, WLC (for redirection) and ISE
PSN node is required.
I was going through the page 17 of the PDF which talks about "Deploying ISE for Guest Network Access" and
mention of switch is confusing to me.
Thanks,
Vivek
08-13-2018 05:34
There are sections showing the wireless and wired cong separate. Wireless cong has nothing to do with the wired
setup
08-14-2018 12:2
vivekkupekar Beginner
Latest Contents
1 0
Hi, I'm currently running FMC version 6.6.1 and I have two FTDs running 6.6.0.1 and want to make sure I choose the
correct next step to upgrade the FTDs. When I go to download updates the only one I see for the FTDs is Cisco FTD
SSP FP2K Patch 6.6.0.... view more
0 0
Hi, I have 5506-X with Firepower services, Do i need the URL license for Whitelisting URLs or it just be needed in ca
se i need to blacklisting (Block) urls?The purpose for this that i have a network which i just need to permit a specic
URLs and blo... view more
1 0
Dear Teams ; I congured email alerts for some alarms for a year everything works well , but now i do not receive an
y alarmhow can i send test email for ensure that's the smtp server work ne thanks in advance
DART
Created by cae5upport on 02-11-2021 02:24 AM
2 0
Hi Guys, According to Cisco (see source) you can download the DART as a separate MSI installer le, the format is
"anyconnect-win-version-dart-predeploy-k9.msi" but I am unable to nd this particular package via the Cisco down
load and do remem... view more
0 0
Hi, I'm trying to chagne some funcionality in guest portal auto register and aproval. Now with ISE you have a eld wit
h: Person being visited (email address)When guest user register in this portal, it's send an email to validate this acc
ess. Well, I... view more
Discussion Video
Blog
Document
Project Story
Related Content
Discussions
Blogs
Events
Videos
Project Gallery
Recommended for you
guest access
Top