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

[ciscomoderator]

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)

[mackleyl]

Craig,

Is there a way to have confidence that certificate authentication is being done by the device to which certificate was issued? We would like to avoid a certificate being installed on multiple machines.

[Craig Hyps]

For starters, there are basic precautions that are possible outside of ISE such as setting issued certificate to be non-exportable.  That is not full-proof, but will not make things so simple for typical user.

For Windows PCs, there is also option to have separate machine and user certificates. AnyConnect supplicant can further enhance functionality by allowing separate identities to be chained together using EAP Chaining. This would allow, for example, to validate machine using cert or even AD machine account (not easily hacked) and then user auth to occur via user cert.

For general OSes, one simple option is to issue certificate with endpoint identifiable information that can be verified during authentication and authorization phase. For example, ISE BYOD allows certs to be issued whereby the MAC address of the registering client is captured during enrollment and automatically populated into the issued certificate's SAN field. If issuing client certificates using MDM, similar options exist to capture attributes from client and populate cert fields.

During authentication/authorization, you can then compare the Calling-Station-ID (commonly MAC Address) of client to the certificate field that is populated with the MAC Address.  If using MDM, then possible to check if mobile device is rooted/jailbroken which may also indicate possible tampering with device credentials/certs.

We have also supported binary comparison during authentication which basically compares the certificate issued to a user with the one they are presenting.  For example, if pushing certificates from AD CA and AD has a copy of issued cert, we will compare that cert presented is actual cert for that endpoint.  If user has multiple machines, then certs would be different, even if each valid.

Hope that helps.

Craig

[dal]

Hello Craig.

I have some questions about ISE v1.3 if you don't mind.

I see that the guest part of ISE has been upgraded, is it now possible for a guest to send a sms to a given phone number and get a login link in return?

If not, is it possible for a guest to self register, and then recieve a link they can click on, and be logged in? I mean so guests don't have to enter username and password at all, it is all embedded in the link?

We use NowSMS as SMS Gateway. Have you heard of it? Any pointers on how to configure ISE against it?

Will we see Norwegian language files for sponsor and guest portal? We we make them ourselves?

Can we use phone number as username?

Where can I change what fields the sponsors have to fill out when making new guest accounts?

Thank you.

[Craig Hyps]

No problem asking questions on ISE 1.3.  When asked for topic for this event, we did not know that ISE 1.3 would be shipping yet, so I listed ISE 1.2 to avoid questions on pre-release code.  Now that it is shipping, ISE 1.3 questions are fair game.

1. SMS Notification: Yes, a guest can send SMS to acquire credentials and this is admin configurable. They automatically are redirected to the login page from web browser but will need to manually enter the credentials received via SMS. We hope to provide update in interim release that will offer link with credentials that allows automatic login, but that did not make the first ISE 1.3 release.

2. Auto-Login Guest: When users self-register, YES, you can allow automatic login after they submit the requested information.

3. SMS Provider Support: ISE 1.3 comes preconfigured with a number of major SMS providers including both HTTPS and SMTP gateway support. NowSMS is not one of the preconfigured providers, but you can leverage one of the existing templates as a guide for populating the template for this provider.

4. Language Support: ISE 1.3 does not have Norwegian language support out-of-the-box, but the language files in ISE 1.3 make it much easier for customers to create and customize their own "templates", more similar to the way we support multiple language files with AnyConnect VPN.  You will be able to export the language file for selected portal, copy the properties file for supported language like English or German, make all changes to properties file offline, and then import the language file back into ISE with new properties entry.

5. Phone # as Username: There is an option to allow self-registered users to set username. We also support option to set custom username via API so you could create your own sponsor app to do this. For standard sponsor portal, the username is either the email address or derived from first and last name, often with additional numeric suffix to ensure uniqueness. Further testing would be required to see if custom CSS or Javascript could accomplish similar result from a sponsor portal.

6. Sponsor Fields: The fields that will be populated are configured under the Sponsor Portal > Portal Page Customization. Select the Page customization for Create Account for Known Guests. You will  see a Preview of the sponsor portal on right side. Click the Settings option above the preview. Here you can select which fields are displayed and whether they are mandatory entry fields.  You can also configure specific attributes required for specific Guest Types.  These will be automatically added if create guest from that portal when that guest type is selected.

Regards,

Craig

[dal]

Hello again, and thank you for your answers.

1. This is actually possible? A guest can send a SMS and get login credentials back? Without any web page involved before the actual login? Do have an example for this?
I'm looking forward to the login link contain login credentials

2. Very nice. Do you have any pointers where I can find that option?

3. I actually found this one out myself, and I now have NowSMS working as SMS Gateway for ISE :)

4. Yeah, I downloaded a few of them and started the conversion. Exactly how many language files are there? Is there a way to download them all at once?

5. I'm not sure what you mean (There is an option to allow self-registered users to set username). Where can I do that?

6. Found it, thanks for that.

Thank you again.

[Craig Hyps]

1. Self registration flow starts with user being redirected to a login web portal, selecting option that they need to setup an account, and then completing form. If self-service portal is also configured to allow notification through SMS, then user will be sent text message with login credentials that will be used at login page.

Below is an example configuration for the self-service portal with SMS options enabled.

If do not want to automatically send credentials via email or SMS, you can set the option to have user select whether they want credentials sent via email or SMS:

Under the Portal Customization, you can use default notification or add your own text and variables. In below example, I was using the optional access code, so added that to the default SMS notification message:

2. See second screenshot above where I highlighted option "Allow guests to log in directly from the Self-Registration Success page" under the Self-Registration Success Settings.

4. Language files in 1.3.0 are portal specific. There is one language file per portal that can be exported as a zip and contains all supported languages under separate properties files. You can make changes to any of the default properties files or add a new one.  If you want changes to apply to multiple portals of the same type, then you will need to import new zipped language file into each portal. 

5. Yes. For example, maybe the guest wants to use their phone number or other personal ID.  See first screenshot where I highlighted the optional User name field under the  Self-registration Page Settings.

Regards,

Craig

[dal]

Hello, and thank you again for your answers.

1. This is not what I meant. I was hoping for there was a way for the guest to send a SMS to acquire login credentials. Not going via the web page first.

Like sending a SMS with a code word, ie. GUEST first name last name, and get a response with an auto generated username (or phone number as username) and a password. And to top it all off, a link containg the login credentials :)

4. Ok, but let's say I have 1 portal for each type (1 guest portal, 1 sponsor portal, 1 self registration portal, etc) How many language files do I end up with then? Or do they all use the same language file? Or should I say language template?

But I have trouble making the portal work.

The self registration works fine, sending credentials with SMS works fine, and login works fine.

I'm getting a message saying: Success, you now have Internet access through this network.

But after this, whenever I try to go to any web site, I get redirected back to the Guest Portal..

I'm guessing it have something to do with the fact that we use Aerohive for WIFI.

Doesn't ISE need to send some "message" back to the accesspoint, telling the accesspoint that access is granted?

If so, what kind of message is that? And how to make an Authorization Result with it?

Two more things:

What exactly are the URL's for the sponsor and guest portals? The only way I have found to access them is via the setup page and portal test URL

When will Anyconnect 4 be released?

Thanks again.

[Craig Hyps]

1. Guests cannot send SMS to ISE and have it parse info to generate guest account. You could however have user send SMS to an external application that is able to process the data and use the Guest API in ISE 1.3 to create the account and automatically send SMS notification to the guest. 

4. By default, there is one language file per portal type that contains all of the text for that specific portal. For example, there is one language file for guest portals, one for Sponsor portals, one for My Devices, etc. If you were to have three portals of different types, then you would have three different language files.  You can export the language files in your current portals and see this first-hand.

Regarding authorization issue, you need to review ISE Live Authentications log under Operations > Authentications and look for the events for user in question. Verify that ISE is matching proper policy rule and returning the expected RADIUS authorization attributes to your wireless device.

Since you mention 3rd-party wireless device, this will be Local Web Authentication (LWA) versus Central Web Authentication (CWA) where ISE sends CoA after web auth. You should see a basic PAP request from the access device where it submits the guest credentials and returns specific authorization. In LWA, redirection does not come from PSN, but from your local access device. The Success message indicates authentication was successful, but need to review Live Log to determine which authorization was returned.

For CWA, it is not necessary to know actual portal location since ISE returns specific location automatically. For LWA, you need to enter a static URL destination. The syntax for portal under ISE 1.3 would be:

https://<psn_fqdn>:<port>/portal/PortalSetup.action?portal=<portal_name>

where:

   <psn_fqdn> resolves to a specific PSN or load-balanced server>
   <port number> is 8443 by default
   <portal_name is exact name assigned to portal including spaces. May need to add Unicode equivalents for spaces and special characters depending on your access device.

For Sponsor Portal, the best method is to use the simple URL (ISE 1.2) or the FQDN setting under the portal config. This allows you to configure DNS with this simple FQDN and have it resolve to desired destination.

Regarding AC 4.0, I cannot provide information on future release dates in this forum. Please contact your local Cisco account team for information on future releases.

Regards,
Craig

[Aaron Blair]

Hi Craig,

A customer of ours, which is intending to grow their deployment wants to deploy F5 load balancing in front of their ISE deployment.

The broad question I have is: Is there any F5/ISE integration/best practice guide that can be used to ensure this deployment is successful?

The technical problem that we are running in to is with traffic that was originated by the ISE PSN, or traffic from a client that addresses the ISE PSN directly instead of through the F5 VIP (such as guest portal traffic). Because the F5 is the PSN's default gateway for all traffic, OCSP traffic from ISE (10.10.10.10) for example, is getting sent through the F5 (10.10.10.253), however the return traffic from the OCSP server is using the regular path to the ISE node, which is through the firewall (10.10.10.254). This causes the stateful firewall to reject this packet, and the conversation is broken.

Is the solution here simply to place the ISE nodes on a L3 segment with the F5 routing all traffic for that network? Or is there something else we can do here?

Thank you,

Aaron

[Craig Hyps]

Aaron,

Yes there is an F5/ISE LB Deployment and Best Practices Guide that is almost ready for release.  Please see my response to similar question on the main page of this event here. (Search on F5).

Current best practice guidance is to ensure the F5 LTM is fully inline with traffic and using IP Forwarding servers to address non-LB traffic.  There are cases where some traffic may bypass F5 and I cover this in my guide, but most LB flows like RADIUS should always be fully inline.

Technically there are ways to make some flows bypass the F5 LB, but my focus for this first revision of the guide is to advocate proven, working configurations that have successful deployments around them.  There are so many variables when traffic is asymmetric and difficult to capture.  I am hoping to have a larger deployment base with these variations before promoting them as best practice. 

In your case you mention issues with asymmetric flows through firewall.  There are methods to address asymmetry through a firewall which are independent of the topic of load balancing.  You could create a static route to OCSP server that points to firewall, but my recommendation is to start with fully inline--either physically or logically inline--to help ensure success.

Since you mention "a customer of ours", it sounds like you may be a Cisco partner. If so, please reach out to your Cisco Security Channels SE for information on an upcoming webinar I will be delivering with F5 team next month on this very topic.

Regards,
Craig
 

[grabonlee]

Hi Craig,

I want to create authorisation rules based on location and assign a VLAN through authorisation profile. What is the best method?

For example, IP phones attached to different wired closets with named vlan (Voice_Vlan) but different vlan IDs. 

Do I,

1. Create a single rule and use the authorisation policy with the named VLAN, but have the wired closets on different VTP domains, so that once the rule match, IP phone in building A gets VLAN 10, building B gets vlan 20 and so on.

2. Create a nested or inner rule within a single rule based on location and assign different authorisation profiles that have the VLAN IDs and not name. If so, please could you describe how to create the inner rules.

Thanks for your help.

[Craig Hyps]

My first recommendation is to authorize based on VLAN Name and/or VLAN Group Name.  Note that names are case sensitive. This allows you to assign users to same functional VLAN even if the numbers are not consistent across network devices.

For switches that support VLAN Group Name, it allows for an even higher level of abstraction to assign users to on of many VLANs that are associated to the same group/function.  An example would be a switch where you run out of address space and need to allocate another VLAN to extend the address space into a different subnet.  For wireless, you can assign assign VLAN by number, but also be Interface Name or Interface Group Name.

The above would be my first recommendation bit does require validation that your naming is consistent across the network. If for some reason you are unable to facilitate the use of VLAN Names or Group Names (for example, unable to get consistent naming in place), then option 2 is valid as well, albeit not as efficient. 

You would not need to nest Authorization Policy rules. You can simply have consecutive rules with varying conditions to match on things like Network Device Group (NDG) name, then assign the appropriate location-specific Authorization Profile.  Optionally, you could have separate Policy Sets based on NDG location.

For reference, I posted a separate guide to the support forum that highlights a similar configuration for the purpose of returning different authorizations for different web authentication portals based on location here.

Regards,

Craig

[grabonlee]

Hi Craig,

Thanks for the quick response. My naming convention will be consistent, so I will use the first option, which would be to have a single authorization rule for each category of user/device and assign profile with the VLAN name. Please you did confirm if VTP domain must be different or can be the same across wiring closets but the mode will be Transparent.

Another question I have is regarding device provisioning with PEAP only no SCEP and no device registration. I understand that the authentication would be through Wired or Wireless MAB, but I want the Authorisation rule to match the profile for self-provisioning. I already have my default rule Authorisation rule as Web_Auth.

So would my authz rule be:

If Wireless_MAB or Wired_MAB and Network Access: AuthenticationMethod = MSCHAPv2 then Self_Provisioning_profile. Should there be any other differentiating condition so that othe MAB devices don't match this rule?

Do I place this before rule for 802.1X devices that are configured properly and don't require provisioning or after?

Lastly for wired devices, do I still need to configure Guest Portal?

Thanks a lot

[Craig Hyps]

The use of VTP has no relevance on the authorization. VTP essentially controls how VLANs are auto-populated.

Regarding second question, you mention that you want to use device provisioning but not for device registration and no SCEP.  I interpret your request to mean that you want to provision the supplicant on user devices for 802.1X using PEAP-MSCHAPv2. Based on this premise...
let me clarify that device registration is a prerequisite for supplicant provisioning which is part of the BYOD flow. This is not a big issue and actually a good thing.  For each user provisioned you will see that user's identity defined as the PortalUser for the endpoint. The endpoint will also show that it has been registered and users will be able to manage their registered devices and do things like report lost or stolen.

Typical flow would be to start with Central Web Auth. You have option to enable Supplicant Provisioning for all non-Guest users by a config setting in the portal. This may work fine if you want to provision all employees hitting that CWA portal, but I generally recommend using the web authentication result to perform lookup to ID store and determine if that user should be placed into provisioning flow.

In the below example, the user hits CWA by default.  Based on their identity captured from CWA, I send specific users (members of the AD group "employee") through supplicant provisioning.

Other CWA users like guests, or other non-AD users, could match a less specific policy below the one that matches the more specific conditions for employee. Guest Flow condition basically matches users that just completed a successful web auth and going through reauthentication after CoA.

Hope this answers your question.

Craig

[grabonlee]

Hello,

Please what do you mean by "I generally recommend using the web authentication result to perform lookup to ID store and determine if that user should be placed into provisioning flow".

My use case is this:

An AD and Non-AD user (Identity store through radius proxy) without 802.1X setup properly will use Supplicant provisioning. I am not differentiating between Employee BYOD or a non-employee as long as they fall into the ID stores I mentioned above. The default rule which is WebAuth is just for users without matching Authz rule to provide AD credential and gain limited access. 

Also in the Multi-portal configuration menu, Device registration is not checked. Must this be checked as you mentioned that it's a prerequisite.

I appreciate your help.

Thanks