Cisco ISE Policy Enforcement

18. Testing Wireless Client Access

In this session, we'll be testing wireless client access with the policy that's within our WirelessPolicy Set and using the wireless capabilities of the iPad within the lab. Before we begin testing, let's review the policies within the Wireless Policy Set. And within the Wireless Policy Set, we have an authentication policy in place with rules to deal with map authentication. If it's a map, authentication will drive authentication towards internal endpoints. We'll use the Mac Address Data Store for Ise itself, and for82 and X authentication. We'll drive those towards all userID stores, which will include the Demo Local domain. Then for authorizations, we have our global exception still in place for the IT users, and then our standard authorization policy, which includes an entry for blacklisting as well as entries to match for contractors and employees, and then at the bottom of the list, domain computers themselves with authorization profiles appropriate for each authorization rule. As a reminder, our iPad within the lab is physically connected to the Admin PC with a USB cable, allowing us to remote control the iPad. The iPad itself and network access for the iPad will be completely over WiFi and wireless. Let's go back to the admin PC and access that tablet.

And we could see that access to the tablet takes us immediately into the Settings screen,and we're looking at the WiFi Connectivity screen, where WiFi is currently disabled. And as we enable WiFi, we see a healthy list of SSIDs within this lab environment. We are Pod 19, so we're focused on the 19 value SSIDs, and for this test, we want to access our WPA-Two E SSID. The fact that we're getting requests for credentials is a positive sign that the WLA controller is prompting us for credentials based on its matching authentication policy and is behaving as an AAA Radius client.

And we'll send these credentials off towards our ISC Radius server as we supply them. And as a reminder, the iPad is not a domain member, so we do need to supply the domain suffixfor the login, and then upon entering or attempting to connect there, we get prompted to trust an ID certificate presented by Ise one dot demo dot local and issued by Root CA r Domain Certificate Authority. We'll trust that certificate, and then upon trusting that certificate, we get a checkbox indicating that we've got a successful connection to this SSID. And before we move off the iPad to investigate elsewhere, let's make sure that we document the Mac address for this iPad. And really, just the last four characters are necessary: two D sixty six.Let's investigate things from Ise and open the live logs to see the results. from live logs. Okay, we see that our employee one at DemoLocal was connected using an endpoint with a Mac address ending in two D sixty six.

It matched an authentication policy of 802 oneX and provided a matched authorization rule for employeeaccess and the associated authorization profile. As we look at the details for this session, we can see the interaction with Ise and ultimately the external identity source timers associated. And then as we scroll down towards the bottom, we'll see the results box which includes the value of the airspace ACL that we specified within our authorization profile. As a reminder, this is not a DACL, but an ACL that resides on the W LA controller itself, and we see that we've correctly delivered that information to the WLAN controller. Let's investigate things from the WLAN controller. Open up clients to see connecting endpoints. We see a Mac address connected to our WPA2 EWLAN and likewise SSID. If we click on this entity to view details from its perspective, we can see IP address information, user authentication information, and if we scroll down here to security, we can see radius and state were run, and we can see that the authorization information provided included the employee underscore ACL. And just as a quick reminder, our iPad doesn't have a command box where we can easily launch a ping command from. And we don't have any web-based resources on the AP or quarantine networks that we are trying to provide policy control against. But given the fact that we're able to confirm results from Ise live logs and the perspective of the NAD, we can have faith that the iPad will be in a good situation for authorization, and we'll do some subsequent testing with the iPad to evaluate Web redirection and Web based authorization in a future session. As a quick summary, we evaluated wireless client access against our WPA two-E, also known as Eight One Authentication and authorization from the WLAN controller.

19. Introducing Cisco TrustSec

Trustec is a next-generation access control method that can greatly enhance the performance, scalability, and manageability of your network. TruSec implements a central policy implemented as a matrix comprised of three main functions: classification, propagation, and enforcement. Classification is enabled by the Cisco Identity Services Engine. Context awareness is the who, what, how, where, and when particulars of a given user session. Server connections can be statically classified based on expected usage and your security needs. This classification knowledge then propagates throughout your infrastructure. When endpoint frames arrive at their ingress NetworkAccess Device, or NAD, the NAD inserts a special tag into the layer two header. These scalable group tags, or SGTs, are also known as tags that are used to make forwardingfiltering or inspection decisions. The system is now capable of enforcing TrustSec. Capable downstream devices can permit or deny access based on these tags by using a new type of access control list or ACL, implemented on switches as a security groupACL or Sgacl, and on firewalls as an SG firewall. Let's dive in with INACC. Network devices in a trusted cloud are verified by a peer device using eight One X with Eat Fast. This allows for Ie 82 One Aeencryption between devices, so you're secure.

EAC is the formal name for the endpoints connecting to Nads. Successful authentication and authorization results in SGT assignment. EAC. Access methods include 82, one-x MAB, and WEBAUTH. A security group is a group of users, endpoint devices, and resources that share access control policies. You, the administrator, defined scalable groups in Cisco Ice. Now the security group tag That's a unique 16-bit scalable group number assigned to each security group. You do not have to manually configure scalable group numbers; they automatically generate them in a sequential manner. However, you can also reserve a range of SGTs for IP to SGT mapping. Now, these tags are applied as frames enter a trusted network, and are untagged as they egress from a trusted network. Now speaking of tags, here are the additional layer two headers that you can add for Trust SEC deployments. The Cisco Trust SEC solution supports hop-by-hop encryption and integrity authentication based on the Ie 802 One Ae standard. Now this is not directly related to tagging, but it's shown here to more fully depict the trustexsolution. You can also see the Cisco Metadata header or CMD header, which includes several fields. Now, the most important thing for this discussion is the actual tag that SGT value, which is added at the ingress port of Scrapable devices. The CMD header is added before the other layers. Two services such as QoS, the 802 One Ae, and Cisco Metadata headers have minimal impact on frame size. Together, they only add about 40 bytes to the frame size, less than a baby giant frame. Here's a TrustSec deployment scenario: an administrator created an a centralized policy matrix on Cisco Ice, and this policy is automatically downloaded to Nads in the form of Sgacls, which control access based on sgts.

This simplifies security policy management. Additionally, trust SEC network devices obtain data from Cisco Ice after they form a secure connection to Cisco Ice. It's called Pac Provisioning. So this information includes a list of radio servers they can use for authentication, the security group to which they belong, and an expiry timeout to control data. refresh rate, The Security Exchange Protocol, or XSP, propagates the IP to SGMT binding table across network devices that are not SGMT capable. SGT reservation enables you to reserve a range of SGTs for IP to SGT mapping. This IP to SGT mapping binds an endpoint IP to SGT and provisions it to a Trusses capable device. Now, this is usually to map SGT to the destination servers. Identitytoport mapping is a method for as witch to define the identity of a port to which an endpoint is connected. It uses this mapping to look up a particular SGT value in Cisco Ice. Okay, so take a moment to notice how non-compliant devices will be tagged. Employee devices will be tagged. Suppliers will also be tagged. Remember, this is tagged as the network access device. Network access devices will only allow sources to reach appropriate destinations based on the Cisco Ice Central Policy. And you can pause the presentation for a moment if you like, and analyse the central policy as it relates to this example.

Okay? Meanwhile, one of the greatest advantages of trustec is that it is topology independent. IP addressing is not relevant to this solution. This independence can improve network performance and scalability, and can greatly ease security administration. So let's take a look at how traditional ACLs play out. Assume we have a set of source IP addresses, S One through S Four, and a set of destination addresses, D One through D Six. So, any S1 source address must be able to access any D1 destination address in this scenario. Now, four permissions are required. They must be able to use HTTP 80, 81, and port 445. All other traffic to these destinations should be denied. So, to ensure that the S One sources can access all six destination ranges with the four permissions, it will require you to create 24 access control entries or Aces in your access control list. Let's suppose that each of the four sourceranges, s2, three, and four, requires similar access. You would have to create a total of 96 aces in your ACL, and these things tend to grow over time. Imagine if you had 400 sources and 300 destinations with the same four aces. That's 480 entries in an ACL. How could this be handled with TrustSec? Well, you merely define your four source groups with say, SGT 1020, 30 and 40, and your three destination server groups with SGT 400, 500, and 600 in this example. So that's four sources times three destinations times the same four permissions. That's only twelve aces. Furthermore, instead of large ACLs being individually managed on each network device, You have small SG ACLs that are centrally managed on Cisco ice.

20. Configure Access Policy for Easy Connect

In this session, we'll be configuring Ise to support Easy Connect. Easy.Connect uses Cisco's passive ID capabilities. to allow Isa to view Windows domain logon events via the Windows Management interface. And then with that, we can authenticate and authorize users that are on wired domain computers without using 821 X to authenticate them. Okay, to start, we'll look at the Passive IDwork center. Passive ID interacts with our Windows domain joinpoint,and we'll see our domain or domain demo local listed as a provider under Active Directory. And then by selecting this, our domain and thenPassive ID, we'll get notified that passive identity needs to be activated on at least one node in the deployment to access this page. Passive ID is not currently running. We need to turn that on within our deployment by clicking on that shortcut that takes us quickly to the deployment screen. "Click on our IC On one node, we can see that passive identity is a service that runs under a policy service note, and we need to have that active on at least one node. So we're doing this on our single node within the lab, and then we'll save that. Now, in order for those pages to actually come up, we need to see the service actually running, and we can see the services related to passiveid are still disabled. We'll wait about two or three minutes for those services to start and pause in the meantime.

Come back after those services have been activated. Okay, picking up where we left off, our Passive IDservices are now all running, as we can see here. Again, this takes about two to three minutes and does not require a reboot of the node in order to activate the passiveid capabilities. Go back into Ise and look at our Passive ID providers again, based on our existing Active Directory join points. And then when we click on Passive ID, we should see that we can modify and add Passive ID domain controllers. We'll add a DC and this brings up what we have available for listed domain controllers within Isse. One of these is kind of adapted and added in. One is the one that we're actually using for our joint point. We can get a little peek at the IP addresses there. So the first one on the list, we got an okay message and indicated that we need to make sure and edit the credentials to make sure they are correct for interaction with WMI. We see our Demo Local listed there, and we'll edit that, information provided, everything but the password.

So we'll supply that and we'll configure it next to WMI. Before we select Configure, notice that we, as an alternative to interacting with WMI, which modifies privileges forour domain user here or domain administrator here, are able to view those WMI log on events. An alternative could be to install an agent on that domain controller, and that would be an alternative to the WMI access that we're doing here, and we'd get information that we've successfully configured and interacted with that domain controller. And then we'll do a test and see if we have a valid connection established successfully interacting with the Windows Server version that BIOS names and we're able to query for history events as needed. We'll save this and then, as a last step, we'll do the piece that actually goes and configures the necessary pieces as related within MI, do a quick configuration here, and see successful configuration of one domain controller with respect to passive ID capabilities and WMI interaction. Okay, that's our first step for interacting with MI on a domain controller on behalf of the Ise Easy Connect solution, which allows users that are on wired domain computers to authenticate without utilizing 821 X. We're instead authenticating directly to the domain controller. Ise views those logged-on events and then can provide an authorization policy based on that event.

21. Configure Access Policy for Easy Connect 2

In this session, we'll be creating a new policy set to support our Easy Connect integration. This policy set, of course, will have its own unique authentication and authorization policies separate from the other policy sets already in place. And of course, as part of building policy, we need to build out policy components to policy elements as part of that policy building process. Let's start that by going into our policyelements and policy results elements results area. Here we see results that can be provided for authentication, which would be allowed. Protocols As you can see, the default network access that has been used for other policy sets is already in place. We're going to do similar here, but limit further access to our Easy Connect policy set. You can see within a lot of protocols that we can check or uncheck the layer two authentication methods that are viable for use. This would be true of either a policy set or an authentication rule. For Easy Connect, the only protocol that's needed is Mac Authentication Bypass or Process Host Lookup, which will leave checked and then uncheck all the other methods. Okay, our new policy set will also include a new authorization policy and new Authorization Rules.

And those authorization rules will need an authorization profile, and one of those authorization profiles will need a new tackle. The Stackle and the authorization profile that will use the Stackle are the base authorization that all anyconnect endpoints will receive upon initial access. This DACA will provide them the ability to communicate and interact with the domain and the domain controller to be able to authenticate the user. And then IC will correlate that user's log on via WMI Lookup and the Mac address of that endpoint. And then we'll provide policy around those two components. Where we could provide a pretty basic IPaccess list here, let's be a little more precise and provide the entries specific to Active Directory communication. You can see that we've got a pre-builtaccess list on our Admin PC for this purpose. We'll take advantage of that and we'll leave the IPV four radio button check, which should then work with our DACA syntax verifier because there's no wild card mass being issued on this access list. And then the Authorization Profile again.

We're creating this authorization profile to provide for all Easy Connect endpoints that initial access to Active Directory. And for this authorization profile will enable passive identity tracking, which will provide that Mac address correlation to the user's look up that's occurring with WMI, and will provide that Daco which allows interaction with the domain controller. Then we'll modify a couple of existing authorization profiles to work with our existing domain accounts. In this case, we'll be providing the standard tackle, but we're also activating passive identity tracking again for that Mac address correlation. It should be noted that this has no effect on the radius authorization attributes that are sent to an ad. This is simply for system tracking within itself. Let's do that for contractors. Let's do it for our employee users as well. Okay, so now we've got a new DACL, a new authorization profile created and a couple of authorization profiles modified, all to support passive identity tracking and to provide the necessary access to interact with Active Directory as part of the Easy Connect solution. Okay, let's create our new policy set now. And we've opened up the Policy Sets view. We can see our existing wired and wireless along with the default policy set, and we're going to add a new one. And again, as a reminder, all rules and conditions within Ise are evaluated top to bottom.

So we've added a new one at the top for our Easy Connect testing. And just as an example, where we're trying to be very precise with the entities that are allowed to interact with our Easy Connect policy set, we'll find an example of the kind of precision that can be applied for condition matching within a policy set match or an authentication rule match. Either way, in this case, one value that we'll want to match for sure is that it's a wired map. And we can combine that with a radius attribute that will focus on the IP address of the network access device sending the access request. Scroll to the bottom of this list and we can see Nas IP address, which is the radius attribute being sent with that information. And we want to match something specific, in this case, the management IP address of our three K access switches. We can combine this to make it even more precise and focus on the actual switch port that's used for access.

Click on the port and we can see that Nas port ID is our option there. And in this case, this attribute being sent by the NAD as part of the access request is quite specific to iOS and formatted. Just so, no abbreviations and it's case sensitive, and we'll take advantage of our cheat sheet for that aspect as well. And this is the switch the portable court PC is connected to. So there's our new policy set with very precise conditions. The only other remaining item is to define the protocols that we allow for access, and we'll pick our new Easy Connect Protocol set, which has only one map activated. Then we'll save this. Okay, now let's develop our authentication policy.

In this case, we could take advantage of the existing default rule and modify it such that we'll authenticate and validate against internal endpoints. And because the Easy Connect solution relies on Map in the way that it does, it will anticipate a decent amount of map failure to occur. It's a very dynamic process as users log in and log out. As a result, in all cases where authentication fails or a map user cannot be found, we want to continue with authorization processing. Now, for our authorization rules, we'll modify the existing default rule and clear out the deny access authorization profile and replace it with ad access.

And again, ad access, providing all the necessary communication ports for Active Directory and activating passive identity tracking. And then a rule for our employees. And conditions here work very much like they do with the Active Directory join point, except they're specific to Passive ID and the tracking service that relates. And because that ties to our Active Directory join point, we see those Active Directory groups there and we'll select our modified Employee Access Authorization Profile, which has been updated to support passive identity tracking, take advantage of duplicate and modify this for our contractors, and save our policy set. So, in review, we've just created a new policy set with very precise condition matching in order to utilize this policy set, an authentication role that authenticates against our internal endpoints and anticipates map failure in order to process against easy Connect lookup service, and then authorization rules that turn on passive identity tracking and provide appropriate permissions for the users as they access.

Study with ExamSnap to prepare for Cisco CCNP Security Practice Test Questions and Answers, Study Guide, and a comprehensive Video Training Course. Powered by the popular VCE format, Cisco CCNP Security Certification Exam Dumps compiled by the industry experts to make sure that you get verified answers. Our Product team ensures that our exams provide Cisco CCNP Security Practice Test Questions & Exam Dumps that are up-to-date.