cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

ISE Single Click Sponsor Approval FAQ

11779
Views
19
Helpful
17
Comments

This is an FAQ about the single click sponsor approval feature added in ISE 2.2

 

Watch a video explanation: Video Link : 15799

 

SAML SSO and internal sponsors are not supported.

 

Flow has been tested against LDAP running on AD, it should work with other LDAP servers

 

If your are upgrading or restoring the database from earlier version of Cisco ISE to Cisco ISE 2.2+ you must manually insert Approve/Deny links. To manually insert the Approve/Deny links

1.Select Self-Registered Guest Portal

2.Click on the Portal Page Customization

3.Click on Insert Approve/Deny link in the Approval Request Email section.

For information on configuring Approval Request emails with approval/deny links, see Configuring Account Approval Email Links.

Cisco Identity Services Engine Administrator Guide, Release 2.2 - Configure Guest Access [Cisco Identity Services Engin…

 

There are two ways to approve an account using the single-click, one with and without a token. If you have a token then its truly a 1 click action. If you don’t have a token then the sponsor is required to enter their credentials and then the account will be approved.

 

How long does the token last?

The default is 3 hours. After that the single click function won’t work, the user will have to click on the link and login with their credentials to approve the account.

 

What happens if I forward the email link to someone else to approve?

If the single click email approval is forwarded to someone else then it will be approved by the person being visited email-address even though someone else clicked on it. This is because a token is generated when the guest 1st requests it by linking it with the person being visited. This tokenized link will only work when directly mapping a person being visited email address in the self-registration portal.

 

An example on why you may want the tokenized link. This is up to your organization standard procedures.

Maybe someone is out of the office and can’t get access to approve it as the Sponsor portal is available on the internal network. They forward it to someone else to click on the link for them. Because it wasn't the original recipient clicking on the link then any reporting or manage accounts lists will show the account belongs to the person being visited and not the actual person who clicked on the link.

To protect against this you would turn on the option to require authentication. This way you have tracking but lose the ease of use aspects.

 

What’s required for single-click with token (no requirement to enter credentials) to work?

Simple steps

  1. Your sponsors must belong to an AD group.
  2. AD group must belong to a sponsor group.
  3. Self-Registration page settings must require the following:
    1. sponsor approval
    2. person being visited

 

Note that the single-click (tokenized) link will not work if the following aren’t met.

·         The person being visited email address is not matched to a valid sponsor (must match a sponsor group and be part of a valid identity source sequence)

·         AD sponsor user must have same email address configured to match

 

How can I send the single click (with token credentials) to a group of sponsors so anyone receiving doesn’t have to enter their credentials?

since the person being visited option is required to create a single click tokenized URL then the Sponsor email address listed below option won't work. Here is an idea on how this would work:

Create a generic sponsor account in AD with email address like sponsors@mycompany.com, this would be entered by the guest on the self-reg page.

To make it easier on the visiting user since they can only use a limited set of email address values then some options:

  • to provide a drop down list (maybe 1 portal handles several sites) using javascript ISE Guest Self-Registration choose sponsor from a list
  • create a portal for each site that has different email address of sponsors this could then be pre-populated on the self-reg page with some javascript to hardcode as one single email address

 

<script>

setTimeout(function(){

$('#guestUser\\.fieldValues\\.ui_person_visited').val('sponsors@cisco.com');

$('#guestUser\\.fieldValues\\.ui_person_visited').attr('disabled', true);

}, 500);

</script>​

Keep in mind since this email address and generic account is used then there is no way to tie the approval a specific sponsor user.

Because of this its recommended you setup a sponsor group with group ownership, this generic sponsor and any other sponsors that would need to manage these accounts would need to be part of this group.

If this sponsor group had the option to filter the list of pending accounts to the person being visited then keep in mind that only the generic sponsor would be able to see these accounts as they are only matched by that account. If another sponsor that is part of the group logged in they would only see the accounts pending and matching their email address.

 

What happens if I self-reg guest enters an email address that doesn’t belong to a sponsor?

Single click won’t work but recipient can still attempt to login to approve with their credentials

 

Where does the overall theme (look) of the single click portal come from?

Customization comes from the 1st matched sponsor portal

 

How does Single Click Guest choose what PSN to encode in the URL?

The URL that is returned in the email to the sponsor is encoded with the Sponsor Portal Test URL of the 1st matched sponsor portal.  The only way to override this is to give the portal an EASY URL (FQDN) set in sponsor portal settings. Example: sponsor.mycompany.com maps to IP address of PSN1, PSN2 in DNS as a CNAME Alias

 

https://sponsor.mycompany.com:8445/sponsorportal/PortalSetup.action?portal=af0e2960-c324-11e8-b505-6a8ec20f675a&oneClickToken=4Hm/OR0mv3/l/xnzMs7b5g==&oneClickAction=Approve

 

This is a great discussion about redundancy with single click sponsor approval, guest and the sponsor portals

https://community.cisco.com/t5/identity-services-engine-ise/one-click-approval-redundancy/m-p/3548324
 

How do I customize the notification message sent to the sponsor?

Cisco Identity Services Engine Administrator Guide, Release 2.2 - Customize End-User Web Portals [Cisco Identity Servic…

 

How do accounts that don’t get approved get cleaned from the system?

They will be removed after 90 days (default) per the guest purge policy

Under?

 

What type of accounts are able to use the single click with token?

The sponsor email address must be populated under the AD or LDAP account Email.

ISE AD/LDAP schema is already mapped out of box when configured.

Administration > Identity Management > External Identity Sources > Active Directory > domain > Advanced Settings > Schema

Screen Shot 2016-11-28 at 6.48.49 PM.png

Screen Shot 2016-11-28 at 6.50.22 PM.png

 

Known defects

  • CSCvd29533 Fixed in 2.2P2 and 2.3 One-Click approval does not work with the "Only accounts assigned to this sponsor" option.
  • CSCvd85620 Fixed in 2.3 Utilizing a custom Schema to map attributes does not work with Active Directory.
  • CSCvi41646 April 2018 - LDAP query goes to domain mentioned after @ in user email

 

Unknown error when saving portal: I started getting this same issues after I had to rebuild the guest portals (suddenly they started throwing an error whenever I tried to save them) and have just found what was causing it for me.

In the Self Registration settings there is a collapsed list called "Sponsor is matched to a Sponsor Portal to verify approval privileges" which I hadn't noticed when recreating the portals. This had defaulted to the default sponsor portal which is not in use (and not linked to AD groups). After selecting the correct AD linked sponsors portals the issue was resolved.

Comments
Beginner

Hi all
Cisco ISE 2.1

Person being visited (email) cannot see button Approval or Deny.

you have solution ?Capture.JPG

Cisco Employee
Please read the top of this article. The feature came in ise 2.2