Ask the Expert: ISE 1.2: Configuration and Deployment with Cisco expert Craig Hyps

Question

Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions about how to deploy and configure Cisco Identity Services Engine (ISE) Version 1.2 and to understand the features and enhanced troubleshooting options available in this version, with Cisco expert Craig Hyps.
October 27, 2014 through November 7, 2014.
The Cisco Identity Services Engine (ISE) helps IT professionals meet enterprise mobility challenges and secure the evolving network across the entire attack continuum. Cisco ISE is a security policy management platform that identifies users and devices using RADIUS, 802.1X, MAB, and Web Authentication methods and automates secure access controls such as ACLs, VLAN assignment, and Security Group Tags (SGTs) to enforce role-based access to networks and network resources. Cisco ISE delivers superior user and device visibility through profiling, posture and mobile device management (MDM) compliance validation, and it shares vital contextual data with integrated ecosystem partner solutions using Cisco Platform Exchange Grid (pxGrid) technology to accelerate the identification, mitigation, and remediation of threats.
Craig Hyps is a senior Technical Marketing Engineer for Cisco's Security Business Group with over 25 years networking and security experience. Craig is defining Cisco's next generation Identity Services Engine, ISE, and concurrently serves as the Product Owner for ISE Performance and Scale focused on the requirements of the largest ISE deployments.
Previously Craig has held senior positions as a customer Consulting Engineer, Systems Engineer and product trainer.   He joined Cisco in 1997 and has extensive experience with Cisco's security portfolio.  Craig holds a Bachelor's degree from Dartmouth College and certifications that include CISSP, CCSP, and CCSI.
Remember to use the rating system to let Craig know if you have received an adequate response.
Because of the volume expected during this event, Ali might not be able to answer each question. Remember that you can continue the conversation on the Security community, sub-community shortly after the event. This event lasts through November 7, 2014. Visit this forum often to view responses to your questions and the questions of other community members.
(Comments are now closed)

Answer 1

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.
Regards,
Craig