Internal Users not to use Guest Access

Hey Iris, nice piece here. I guess I'm coming to the dance late but could you kindly give any update from your implementation as I just took over a project on ISE as just like you the previous resource left and its now dumped on my laps to run with and the little I've been able to gather here has gone a long way in preparing me so you'd agree it's only natural to ask that you kindly give further updates on your implementation so as to learn more.

Guys how can you block internal users not to use Guest wireless to browser internet with ISE?

Easiest way to do this is to uncheck the box under the Guest portal that allows employees to login to the Guest Portal and use Sponsor Portals to create guest accounts. Restrict access to who can access the Sponsor Portal and create guest accounts

Hey Iris, nice piece here. I guess I'm coming to the dance late but could you kindly give any update from your implementation as I just took over a project on ISE as just like you the previous resource left and its now dumped on my laps to run with and the little I've been able to gather here has gone a long way in preparing me so you'd agree it's only natural to ask that you kindly give further updates on your implementation so as to learn more.

LoL. I actually have a server sitting next to me right now running ISE 1.4 (Had to downgrade from ISE 2.0 for POC reasons *sniff*) with Pxgrid integration across Lancope, WSA, Firepower and controlling wireless and wired access. I tend to favor PEAP-EAP-TLS for my corp devices and I have Guest Access provided through Sponsor Portals. I haven't had much need to play around with or configure posturing yet. I'm about to run out of the house but let me give you a bit of a dump on here when I get back and hopefully that gives you some ideas on how to successfully implement ISE.

I guess I'll resurrect this thread a little more Maybe make it a little educational.

So the first thing I would say is that ISE is not a "one-size-fits-all" system that you set up and it goes. It provides you with the ability to restrict and control access into your environment and with Pxgrid, you have the ability to share information and greatly enhance other security products you may own. That being said, you need to have your goals in mind. I get a lot of people asking me what other people did when they deployed ISE and what policies they built... If I'm talking to a customer, the first thing I ask is what their security policy is. ISE's policies should be written around the company's security policies, not have the security policies be written around some of the cool features that ISE can do or what you see other people doing.

So some examples of what a security policy a company wants to enforce includes:
- Employees are allowed to BYOD but their devices must meet a certain technical policy
- Guests are allowed network access but require to checkin and should not have access to internal resources
- For auditing purposes, all users or devices that access the corporate network must be logged

These are the types of policies that vary from company-to-company which is why the policy you write in ISE could be vastly different depending on where you go. I usually like to square away what is attempting to be accomplished before digging into the policies that will be created.

There are other things to consider as well such as ISE design. There are three "personas" that ISE can have. Now you can have all three personas on the same ISE VM/server but it limits your scalability. The different personas are as follows:

- Admin Persona - Each deployment can have two of these. Active/Standby. This is where you write your policy and it's pushed down to the other nodes. Typically I like to have two deployed in safe separate locations - such as two data centers. You definitely need to have IP reachability between these two since they do need to sync databases. If the pipes are clogged or unreliable, I've assigned QoS to the replication traffic before to help.
- Monitoring Persona - This is where all the records and logs are stored. Again, you can have two per deployment
- Policy Service Node - This is the node that your Admin node pushes all the policy down to. They're the real "workhorses." All your RADIUS nodes will be directing their requests towards these. You can have up to 40 of these per a deployment. In reality, I don't see that happen often but I do see people putting one in their DC, one in DR, and in their LARGE sites, putting an PSN in to locally respond to requests.

How redundant, how many endpoints you hope to support, etc can all influence how your distribute or don't distribute the above nodes so it should be taken into consideration before you head too far down the ISE road.

Great job Iris, thanks for the prompt response.....I can see you are forging ahead with the CCIE Datacenter as I have actually followed your Datacenter blogs too. Anyway, wish you all the best and once you are done, I'd like to pick your brain the more on somethings.

Design ISE 2.0

Hello Iris, i'm new to this forum. I have already deployed NAC 4.xx high reliability(2 cam and 2 CAs) but only for wireless network connections. Now my client wants to install ISE 2.0 to connect 800 PCs in LAN and about 150 wirelessly, using 802.1x. They are all connected to the same campus. The wireless part is handled with a pair of WLC 5508. The data center is run by a pair of 6500 with a classical structure Multi-tier. Have available No. 3 SNS 3495 and 1 sns 3415. How can I divide the functionality (persona)? Thanks a lot
Gino

Ekk. Sorry for for delayed response, Ginoogle. I would probably say that if you have 4 SNS appliances, you could easily divide two nodes as a combined Admin/Monitor node for failover so if one dies, the other keeps clugging away. Then the other two could be PSNs. Just create a radius group with both and if one fails, then the other will be used Adds a little redundancy in your design and considering that your deployment is pretty small, you're not even near bumping up to any ISE node limitation that way.

Ok, I'm going to close out this thread and open a new one in a couple weeks. Over the thanksgiving weekend, I took advantage of my long weekend and rebuilt my lab with the newest, latest and greatest. Even more importantly, I documented the hell out of every step I took so others couple duplication my efforts. I did the following in my lab:
- Creation of an Active Directory server from scratch, added the CA role, created CA templates for User, Computer, SCEP (for BYOD) and Pxgrid certs, created GPO that pushed SSIDs, certs and dot1x settings, set up for Pxgrid integration, etc
- Basic ISE 2.0 configuration and housecleaning
- Switch configuration for dot1x
- Configuration for Guest, Dot1x, and Hotspot SSIDs, SNMP, Radius, ACL and global configuration of the WLC
- Creation of a wired and wireless Dot1x policy with differentiated access between Computer, Employee, Vendor, and IT Admin
- BYOD configuration with certificates pushed through SCEP
- MDM Integration with Meraki Systems Manager since that's what I had available to me
- Guest wireless and wired policy creation
- Hotspot Wireless policy creation
- Created profiling policies and explained how those work
- Nexus 1000v Installation for my lab
- TrustSec configuration in ISE
- Nexus 1000v Basic TrustSec configuration
- Switch and WLC TrustSec configuration
- Basic ASA Configuration
- ASA TrustSec Configuration and creating rules based on SGTs
- Firepower Setup
- Pxgrid Integration with Firepower
- Connecting AMP for Endpoints to Firepower
- WSA Setup and Pxgrid integration. Created policies based on SGTs
- Netflow configuration on devices for Lancope
- Lancope Pxgrid Integration and mitigation
- FirePower and ISE Remediation

I probably wrote over 300 pages of guides over the Thanksgiving break. I let a member of this forum who I really respect highly take a look through them and he seemed to think they were gold. I am thinking of expanding out and writing some other posts/guides on the following:
- Posturing
- ISE and VPN
- TACACS policy creation and configuration
- Most of the above in different kinds of deployments: Distributed, With the ISE Internal CA instead of an AD CA, etc
- Best practices and lessons learned
- More digging into Firepower and different tools on there
- Prime 3.0 Management and seeing what I can cram in there for logging

Anyways, I have my first 25 or so blog posts written I'll probably retool them for my blog (link in signature) and post them over the holiday break. I originally wrote these guides as a "step by step" but in order to put them in a blog, I really need to rewrite them to include more "why" and background information. I sincerely hope this helps out some of the folks out there deploying, managing or thinking about using the technology.

Check out the link in my signature Also, the ISE BU is hitting me up to finish some docs for them this weekend so expect some nice stuff written by me to be hitting the ISE community pages soon I also need to update my blog.

I just came accross this article and find it , very interesting. We are running ISE ver 2 with two admin nodes, a primary and secondary.
They are both pointed to two different domain controller ( DC1and DC 2).
We had an issue where DC1 was not functioning properly , due to patchs upgrade from the server team.
Since the primary admin did not dectect DC1 down, it was still using DC1 causing user's authentication 's issues.
My understanding if DC1 goes down , the primary admin node will dectects it and will look for the next available DC.
Can you explain the mechanism behin that ? I mean how ISE detects the available DC ? How to configure ISE to automatically detects DC ?

TechExams.Net is not sponsored by, endorsed
by or affiliated with Cisco Systems, Inc. Cisco®, Cisco Systems®,
CCDA™, CCNA™, CCDP™, CCNP™, CCIE™, CCSI™;
the Cisco Systems logo and the CCIE logo are trademarks or registered
trademarks of Cisco Systems, Inc. in the United States and certain other
countries. All other trademarks, including those of Microsoft, CompTIA, Juniper ISC(2),
and CWNP are trademarks of their respective owners.