Guest Portal Settings
Portal Identification Settings
The navigation path for these settings is
.-
Portal Name—Enter a unique portal name to access this portal. Do not use this portal name for any other Sponsor and Guest portals and non-guest portals, such as Blacklist, Bring Your Own Device (BYOD), Client Provisioning, Mobile Device Management (MDM), or My Devices portals.
This name appears in the authorization profile portal selection for redirection choices, and is used in the list of portals for easy identification among other portals.
-
Description—Optional.
-
Portal test URL—A system-generated URL displays as a link after you click Save. Use it to test the portal.
Click the link to open a new browser tab that displays the URL for this portal. In order for this to work, Policy Services Node (PSN) with Policy Services must be turned on. If Policy Services are not turned on, the PSN only displays the Admin portal.
Note
The test portal does not support RADIUS sessions, so you won't see the entire portal flow for all portals. BYOD and Client Provisioning are examples of portals that depend on RADIUS sessions. For example, a redirect to an external URL will not work.
-
Language File—Each portal type supports 15 languages by default, which are available as individual properties files bundled together in a single zipped language file. Export or import the zipped language file to use with the portal. The zipped language file contains all the individual language files that you can use to display text for the portal.
The language file contains the mapping to the particular browser locale setting (for example, for French: fr, fr-fr, fr-ca) along with all of the string settings for the entire portal in that language. A single language file contains all the supported languages, so that it can easily be used for translation and localization purposes.
If you change the browser locale setting for one language, the change is applied to all the other end-user web portals. For example, if you change the French.properties browser locale from fr,fr-fr,fr-ca to fr,fr-fr in the Hotspot Guest portal, the change is applied to the My Devices portal also.
An alert icon displays when you customize any of the portal page text on the Portal Page Customizations tab. The alert message reminds you to update any changes made to one language while customizing the portal into all the supported languages properties files. You can manually dismiss the alert icon using the drop-down list option; or it is automatically dismissed after you import the updated zipped language file.
Portal Settings for Hotspot Guest Portals
The navigation path for these settings is
.-
HTTPS port—Enter a port value between 8000 to 8999; the default value is 8443 for all the default portals, except the Blacklist Portal, which is 8444. If you upgraded with port values outside this range, they are honored until you modify this page. If you modify this page, update the port setting to comply with this restriction.
If you assign Ports used by a non-guest (such as My Devices) portal to a guest portal, an error message displays.
For posture assessments and remediation only, the Client Provisioning portal also uses Ports 8905 and 8909. Otherwise, it uses the same Ports assigned to the Guest portal.
Portals assigned to the same HTTPS port can use the same Gigabit Ethernet interface or another interface. If they use the same port and interface combination, they must use the same certificate group tag. For example:
-
Valid combinations include, using the Sponsor portal as an example:
-
Sponsor portal: Port 8443, Interface 0, Certificate tag A and My Devices portal: Port 8443, Interface 0, Certificate group A.
-
Sponsor portal: Port 8443, Interface 0, Certificate group A and My Devices portal: Port 8445, Interface 0, Certificate group B.
-
Sponsor portal: Port 8444, Interface 1, Certificate group A and Blacklist portal: Port 8444, Interface 0, Certificate group B.
-
-
Invalid combinations include:
-
Sponsor portal: Port 8443, Interface 0, Certificate group A and My Devices portal: 8443, Interface 0, Certificate group B.
-
Sponsor portal: Port 8444, Interface 0, Certificate tag A and Blacklist portal: Port 8444, Interface 0, Certificate group A.
-
-
-
Allowed interfaces — Select the PSN interfaces which a PAN can use to run a portal. When a request to open a portal is made on the PAN, the PAN looks for an available allowed Port on the PSN. You must configure the Ethernet interfaces using IP addresses on different subnets.
These interfaces must be available on all the PSNs, including VM-based ones, that have Policy Services turned on. This is a requirement because any of these PSNs can be used for the redirect at the start of the guest session.
-
The Ethernet interfaces must use IP addresses on different subnets.
-
The interfaces you enable here must be available on all your PSNs, including VM-based ones when Policy Services turned on. This is required because any of these PSNs can be used for a redirect at the start of the guest session.
-
The portal certificate Subject Name / Alternate Subject Name must resolve to the interface IP.
-
Configure ip host x.x.x.x yyy.domain.com in ISE CLI to map secondary interface IP to FQDN, which is used to match Certificate Subject Name / Alternate Subject Name.
-
If only the bonded NIC is selected - When the PSN attempts to configure the portal it first attempts to configure the Bond interface. If that is not successful, perhaps because there was no bond setup on that PSN, then the PSN logs an error and exits. The PSN will NOT try to start the portal on the physical interface.
-
NIC teaming or bonding is an O/S configuration option that allows you to configure two individual NICs for high availability (fault tolerance). If one of the NICs fails, the other NIC that is part of the bonded connection continues the connection. A NIC is selected for a portal based on the portal settings configuration:
-
If both physical NICs and the corresponding bonded NIC are configured - When the PSN attempts to configure the portal, it first attempts to connect to the Bond interface. If that is not successful, perhaps because there was no bond setup on that PSN, then the PSN attempts to start the portal on the physical interface.
-
-
-
Certificate group tag—Pick a certificate group tag that specifies the certificate to use for the portal’s HTTPS traffic.
-
Endpoint identity group—Choose an endpoint identity group to track guest devices. Cisco ISE provides the GuestEndpoints endpoint identity group to use as a default. You can also create more endpoint identity groups if you choose to not use the default.
Choose an endpoint identity group to track employee devices. Cisco ISE provides the RegisteredDevices endpoint identity group to use as a default. You can also create more endpoint identity groups if you choose to not use the default.
-
Purge endpoints in this identity group when they reach __ days—Change the number of days since the registration of a user's device before it is purged from the Cisco ISE database. Purging is done on a daily basis and the purge activity is synchronized with the overall purge timing. The change is applied globally for this endpoint identity group.
If changes are made to the Endpoint Purge Policy based on other policy conditions, this setting is no longer available for use.
-
Display Language
-
Use browser locale—Use the language specified in the client browser's locale setting as the display language of the portal. If browser locale's language is not supported by ISE, then the Fallback Language is used as the language portal.
-
Fallback language—Choose the language to use when language cannot be obtained from the browser locale, or if the browser locale language is not supported by ISE.
-
Always use—Choose the display language to use for the portal. This setting overrides the User browser locale option.
SSIDs available to sponsors—Enter the names or the SSIDs (Session Service Identifiers) of the networks that a sponsor can notify guests as the correct networks to connect to for their visit.
-
Acceptable Use Policy (AUP) Page Settings for Hotspot Guest Portals
The navigation path for this page is
-
Include an AUP page—Display your company’s network-usage terms and conditions on a separate page to the user.
-
Require an access code—Assign an access code as the login credential that multiple guests should use to gain access to the network. An access code is primarily a locally known code that is given to physically present guests (either visually via a whiteboard or verbally by a lobby ambassador). It would not be known and used by someone outside the premises to access the network.
You can use this option in addition to the usernames and passwords that are provided as the login credentials to individual guests.
-
Require scrolling to end of AUP—Ensure that the user has read the AUP completely. The Accept button activates only after the user has scrolled to the end of the AUP. Configure when the AUP appears to the user.
When configuring the Hotspot Guest Portals flow, the AUP access code is reliant on Endpoint Identity Group device registration. This means that AUP Last Acceptance and Network Access: Use Case EQUALS Guest Flow flags cannot be used. When a user's session gets removed from the NAD, upon reconnecting, the user will see the AUP page but will not be required to enter the AUP access code.
The AUP access code page will appear only after the MAC address has been removed from the Endpoint Identity Group tied to the hotspot portal configuration. An endpoint is either manually deleted from the database through the Context Visibility page on Cisco ISE, or it is purged by way of the Endpoint Purge feature and configured endpoint purge policies.
Post-Access Banner Page Settings for Hotspot Portals
The navigation path for this page is
.Use this setting to inform guests of their access status and any other additional actions, if required.
Field | Usage Guidelines |
---|---|
Include a Post-Access Banner page |
Display additional information after the guests are successfully authenticated and before they are granted network access. |
Portal Settings for Credentialed Guest Portals
The navigation path for these settings is:
.-
HTTPS port—Enter a port value between 8000 to 8999; the default value is 8443 for all the default portals, except the Blacklist Portal, which is 8444. If you upgraded with port values outside this range, they are honored until you modify this page. If you modify this page, update the port setting to comply with this restriction.
If you assign Ports used by a non-guest (such as My Devices) portal to a guest portal, an error message displays.
For posture assessments and remediation only, the Client Provisioning portal also uses Ports 8905 and 8909. Otherwise, it uses the same Ports assigned to the Guest portal.
Portals assigned to the same HTTPS port can use the same Gigabit Ethernet interface or another interface. If they use the same port and interface combination, they must use the same certificate group tag. For example:
-
Valid combinations include, using the Sponsor portal as an example:
-
Sponsor portal: Port 8443, Interface 0, Certificate tag A and My Devices portal: Port 8443, Interface 0, Certificate group A.
-
Sponsor portal: Port 8443, Interface 0, Certificate group A and My Devices portal: Port 8445, Interface 0, Certificate group B.
-
Sponsor portal: Port 8444, Interface 1, Certificate group A and Blacklist portal: Port 8444, Interface 0, Certificate group B.
-
-
Invalid combinations include:
-
Sponsor portal: Port 8443, Interface 0, Certificate group A and My Devices portal: 8443, Interface 0, Certificate group B.
-
Sponsor portal: Port 8444, Interface 0, Certificate tag A and Blacklist portal: Port 8444, Interface 0, Certificate group A.
-
-
-
Allowed interfaces — Select the PSN interfaces which a PAN can use to run a portal. When a request to open a portal is made on the PAN, the PAN looks for an available allowed Port on the PSN. You must configure the Ethernet interfaces using IP addresses on different subnets.
These interfaces must be available on all the PSNs, including VM-based ones, that have Policy Services turned on. This is a requirement because any of these PSNs can be used for the redirect at the start of the guest session.
-
The Ethernet interfaces must use IP addresses on different subnets.
-
The interfaces you enable here must be available on all your PSNs, including VM-based ones when Policy Services turned on. This is required because any of these PSNs can be used for a redirect at the start of the guest session.
-
The portal certificate Subject Name / Alternate Subject Name must resolve to the interface IP.
-
Configure ip host x.x.x.x yyy.domain.com in ISE CLI to map secondary interface IP to FQDN, which is used to match Certificate Subject Name / Alternate Subject Name.
-
If only the bonded NIC is selected - When the PSN attempts to configure the portal it first attempts to configure the Bond interface. If that is not successful, perhaps because there was no bond setup on that PSN, then the PSN logs an error and exits. The PSN will NOT try to start the portal on the physical interface.
-
NIC teaming or bonding is an O/S configuration option that allows you to configure two individual NICs for high availability (fault tolerance). If one of the NICs fails, the other NIC that is part of the bonded connection continues the connection. A NIC is selected for a portal based on the portal settings configuration:
-
If both physical NICs and the corresponding bonded NIC are configured - When the PSN attempts to configure the portal, it first attempts to connect to the Bond interface. If that is not successful, perhaps because there was no bond setup on that PSN, then the PSN attempts to start the portal on the physical interface.
-
-
-
The portal certificate Subject Name / Alternate Subject Name must resolve to the interface IP.
-
Authentication Method —Choose which identity source sequence (ISS) or Identity Provider (IdP) to use for user authentication. The ISS is a list of Identity Stores that are searched in sequence to verify user credentials. Some examples include: Internal Guest Users, Internal Users, Active Directory, LDAP Directory.
Cisco ISE includes a default sponsor Identity Source Sequence for sponsor portals, Sponsor_Portal_Sequence.
To configure IdP, choose
.To configure an Identity Source Sequence, choose Administration > Identity Management > Identity Source Sequences.
-
Employees using this portal as guests inherit login options from—Choose the Guest Type that employees are assigned when they log on to this portal. The employee's endpoint data is stored in the endpoint identity group configured in that guest type for the attribute Store device information in endpoint identity group. No other attributes from the associated guest type are inherited.
-
Display Language
-
Use browser locale—Use the language specified in the client browser's locale setting as the display language of the portal. If browser locale's language is not supported by ISE, then the Fallback Language is used as the language portal.
-
Fallback language—Choose the language to use when language cannot be obtained from the browser locale, or if the browser locale language is not supported by ISE.
-
Always use—Choose the display language to use for the portal. This setting overrides the User browser locale option.
SSIDs available to sponsors—Enter the names or the SSIDs (Session Service Identifiers) of the networks that a sponsor can notify guests as the correct networks to connect to for their visit.
-
Login Page Settings for Credentialed Guest Portals
The navigation path for this page is:
-
Require an access code—Assign an access code as the login credential that multiple guests should use to gain access to the network. An access code is primarily a locally known code that is given to physically present guests (either visually via a whiteboard or verbally by a lobby ambassador). It would not be known and used by someone outside the premises to access the network.
You can use this option in addition to the usernames and passwords that are provided as the login credentials to individual guests.
-
Maximum failed login attempts before rate limiting—Specify the number of failed login attempts from a single browser session before Cisco ISE starts to throttle that account. This does not cause an account lockout. The throttled rate is configured in Time between login attempts when rate limiting.
-
Time between login attempts when rate limiting—Set the length of time in minutes that a user must wait before attempting to log in again (throttled rate), after failing to log in the number of times defined in Maximum failed login attempts before rate limiting.
-
Include an AUP—Add a acceptable use policy page to the flow. You can add the AUP to the page, or link to another page. Adding this changes the picture of the flow on the right.
-
require acceptance—Force the user to agree to the AUP before continuing the flow.
-
-
Allow guests to create their own accounts—Provide an option on this portal’s Login page for guests to register themselves. If this option is not selected, sponsors create guest accounts. Enabling this also enables tabs on this page for you to configure Self-Registration Page Settings and Self-Registration Success Page Settings.
If guests choose this option, they are presented with the Self-Registration form where they can enter the requested information to create their own guest accounts.
-
Allow guests to change password after login—Allow guests to change their password after successfully authenticating and accepting the AUP, if it is required. If guests change their passwords, sponsors cannot provide guests with their login credentials if lost. The sponsor can only reset the guest’s password back to a random password.
-
Allow the following identity-provider guest portal to be used for login—Checking this option and selecting a SAML Id identity provider adds a link for that SAML Id to this portal. This sub-portal can be configured to look like the SAML IDP that the user is providing credentials for.
Self-Registration Page Settings
The navigation path for this page is
. Use these settings to enable guests to register themselves and specify the information they must provide on the Self-Registration form.-
Assign self-registered guests to guest type—Choose the guest type to which all the self-registered guests using this portal will be assigned.
-
Account valid for—Specify the duration for the account in days, hours, or minutes after which the account expires unless you or the sponsor extend the account duration in the Sponsor portal.
-
Require a registration code for self registration—Assign a code that the self-registering guests must enter to successfully submit their Self-Registration form. Similar to the access code, the registration code is provided to the guest offline to prevent someone who is outside the premises from accessing the system.
-
Fields to include—On the self-registration page. Check the fields that you want to display on the Self-Registration form. Then check which fields are mandatory for the guests to complete in order to submit the form and receive a guest account. You may want to require fields such as SMS Service Provider and Person being Visited to gather important information from self-registering guests.
-
Location—Enter locations that the self-registering guests can select at registration time using the list of locations that you have defined. This automatically assigns the related time zones as the valid access times for these guests. The location names should be clear to avoid ambiguity during selection (for example, Boston Office, 500 Park Ave New York, Singapore.)
If you plan to restrict guest access by time of day, the time zone is used to determine that time. Unless all your time-access controlled guests are in the San Jose time zone, then create a time zone for your locale. If there is only one location, it is automatically assigned as the default location, and this field does not display in the portal for guests to view. Also, Location is disabled in the list of Fields to include.
-
SMS Service Provider—Select which SMS providers to display on the Self-Registration form to enable self-registering guests to choose their own SMS provider. You can then use the guest’s SMS service to send them SMS notifications, which minimize expenses for your company. If you only selected one SMS provider for the guest to use, this field will not display on the Self-Registration form.
-
Person being visited—This is a text field, so if you want to use it, instruct your guests what kind of information to enter into this field.
-
Custom Fields—Select the custom fields that you previously created to collect more data from the self-registering guests. Then check which fields are mandatory for the guests to complete in order to submit the Self-Registration form and receive a guest account. These fields are listed in alphabetical order by name. They are created on to add more custom fields.
-
Include an AUP—Display your company’s network-usage terms and conditions, either as text on the page currently being displayed for the user or as a link that opens a new tab or window with AUP text.
-
Require acceptance—Ensure that the user has read the AUP completely. This configures an Accept button on the self-registration page. If AUP is configured as on page, then you can also configure the Accept button to be disabled until after the user has scrolled to the end of the AUP.
-
-
-
Only allow guests with an email address from—Specify a whitelist of domains which the self-registering guests can use in Email Address to create email addresses; for example, cisco.com.
If you leave this field blank, any email address is valid, except for domains listed in Do not allow guests with email address from.
-
Do not allow guests with an email address from:—Specify a blacklist of domains which the self-registering guests cannot use in Email Address to create email addresses; for example, czgtgj.com.
-
Require self-registered guests to be approved—Specify that the self-registering guests using this portal require approval from a sponsor before receiving their guest credentials. Clicking this option displays more options for how sponsors approve a self-registered guest.
-
Email approval request to—If you select:
-
sponsor email addresses listed below, enter one or more email addresses of sponsors designated as approvers, or a mailer, to which ALL guest approval requests should be sent. If the email address is not valid, approval fails.
-
person being visited, then the field Require sponsor to provide credentials for authentication is displayed, and the Required option in Fields to include is enabled (if it was previously disabled). These fields are displayed on the Self-Registration form requesting this information from the self-registering guests. If the email address is not valid, approval fails.
-
-
Approve/Deny Link Settings—This section allows you to configure:
-
Links are valid for—You can set an expiration period for the account approval links.
-
Require sponsor to provide credentials for authentication—Check this to force the sponsor to enter credentials to approve the account, even if it is not required by the configuration in this section. This field is only visible if Require self-registered guests to be approved is set to person being visited.
-
Sponsor is matched to a Sponsor Portal to verify approval privileges—Click Details > to select the portals that are searched to verify that the sponsor is a valid system user, a member of a sponsor group, and that the members of that group have authority to approve the account. Each sponsor portal has an identity source sequence, which is used to identify the sponsor. Portals are used in the order they are listed. The first portal in the list determines the style and customization used in the sponsor portal.
-
-
-
After registration submission, direct guest to—Chose where the self-registered guest is directed after successfully registering.
-
Self-Registration Success page—Direct successfully self-registered guests to the Self-Registration Success page, which displays the fields and messages you have specified on Self Registration Success Page Settings.
It may not be desirable to display all the information, because the system may be awaiting account approval (if enabled on this page) or delivering the login credentials to an email address or phone number based on the whitelisted and blacklisted domains specified on this page.
If you enabled Allow guests to log in directly from the Self-Registration Success page in Self-Registration Success Page Settings, successfully self-registered guests can log in directly from this page. If it is not enabled, they are directed to the portal's Login page after the Self-Registration Success page is displayed.
-
Login page with instructions about how to obtain login credentials—Direct successfully self-registered guests back to the portal’s Login page and display a message, such as “Please wait for your guest credentials to be delivered either via email, SMS, or print format and proceed with logging in.”
To customize the default message, click the Portal Page Customization tab and select Self-Registration Page Settings.
The system may be awaiting account approval (if enabled on this page) or delivering the login credentials to an email address or phone number based on the whitelisted and blacklisted domains specified on this page.
-
URL—Direct successfully self-registered guests to the specified URL while waiting for their account credentials to be delivered.
The system may be awaiting account approval (if enabled on this page) or delivering the login credentials to an email address or phone number based on the whitelisted and blacklisted domains specified on this page.
-
-
Send credential notification automatically using:
-
Email—Choose email as the option by which successfully self-registered guests receive their login credential information. If you choose this option, Email address becomes a required field in the list of Fields to include and you can no longer disable this option.
-
SMS—Choose SMS as the option by which successfully self-registered guests receive their login credential information. If you choose this option, SMS Service Provider becomes a required field in the list of Fields to include and you can no longer disable this option.
-
Self Registration Success Page Settings
The navigation path for this page is
. Use these settings to notify successfully self-registered guests of the credentials they need to gain access to the network.Field | Usage Guidelines |
---|---|
Include this information on the Self-Registration Success page |
Check the fields that you want to display for the successfully self-registered guests on the Self-Registration Success page. If sponsor approval of the guest is not required, check Username and Password to display these credentials for the guest. If sponsor approval is required, these fields are disabled, because the credentials can only be delivered to the guest after they have been approved. |
Allow guest to send information to self using |
Check the options by which the successfully self-registered guest can send credential information to themselves: Print, Email, or SMS. |
Include an AUP (on page/as link) |
Display your company’s network-usage terms and conditions, either as text on the page currently being displayed for the user or as a link that opens a new tab or window with AUP text. |
Require acceptance |
Require users to accept an AUP before their account is fully enabled. The Login button is not enabled unless the user accepts the AUP. If users do not accept the AUP, they will not obtain network access. |
Require scrolling to end of AUP |
This field displays if you chose the AUP on page option. Ensure that the user has read the AUP completely. The Accept button activates only after the user has scrolled to the end of the AUP. |
Allow guests to log in directly from the Self-Registration Success page |
Display a Login button at the bottom of the Self-Registration Success page. This enables the guest to bypass the Login page and automatically deliver the login credentials to the portal and display the next page in the portal flow (for instance, the AUP page). |
Acceptable Use Policy (AUP) Page Settings for Credentialed Guest Portals
The navigation path for this page is
.-
Include an AUP page—Display your company’s network-usage terms and conditions on a separate page to the user.
-
Use different AUP for employees —Display a different AUP and network-usage terms and conditions for employees only. If you choose this option, you cannot also choose Skip AUP for employees.
-
Skip AUP for employees— Employees are not required to accept an AUP before accessing the network. If you choose this option, you cannot also choose Use different AUP for employees.
-
Require scrolling to end of AUP—This option displays only if Include an AUP on page is enabled.
Ensure that the user has read the AUP completely. The Accept button activates only after the user has scrolled to the end of the AUP. Configure when the AUP appears to the user.
-
On first login only—Display an AUP the first time the user logs into the network or portal.
-
On every login—Display an AUP every time the user logs into the network or portal.
-
Every __ days (starting at first login)—Display an AUP periodically after the user first logs into the network or portal.
-
Guest Change Password Settings for Credentialed Guest Portals
Guest Change Password Settings
The navigation path for this page is
-
Allow guests to change password after login—Allow guests to change their password after successfully authenticating and accepting the AUP, if it is required. If guests change their passwords, sponsors cannot provide guests with their login credentials if lost. The sponsor can only reset the guest’s password back to a random password.
Guest Device Registration Settings for Credentialed Guest Portals
Guest Device Registration Settings
The navigation path for this page is
Use these settings to either ensure that Cisco ISE automatically registers guest devices when they log in to or to allow guests to manually register their devices after they log in.
The maximum number of devices is specified for each guest type in
.- Automatically register guest devices—Automatically
create an endpoint for the device from which the guest is accessing this
portal. The endpoint is added to the endpoint identity group specified for this
portal.
An authorization rule can now be created to allow access to endpoints in that identity group, so that web authentication is no longer required.
If the maximum number of registered devices is reached, the system automatically deletes the first registered device, registers the device the guest is trying to log in with, and notifies them. Choose
to change the maximum number of devices with which a guest can register. - Allow guests to register devices—Guests can register
their devices manually by providing a name, description and MAC address. The
MAC address is associated with an endpoint identity group.
If the maximum number of registered devices is reached, the guest is required to delete at least one device before being allowed to register another device.
BYOD Settings for Credentialed Guest Portals
The navigation path for this page is
.Use these settings to enable Bring Your Own Device (BYOD) functionality for non-guests, such as employees, using the Credentialed Guest portals to access your corporate network.
Field | Usage Guidelines |
---|---|
Allow employees to use personal devices on the network |
Add the Employee Bring Your Own Device (BYOD) Registration page to this portal allowing employees to go through the employee device registration process, and possibly native supplicant and certificate provisioning, depending on the settings for Client Provisioning for the employee’s personal device type (for example, iOS, Android, Windows (excluding RT or mobile), OSX). |
Endpoint identity group |
Choose an endpoint identity group to track guest devices. Cisco ISE provides the GuestEndpoints endpoint identity group to use as a default. You can also create more endpoint identity groups if you choose to not use the default. |
Allow employees to choose to get guest access only |
Let employees access your guest network and avoid additional provisioning and registration that may be required to access your corporate network. |
Display Device ID field during registration |
Display the device ID to the user during the registration process, even though the device ID is pre-configured and cannot be changed while using the BYOD portal. |
Originating URL |
After successfully authenticating to the network, redirect the user’s browser to the original website that the user is trying to access, if available. If not available, the Authentication Success page displays. Make sure that the redirect URL is allowed to work on port 8443 of the PSN by the access-control list on the NAD and by authorization profiles configured in ISE for that NAD. For Windows, MAC and Android devices, control is given to the Self-Provisioning Wizard app, which does provisioning. Therefore, these devices are not redirected to the originating URL. However, iOS (dot1X) and unsupported devices (that are allowed network access) are redirected to this URL. |
Success page |
Display a page indicating that the device registration was successful. |
URL |
After successfully authenticating to the network, redirect the user's browser to the specified URL, such as your company’s website. |
Post-Login Banner Page Settings for Credentialed Guest Portals
The navigation path for this page is
.Use this setting to notify users (guests, sponsors or employees as applicable) of additional information after they log in successfully.
Field | Usage Guidelines |
---|---|
Include a Post-Login Banner page |
Display additional information after the users successfully log in and before they are granted network access. |
Guest Device Compliance Settings for Credentialed Guest Portals
The navigation path for this page is
. Use these settings to require guests, and employees using the guest portal, to undergo client provisioning of their devices in order to gain access to the network.- Require guest device compliance—Redirect guests to the Client Provisioning page, which requires them to download a posture agent. This adds client provisioning
to the Guest flow, where you configure posture policies for guests, such as checking for virus protection software.
If the guest is an employee using the Credentialed Guest portals to access the network and:
-
If you enabled Allow employees to use personal devices on the network in the BYOD Settings, the employee is redirected to the BYOD flow and will not undergo client provisioning.
-
If you enabled both Allow employees to use personal devices on the network and Allow employees to choose to get guest access only in the BYOD Settings, and the employee chooses guest access, they are routed to the Client Provisioning page.
-
VLAN DHCP Release Page Settings for Guest Portals
The navigation path for this page is
.-
Enable VLAN DHCP release—Refresh a guest's IP address for Windows devices after a VLAN change in both wired and wireless environments.
This affects the Central WebAuth (CWA) flow during final authorization, when the network access changes the guest VLAN to a new VLAN. The guest’s old IP address must be released before the VLAN change, and a new guest IP address must be requested through DHCP when the guest connects to the new VLAN. The IP address release and renew operations are supported only on the Internet Explorer Browser which uses DirectX controls.
The VLAN DHCP Release option does not work on mobile devices. Instead, guests are requested to manually reset the IP address. This method varies by devices. For example, on Apple iOS devices, guests can select the Wi-Fi network and click the Renew Lease button.
-
Delay to release __ seconds—Enter the delay to release time. We recommend a short value, because the release must occur immediately after the applet is downloaded, and before the Cisco ISE server directs the NAD to re-authenticate with a CoA request.
-
Delay to CoA __ seconds—Enter the time to delay Cisco ISE from executing the CoA. Provide enough time (use the default value as a guideline) to allow the applet to download and perform the IP release on the client.
-
Delay to renew __ seconds—Enter the delay to renew value. This time is added to the IP release value and does not begin timing until the control is downloaded. Provide enough time (use the default value as a guideline) so that the CoA is allowed to process and the new VLAN access granted.
Authentication Success Settings for Guest Portals
These settings notify the users (guests, sponsors, or employees as applicable) of authentication success or display a URL. Under Once authenticated, take guest to:, configure the following fields:
-
Originating URL—After successfully authenticating to the network, redirect the user’s browser to the original website that the user is trying to access, if available. If not available, the Authentication Success page displays. Make sure that the redirect URL is allowed to work on port 8443 of the PSN by the access-control list on the NAD and by authorization profiles configured in ISE for that NAD.
For Windows, MAC and Android devices, control is given to the Self-Provisioning Wizard app, which does provisioning. Therefore, these devices are not redirected to the originating URL. However, iOS (dot1X) and unsupported devices (that are allowed network access) are redirected to this URL.
-
Authentication Success page—Notification of successful authentication of the user.
-
URL—After successfully authenticating to the network, redirect the user's browser to the specified URL, such as your company’s website.
![]() Note |
If you redirect a Guest to an external URL after authentication, there may be a delay while the URL address is resolved and the session is redirected. Make sure that the redirect URL is allowed to work on port 8443 of the PSN by the access-control list on the NAD and by authorization profiles configured in ISE for that NAD. |
Support Information Page Settings for Guest Portals
The navigation path for this page is
.Use these settings to display the information that your Help Desk can use to troubleshoot access issues experienced by users (guests, sponsors or employees as applicable).
Field | Usage Guidelines |
---|---|
Include a Support Information Page |
Display a link to an information page, such as Contact Us, on all enabled pages for the portal. |
MAC address |
Include the MAC address of the device on the Support Information page. |
IP address |
Include the IP address of the device on the Support Information page. |
Browser user agent |
Include the browser details such as the product name and version, layout engine and version of the user agent originating the request on the Support Information page. |
Policy server |
Include the IP address of the ISE Policy Service Node (PSN) that is serving this portal on the Support Information page. |
Failure code |
If available, include the corresponding number from the log message catalog. You can access and view the message catalog by navigating to . |
Hide field |
Do not display any field labels on the Support Information page if the information that they would contain is non-existent. For example, if the failure code is unknown, and therefore blank, do not display Failure code, even if it is selected. |
Display label with no value |
Display all selected field labels on the Support Information page, even if the information that they would contain is non-existent. For example, if the failure code is unknown, display Failure code, even if it is blank. |
Display label with default value |
Display this text in any selected field on the Support Information page, if the information that they would contain is non-existent. For example, if you enter Not Available in this field, and the failure code is unknown, the Failure code displays Not Available. |