Showing results for 
Search instead for 
Did you mean: 
Choose one of the topics below to view our ISE Resources to help you on your journey with ISE

This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.


As noted, "You have option to

As noted, "You have option to enable Supplicant Provisioning for all non-Guest users by a config setting in the portal."

This means that any non-Guest user will be automatically put into the Native Supplicant Provisioning (NSP) flow and does not allow for selective application of NSP flow. By not enabling that portal option...

   Under 1.2: "Enable Self-Provisioning Flow"
   Under 1.3: "Allow employees to use personal devices on the network " can use the results of web authentication to determine if CWA user should go through NSP. For example, IF User is member of AD Group XYZ, then NSP.

Device Registration option in guest portals has no bearing on NSP flow.

Hope that clarifies.



Hi Craig, Makes perfect sense

Hi Craig,


Makes perfect sense.


Thanks a lot


Hello Craig,Please some more

Hello Craig,

Please some more questions:

1. Some time ago, I noticed that when I assigned an IP (can't remember if it was the same subnet or not) to Gi1 on Standalone ISE, the GUI became inaccessible. I had to use console to remove the IP. Why was this so?

2. If all 4 interfaces can be used, how should they be configured?

a) Standalone = Same subnet or different subnets

b) Distributed (including geography) = Any point having 4 interfaces for PAN since all comms are through Gi0. For the PSN, can all 4 be on different subnets? or is it sensible to have Gi0 for admin only, while Gi1-3 be the only ports checked for profiling,posturing,and radius.


Back to the supplicant provisioning issue, for wireless it's easier to different User authentication based on Radius-Called-Station-ID. But for Wired, what is the best way to differentiate in the Authentication policy an AD and non-AD user(via Proxy) since the only ID stores that can be chosen are AD, Internal User and Internal endpoints? To make it clearer, would a wired device with native supplicant match the Wired MAB and continue, then default Authz sends it to Web Auth, and when the non-AD (proxy) credentials are typed, it goes to the rule matching Guest_Flow and proxy service, which would have the NSP profile permission?

In a documentation I read, ISE1.2 can't work with multiple domains. However, the workaround is Proxy and 2-way Domain trust. Regarding the use of Proxy, if the multiple domains are in a Single forest, how does it work since there won't be an external radius server configured. Obviously the child domain server can't be added as a network object. So does that mean having a secondary radius server on the child domain to proxy requests from ISE?



1. Without more specifics it

1. Without more specifics it is hard to determine actual issue. It may be possible that if configured in same subnet that asymmetric traffic caused connections to fail. A key enhancement in ISE 1.3 is to make sure traffic received on a given interface is sent out same interface.

2. Common use cases for using different interfaces include separation of management traffic from user traffic such as web portal access or to support dedicated profiling interfaces. For example, you may want employees to use a different interface for sponsor portal access. For profiling, you may want to use a specific interface for HTTP SPAN traffic or possibly configure IP Anycast to simplify reception and redundancy of DHCP IP Helper traffic. Another use case is simple NIC redundancy.

a. Management traffic is restricted to eth0, but standalone node will also have PSN persona so above use cases can apply for interfaces eth1-eth3.

b. For dedicated PAN / MnT nodes it usually does not make sense to configure multiple interfaces although ISE 1.3 does add support for SNMP on multiple interfaces if needed to separate out. It may also be possible to support NIC redundancy but I need to do some more testing to verify. 
For PSNs, NIC redundancy for RADIUS as well as the other use cases for separate profiling and portal services apply.


Regarding Supplicant Provisioning issue, the flows are the same whether wireless or wired. The same identity stores are supported as well. The key difference is that wireless users are directed to a specific auth method based on WLAN configuration and Cisco wired switches allow multiple auth methods to be supported on same port. 

If RADIUS Proxy is required to forward requests to a foreign RADIUS server, then decision must be made based on basic RADIUS attributes or things like NDG. ISE does not terminate the authentication requests and that is handled by foreign server. ISE does support advanced relay functions such as attribute manipulation, but recommend review with requirements with local Cisco or partner security SE if trying to implement provisioning for users authenticated via proxy. Proxy is handled at Authentication Policy level. CWA and Guest Flow is handled in Authorization Policy.  If need to authenticate a CWA user via external RADIUS, then need to use RADIUS Token Server, not RADIUS Proxy.

A typical flow for a wired user without 802.1X configured would be to hit default policy for CWA.  Based on successful CWA auth, CoA is triggered and user can then match a policy rule based on guest flow and CWA user identity (AD or non-AD) and returned an authorization for NSP.


Regarding AD multi-domain support...

Under ISE 1.2, if need to authenticate users across different forests or domains, then mutual trusts must exist, or you can use multiple LDAP server definitions if the EAP protocol supports LDAP. RADIUS Proxy is another option  to have some users authenticated to different AD domains via foreign RADIUS server.

Under ISE 1.3, we have completely re-architected our AD connector and support multiple AD Forests and Domains with or without mutual trusts.

When you mention the use of RADIUS proxy, it is not clear whether you are referring to ISE as the proxy or another RADIUS server proxying to ISE.  If you had multiple ISE deployments, then a separate RADIUS Server like ACS could proxy requests to different ISE 1.2 deployments, each with their own separate AD domain connection.  If ISE is the proxy, then you could have some requests being authenticated against locally joined AD domain while others are sent to a foreign RADIUS server which may have one or more AD domain connections.

In summary, if the key requirement is ability to join multiple AD domains without mutual trust, then very likely ISE 1.3 is the solution.  Your configuration seems to be a bit involved and I do not want to provide design guidance on a paper napkin, so recommend consult with local ATP Security SE to review overall requirements, topology, AD structure, and RADIUS servers that require integration.




Thanks Craig for a clear and

Thanks Craig for a clear and concise response. I noticed that you used the syntax :(BYOD-Open)$ for called-station-ID. What makes it different from using only the SSID name without the special characters.




Called-Station-Id format is

Called-Station-Id format is controlled by the access device. For example, current WLC allows this RADIUS attribute to be set to many different values including AP Group, MAC address, SSID, etc., or combination of values. 

My example is a throwback to days before we supported Boolean operators like ENDS_WITH. 

   Radius:Called-Station-ID MATCHES .*(:BYOD-Open)$

Using Matches operator, the regular expression is basically interpreted as "match any number of characters, then match string in parenthesis, then match end of line".  By default, WLC sets Called-Station-Id using the format AP_MAC_Address:SSID so regex basically wildcards the AP MAC address.

Using current operators, this condition could also be written as

   Radius:Called-Station-ID ENDS_WITH :BYOD-Open




Thanks for the clarification.

Thanks for the clarification.


Does anyone know how to save

Does anyone know how to save this thread (or any other thread) as a file on my local drive?
There's some really good case studies & info that I want to reference later on.

When I click on the "Save" towards the right hand side of the page, it automatically generats a PDF file, but it only contains the first page.
When I straight up print this web page in browser, all the formatting gets messed up, and the contents are hard to read.



Have you tried your browser's

Have you tried your browser's 'File > Save Page As' option to save it to local files?  I just tested with Firefox and it saved the html and all contents to subfolder.  Simple copy and paste to Microsoft Word also worked, although without same page formatting; content and pictures were preserved.




That worked; forgot the good

That worked; forgot the good old way to save a web page.

Your input in this thread has been awesome.
I took your ISE session in San Fran back in May, and you were great there too.


Frequent Contributor

Thank you Craig and huangedmc

Thank you Craig and huangedmc..

I will request an inquiry into the PDF feature's bug of only one page.