Buy or Renew
Buy or Renew
Duo Security forums now LIVE! Get answers to all your Duo Security questions. Learn more
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Create a new article
3579
Views
5
Helpful
1
Comments

ISE Alerts

Serge Yasmine
Cisco Employee
Cisco Employee

‎11-11-2013 12:44 AM - edited ‎02-21-2020 10:00 PM

 

 

Introduction

This page provides important alerts from Cisco TAC regarding ISE (Identity Services Engine) To automatically be notified of updates, log in and click "Receive email notifications" on the upper right.

Alerts - Firefox upgrade to version 25 stops working with ISE

Date entered: 11-November-2013

ISE web GUI stops working correctly after upgrading Firefox to version 25. You get error message:

There was an error while parsing and rendering the content. (node.getAttribute is not a function)

Error code WAP00008.

This is documented in bug CSCuj61976 and is going to be fixed in 1.2 patch 5 and 1.1.3 patch 9.

CSCuj61976 Admin UI fails to display certain UI pages when using Firefox 25This fix addresses an issue where ISE admin UI pages with a tree view were not displayed correctly in Firefox 25.

 

Patch 3 on 1.2 causes Guest Users login failures

Date entered: 19-November-2013

After installing Patch 3 on ISE 1.2 the sponsor timezone defaults to ECT which is a non-recognized Timezone, the guest account will fail to login. Error message on ISE will be "86019 guest user restricted"

This is bug CSCuj91050 and will be fixed in Patch 4 for ISE 1.2

If you roll back to Patch 2 the problem will disappear.

CSCuj91050 Creating Guest users shows incorrect timezone 'GMT+2 ECT'This fix addresses an issue where Guest user would fail to login with the following error due to an incorrect time zone being assigned to the account: "An internal error occurred. Contact your system administrator for assistance. Contact your system administrator."

 

Patch 7 on 1.2 causes Guest Users login failures

After installing Patch 7 on ISE 1.2 Guest users created with Sponsor logging in via AD are no longer able to login. This is documented in BUG ID: CSCuo16503 and below are more information about this and the workaround:

Date entered: 8-April-2014

 

  
Symptom s of Patch 7 on ISE 1.2, not seen prior to Patch 7, Guest users created with Sponsor holding their credentials on AD cannot login.
Conditions The below need to match:1- Sponsors logging in via AD to create guest users2- Guest users being put into guest groups and "Awaiting initial Login"
Workaround One of the following:1- Create the guest users with internal ISE configured Sponsor account2- Use AD Sponsor Account but place the guest users to the "Activated Guest Group

 

Patch 8 on 1.2 causes Guest Users login failures with invalid License

In case you applied patch 8 on ISE 1.2 and you happen to have only a base license without advanced license or advanced license has expired, then Guest portal will display "no valid system license exists" error message when Guests land on the login page.

This is documented in bug CSCuo76078. Workarounds:

1) In case you really need to run Patch 8 due to an affecting bug, then you will need to contact TAC and get a temporary advanced license.

2) Roll back and apply patch 7 and wait for a fix for above bug.  

Scenario 2

Problem:

Q: Why are the ISE nodes needed to be defined in the web authentication redirect acl that is configured locally on the switch?
 
A. User has setup 2yr old ISE environment this way and was advised in the beginning to do so. But after thinking the whole authentication process through and then testing out my theories I don't understand why the ISE nodes need to be defined in the switch redirect acl. I am now testing with a simple "redirect www & 443" acl and it is working as expected.
 
The client connects to the network and, for our environment, is requested to do dot1x until that times out and then it shifts to mab. At which point, I do not have an authz rule defined for my test machine and therefore matches my catch-all authz rule of CWA which sends a CWA DACL. The switch lays the acls on the interface in this order:
1. Redirect
2. DACL
3. PACL.
 
In my DACL I have access to the ISE nodes allowed (just to be safe) and the redirection still works because my test machine is not sending any www/443 traffic to the ISE nodes that I'm aware of (CWA is 8443).
 
Can someone explain (in detail) why a client machine would send www/443 traffic to the ISE nodes and therefore need to be defined in the CWA redirect acl local to the switch. 

I understand the process and flow of CWA but I still don't see why the ISE nodes need to be defined (as deny statements or at all) in the redirect acl that is locally configured on the switch. 
 
  1. A default PACL is statically applied to an unused interface. For my environment our PACL is a simple "permit ip any any" which allows an open fallback in case communication to ISE fails.
  2. A client plugs in and the switch begins talking dot1x to the client. During this time the PACL is the ONLY acl that is applied to the interface/client.
  3. The client does not run dot1x and therefore the switch eventually fails over to mab. At this time, the CWA authz rule comes into effect and ISE sends the DACL to the switch via radius and also references which RACL (redirect acl) to use.
  4. Not many people seem to understand this part....The switch then rebuilds the ACL that is applied to the interface/user. The switch creates an ACL that consists of ALL THREE ACLs. The first portion of this ACL is the RACL with permit statements (which are the deny RACL statements configured on the switch) and then redirect statements (which are the permit RACL statements configured on the switch) and then the DACL from ISE is the next portion of this new ACL and then the very last portion is the original static PACL that is configured on the port.

 

Let me give you this example. Say I have the following confgured:

CONFIGURED SWITCH INTERFACE ACL (PACL)
  ip access-list standard ACL-ALLOW
   permit ip any any

CONFIGURED SWITCH REDIRECT ACL (RACL)
  ip access-list extended ACL-WEBAUTH-REDIRECT
   permit tcp any any eq www 443

CONFIGURED ISE DOWNLOADABLE ACL (DACL)
  permit tcp any host <psn01> eq 8443
  permit udp any host <dns01> eq 53
  deny ip any any

 

Then the process would look like this:

1. During dot1x negotiation the acl that is used is this:

permit ip any any     <<<<<PACL

2. Once CWA is in effect then the acl looks like this:

redirect tcp host <host ip> any eq www 443             <<<<<<RACL
permit tcp host <host ip> host <psn01 ip> eq 8443       <<<<<<DACL
permit udp host <host ip> host <dns01 ip> eq 53       <<<<<<DACL
deny ip any any      <<<<<<DACL
permit ip any any      <<<<<<PACL

 

Solution

The traffic must first be allowed in dACL or Port ACL (if dACL is not configured as dACL is optional, configured only if you want to restrict access on switch port based user authenticating the network.i.e per-user based) then only it will hit redirect ACL.

This clears the confusion on which ACL got hit first.In fact, dACL will replace the pre-authentication ACL/PACL you have configured on the switchport. Traffic must be first allowed via dACL then it will hit redirect ACL.

 

 

You might be aware that in CWA the client is authenticated twice. As per my understanding PACL is the ACL-Default you apply on port manually. When you do First authentication then this ACL will be dynamically replaced by DACL. So now this is the acl that govern what traffic can pass through that port. so in this you need to permit DHCP, DNS,port  80,443 and traffic to ISE on port 8443.
 
Now when the traffic enters the switch Redirect ACL come in to picture. Here you need to permit only traffic that need to be redirected means port 80 and 443 traffic and you need to deny DHCP,DNS and traffic to ISE on port 8443 to get redirect.
So when the user try to access any web page,then first web browser needs to resolve domain name so it will issue a DNS query which dacl is allowing. then it hit redirect acl but it is denying that traffic to get redirected so client will resolve domain name. Now client try to send http traffic to the resolved ip address, http is allowed in DACL, then it hit redirect ACL which is permitting this http traffic to get redirected to ISE on port 8443. so client browser is redirected to new url.
 
Again DNS query for new url successful. client now send web traffic to ISE on port 8443 which is allowed in DACL, now hit redirect acl where it is denied to get redirected so client will be able to get Guest portal from ISE.
 

As per my understanding, once the port get authenticated, the order of ACL is 1. dACL 2. Redirect ACL 3. Port ACl.

Secondly why the ISE nodes need to be defined (as deny statements or at all) in the redirect acl

When redirect acl is applied to the port, any HTTP or HTTPS traffic that the client sends triggers a web redirection. Deny statement in redirect ACL at first place denies the ISE IP address so traffic to the ISE goes to the ISE and does not redirect in a loop. (In this scenario, deny does not block the traffic; it just does not redirect the traffic)

Source Discussion

 
Labels:
Comments
cgambrel
Cisco Employee
Cisco Employee
‎01-13-2014 06:15 PM

Mozilla has an extended support release (ESR) version of Firefox browser.  It is built around version 24 and does not upgrade, only patches.  I have had great results using this version with ISE and other web-based interfaces. Here is the link www.mozilla.org/en-US/firefox/organizations/all.html‎

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Customers Also Viewed These Support Documents