Pass Your Cisco CCNP Security Certification Easy!

Prepare with top-notch Cisco CCNP Security certification practice test questions and answers, vce exam dumps, study guide, video training course from ExamCollection. All Cisco CCNP Security certification exam dumps & practice test questions and answers are uploaded by users who have passed the exam themselves and formatted them into vce file format.

Cisco ISE Policy Enforcement

8. Introducing Cisco ISE Policy 2

After successful authentication, authorization controls client access levels, perhaps along with the posture service, the profiler, or maybe guest services. Our focus is on authorization. Cisco's uses a modular network authorization policy based on a set of rules. If a particular user and group identity are matched along with a set of conditions, then an appropriate authorization profile is applied. This profile is pushed from the CiscoIce Policy Service node to the network access device to enforce appropriate permissions. Authorization profiles can include several elements to control user access permissions. Cisco Ice can push downloadable access controllists, or DACLs, to an access switch for a particular user session. As a result, when a contractor connects to a port, they may have very limited access, but when an employee connects to the same port later, they have elevated access. Cisco Is can reference named ACLs configured on a wireless LAN controller or WLC. Thus, various users can connect to the same WLN and gain appropriate access levels. Users can be redirected to a particular portal for further actions such as posture client download, central web authentication or CWA, device registration, web authentication or DRW, native supplicant provisioning or NSP, and more. And when you attach to a wired port or wireless SSID, you are assigned to the default VLAN as configured. However, Cisco Ice can override this default VLAN and assign certain users to a different VLAN, perhaps based on an AD group membership or some other criteria. Security group tags, or SGTs, can be applied to each data packet based on user identity. Security Group Access Control Lists, or SGACLscan, control permissions based on these tags with a very scalable, centralised policy. So the methods I've described are quite common. But Cisco supports other authorization profile elements, including voicedomain permission, autosmart port, filter ID, max SEC policy, neat as a VPN, and much more. Whatever authorization profile elements you use to control it, this access can change over the life of a user session. Now, this is called a change of authorization. Or COA. The Cisco Ice Radius server can use COA to dynamically update client authorization levels as defined in RFC 51 76.Let's look at a simplified example where Auth C is short for authentication and Auth Z is used for authorization. Initially, a switchboard is in an unauthenticated state. The switchboard ACL allows only basic network functionality. Now, this functionality might include DHCP-based IP address assignment, TFTP, the download of IPphone configurations, Active Directory machine authentication, and 802.1X authentication. The connected endpoint uses 802 onex in this case, and to successfully authenticate the CiscoIce authentication server, it sends a Radius accessed accept message to the NAD. The NAD forwards an EAP success message to the endpoint. Now, although Cisco Ice is aware of the user identity, it has not yet performed a posture assessment. As such, it selects a temporary policy for this session with reduced levels of access. Now, Cisco sends a Radius Accept message to the switch specifying an authorization policy with a DACA or downloadable ACL that allows two things one, IP connectivity to Cisco Ice to allow the posture assessment to complete, and two, IP connectivity to a remediation server in case the posture assessment fails. The posture assessment is complete and the endpoint is found to be compliant. Cisco is sending a COA message to the switch. This updates the switch port authorization policy, granting full network access. And remember, this is all controlled by Cisco ICE. Policy set hierarchy: policy sets control allowed protocols. In this example, policy set one applies to wired users who are allowed to use MAB and EEP TLS authentication. Wireless users may authenticate via Peep or Eepls. Now, each policy set can contain an authentication policy, which controls which ID sources to check for credentials. Each policy set also has authorization policy rules that determine permission for larger typical user groups such as employees or contractors. Now, in addition to these regular authorization policies, you can also configure policy exceptions to your normal authorization policy. Exception policies are used to meet an immediate or short-term need, authorising a limited number of users, devices, or groups. Exception rules are often used with Cisco Endpoint Protection Services, or EPS, to dynamically quarantine a set of hosts. Every policy set contains the policy shown here. When you configure a local exception policy in a policy set, it is, as the name implies, local. It affects only that policy set. However, there is only one global exception policy. Wherever you create it, as Paul said, it is applied to all policy sets.

9. Add Network Device

In this session, we'll be adding network devices to our ISE configuration. Network devices are pretty vital to the general operation of ISE as a Radius server. The network access devices will be configured as Radius clients, and as clients, the network access devices will interact with endpoints on behalf of things like 801 X authentication, for example. Alright, before we actually add the networkdevices themselves, let's add groups that thesenetwork devices will be members of. The network device groups create some better organisation around the devices that we'll create here. Many businesses have a large number of network devices that they use. And then these creations are also matchable components within an authorization policy. For example, we can match these group names against them. Okay, I've selected all device types here. This just makes it a little easier. As we'll see when I click the Add button, that checked box becomes the parent group. I can always reselect a different parent group if needed. And we'll add a device group for our wired-access switches and add one for our wireless environment. And then in a similar fashion locations in additionor as an alternate to a particular network devicetype, we can add or match to the particularlocation that device is physically located at. All right? So now as we add network devices, which we'll go ahead and move into now, we can add that network device to a particular location and device type again and utilise that capability for policy matching. Later on, we'll add our wired switch and a reachable IP address. Your alternates for single-host IP addresses must be able to provide a range of addresses. It might be possible to group multiple network access devices up in such a fashion as to be able to match that down below here. We'll leave this intact, but open it up very quickly. The device profile here refers to vendor-specific attributes that are obviously specific to those particular manufacturers. You could see Cisco's added in agood handful of other vendors and theirvendor specific attribute sets and device profiles. The ones that are not on this list, you can manually add yourself or create your own vendor-specific attribute profile or profile VSA set. And you'll find good community support at Cisco's website, likewise for other vendors that are not on this list. And we have our locations and device types that we can put the device in. And then lastly, we'll want to set this up for Radius communication. Of course, this is our Radius server. This will be the Radius client's apparent information. You'll notice that we have the option to change and configure other network device settings, such as TAC X and A P. And of course, trusting check the box to open that drawer and supply a shared secret key that, of course, needs to be matched with a network device and its configuration. And then we'll save this and submit this network device before we add the WLAN controller. Let's double check its configuration. First off, just a quick review. The WLAN controller and its associated access point have multiple WLAN SSIDs configured, and you'll notice that these are all currently disabled. So let's get these WLANs activated. In addition, we'll verify our Radiusconfiguration on the WLAN controller. You can see that we've got a server configured at 1121, which is the IP address of our ISE node that we've configured for our purposes. And for most purposes, we want to have minimal support with Ise as a Radius server to support network user authentication and, as an option, to be able to support management. But be aware that usually we are wanting to separate the two things, management-type access or the very access that I'm performing right now as I browse into the W lane controller. I'll not want to support Radius authentication for that management access, and I'll disable that. Here's the other configuration for accounting, and we're supporting that for network users to our IC node. Lastly, we'll just double check with wireless. This is a list of our current active access points. We see a Signal active access point, and its administrator status is currently set to Ise. Let's add that WLAN controller, and it will be in HQ as well, but its device type is Wireless, and then likewise the Radius configuration. And we'll verify that password here and save our configuration. Okay, just in a quick review, we can see that we've got two network devices added to our ISE configuration. They're both built by Cisco, thus using the Cisco profile of vendors' specific attributes. For those vendor devices, we could see the locations and device types have been added, and these network devices are pretty well ready to go at this point. For the configuration aspect, we've got all the basic ender pinnings in place for Isenow, where they're active and manageable. It's been integrated with Active Directory as an external identity source, and we valued it in that configuration. And now we've added network devices added.The next step is to create an authentication and authorization policy to support endpoint devices utilising these network devices.

10. Create Wired and Wireless Policy Sets

In this session, we're going to do the first part of our policy building by configuring policy sets within Ise. Let's go ahead and move into that screen right now, and we'll talk a little bit about the functions and capabilities around a policy set. First off, we should note that there's already a default policy set that Cisco puts in place, of course, as a default. Let's take a quick peek at that. We have some examples of authentication policies within the default policy set: one authentication rule for MAB, one for 821 X, and pointing to different identity stores. Kind of almost a plug and play approach there. And then some authorization policy that's best described as an example of policy statements that can be configured. Some of these are active and helpful, such as the blacklist rule, and of course we can see and we'll divulge later, as these sessions move forward, what the contents of these authorization profiles are. But we would expect things like DACA airspace, ACL listings, etc. And then, always at the bottom of both the authentication and authorization rules, there's a default rule that's in place, and typically that's set to deny access. But we've got the opportunity with any policy to be able to manipulate it otherwise. I'm kind of going back to our policy screen. The idea of adding additional policy sets provides value around administrative organization and isolation. Quite likely, policy descriptions for certain functional areas would be different than for others. That would be true of a business unit, a location, or a particular device type. And then individual policy sets also allow the definition of a role-based administration. So some administrators can administer some policy sets and not others. For example, let's create our first policy set. We can take advantage of the plus button to create a new policy set. We can also take advantage of the gearicon to be able to insert new rows. The default policy set is always going to be at the bottom, so you can only insert above that policy set name wired.And then, within this context, we can provide a description. The condition studio is then unlocked by the next box. And this is our first time here. It gives us a quick tour and informs us that we can filter pre-built sets of conditions, usually compound conditions, from a conditions library to create these simple drag-and-drop elements. And you can add to this library as needed and drag and drop over there, and we can add specific conditions to create our own particular elements and then apply that to a particular policy. Click this box here to get rid of that helpful information. In this case we're going to select a particularattribute that's not already built into the library andthey let us know how that works. And we've got unique icons here to provide some categorization, as this is a very large list. And then we can also type in the boxes above the columns to be able to do some quick finding. Okay, as we hover over the icons, that lets us know what we're looking at. As mentioned, this list is quite large, so we'll isolate things a little bit and use the somewhat intuitive icon that we're looking for network devices and device types. And that device type that we did in the previous session has been added to that library, so we didn't have to type anything in there. and we'll have a quite specific match. If we hit the save button here, this will be saved as a library element that we see on the left. So, if we're going to use this repeatedly, we could make it our own library object. In this case, we're going to select used, and now that's just added as a condition to reach into this policy set. And as we're getting network authentication requests from our network access devices, it will match that element that we've configured by virtue of adding that network device. As a result, it will match this specific set of conditions and use this policy set rather than any other. The last thing to select here is abasic policy component which protocols are allowed. This is basically a set of protocols that were created by default. Within that, we can redefine that default network access group or create our own set of allowed protocols, and within that, we would select or deselect eight variations that we would want to be viable or usable within this policy set. The ones that are not checked will mean that they're not allowed to be used in this policy set. The additional policy set that will create and we can savethis here, take advantage of the gear icon where the plusbox is not present and do a new row above andwe'll create a separate policy set for wireless. Now that we've been in the condition studio once already, it's not giving us that helpful information, and we'll do the same operation as we did for the wired policy set. In this case, our device type and then some of the other components that we can match in there are going to be wireless, and likewise the lab protocols within default network access, and we'll save that grouping now. So understand that within each policy set, it has its own containers of authentication and authorization policies that are separate for all intents and purposes from the authentication and authorization policies and other policy sets. And then notice that in this quick view we also get hit counters as these policy sets are matched, so we have a good idea of how they're being utilised from this broad perspective. Likewise, you get hit counters on the individual rules within each policy set, too. All right, this is our first set of building policies and a little bit of organization, not a requirement. All policy that is needed for productionenvironment could be developed and you've utilizewithin the default policy set. There wouldn't be any problem with that. It's just the benefits for organisation aroundthe policies that are needed and thenthe possible need to isolate administration toindividual administrators such as to that.

11. Authentication Policy

In this session, we'll be creating an authentication policy for IC. In our last session, we created individual policy sets in addition to the default policy set to create administration, administrative organisation around authentication and authorization, and policy. Let's open up policy sets now, and we can see our default Wired and Wireless policy sets. Let's expand the Wired policy set. We could see that we do have one authentication policy rule in place, which is the default, and we're going to insert a rule immediately above that. This first rule will configure it for Wired as well as add conditions to support Wired 802.1x. In this case, it's handy that they've got prebuilt library conditions established to utilise that. We'll drag this over and add that to a condition match for our authentication rule. If we expand that out, we can see that it's labelled Wired 821.X, but in fact is matching a radius flowtype as it's being sent by the Wired NAD. In this case, we'll use this to apply it into the authentication rule, and then at the end here, we'll select the identity store that we want to send authentication requests towards, and you can see our demo local there. In this case, we'll select all user IDstores, which will allow us collectively to investigate any possible identity store for 821X authentication. If I expand out the options here, we can seethat we can manipulate the responses from that identity store. If an authentication failure occurs, we'll reject the authentication attempt. But notice we could, in addition or instead of dropping or continuing, continue down to authorization policy processing. We'll leave these defaults intact and then we'll utilise the gear icon to insert a new rule, and we'll set up an authentication rule to support Map. It's important that these labels go in in such a way that when we are doing troubleshooting later on within the live log and etc., That these labels are helpful in terms of understandingwhat exactly was matched and within which policy set. We'll add a similar condition for Wired MAB and use it, as is common with MAB policy, and we'll use this tactic for guest services later on when there's a chance that map failure or map authentication failure will occur. And instead of rejecting the authentication attempt, we'll want to continue to be able to evaluate authorization policy rules and send that unauthenticated user who is a Map failuser a redirect rule, for example, that will redirect them towards a portal where we can gain their credentials and understand who they are, and deal with the Map failure scenario in that fashion. So let's modify this to continue andthen we'll save this policy set. Okay. Going back to policy sets We now have three authorization rules in place for Wired excuse me.Three authentication rules in place for Wired andlet's do likewise for wireless and again. Same tactics here we'll just apply the different labelsspecific to wireless and again library condition specific tosupporting wireless flows coming in from the WLN controllernet that we can see that's specifically matching thatradius flow and those will be attributes that willbe added to the access request from the perspectiveof the Nat add the condition to support matchinga map authentication request and yeah pointing out thatMAB authentication will be sent towards the internal useridentity stores and just like we did for 802one x on wired will do likewise for wirelessand we will modify the options for the maprule to be able to continue if the useris not found and will continue to Authorization policyprocessing to be able to handle that map failure. that map authentication failure, and then we'll say, "Okay, this policy set is okay; Scott has finished adding authentication policy rules to each of our newly added policy sets." Now our next session will move on to develop an authorization policy and begin doing some initial testing.

12. Authorization Policy Part 1

In this session, we will be creating an authorization policy for our wired policy set. As part of building an authorization policy, it's necessary to configure components that will be applied within that authorization rule, particularly the authorization profile, which is the package of radius authorization results that is sent towards the NAD. And, if that authorization profile contains aDACL, we'll have to rebuild that DACAto nest within the authorization profile. By looking here, we can go into our policy configuration area. In addition to policy sets, we see policy elements, and we're focused on policy results within policy results. These are generic, not specific authorizations. We see we've got the ability to manage results for authentication rules, specifically the variations that are allowed to be utilised within authentication. And then for authorization here, we see that we can configure downloadable ACLs, but authorization profiles can't specify the Daco within the authorization profile until it's built. So let's build the Daco first. Cisco's got a couple of default access lists specified in there. By name, it's fairly simple to understand what they're doing. We're going to add our own custom employee access within our lab environment. And then down below here, just some quick checks. The versions and the box below refer to the syntax checker that is done with this Daffle box. as we enter entries for the access list entries.You'll notice down below we have the opportunity to do a check on DACL syntax. This can be a little bit inconsistent in application on ISE, and then understand that not all network devices utilise the same syntax, particularly for things like masking of network ranges. And that would be different from an application on an iOS switch compared to an ASA VPN gateway. So, in this case, we'll check the Agnostic to avoid complications and have faith that I'll be typing this syntax correctly, and then understand that the best syntax checker is going to be to develop out a mock access list on that network device where this will be applied eventually, and understand now that it will be pushed to that network device and digested. And that syntax must be exact in order for any aspect of DACA to be applied. A couple of other notes about the syntax of this DACL. It is very important that the source IP field in the access list entries be left to the keyword "any" as opposed to a host IP address or network range. This ultimately will be a session-based access list as the network device applies it towards that particular interface and the user session on that interface. And this source IP will effectively be treated as the actual host IP address of the end point itself. If you put your IP address in here, you will get prompts. So we'll want to leave it to keyword to develop a separate policy for contractors. One nice feature of the syntax checker is that it will confirm typos like that one, but keep an eye on it, and finally, one ACL Daco that will specify for our domain computers. In this case, this would allow the domain computer to be able to interact with the network even though Auser is not currently accessing that domain computer. And this will allow that domain computer to interact with network resources, maintain Windows updates, and maintain a connection with the domain controller. So the three entries, as well as the notes on the keyword port values or keywords, are acceptable; again, depending on the device, the network device will have to digest this access list in the end. And if again, you're not sure which keywords or numeric values are actually applicable, the best syntax checker is, of course, the network device that will be digesting and receiving this tackle. Okay, so we've got our dacos created. Let's go ahead and move on to create the authorization profiles that will utilise those stacks. And again, remember, the authorization profile is the result that will be specified by matching a particular authorization rule. So these are the results that we'll be providing. Notice that with an authorization profile, you can choose to still do a reject despite what an identity source might have specified, and that under the conditions that you're specifying, you would rather reject the access as opposed to accepting it. And then pointing out, down in the authorization profile, the variety of things that we can deliver via an authorization profile matching an authorization rule. We saw the DACA programme up top there. We can also specify a pre-existing named ACL on the device as opposed to pushing a DACA. We can specify security group information, VLAN changes, voice permissions, web redirection to redirect to a portal smart port configuration, Maxc, and an airspace ACL. This would be one thing that's different about the wireless environment in that we will need to use an airspace ACL and not a DACL for wireless. So, more than one thing can be selected depending on the application and, of course, the device to which this authorization profile will be set to.We've checked DCo. When I click the drop-down box, I can see that I can select the Daco that I created on the previous screen. And then as I go to save this, I can see the actual radius authorization syntax that will be sent towards that network device managing that endpoint. Okay, let's add a separate one for contractors and another one for our domain computers. Okay, just a quick summary there. We've built out the necessary components to complete an authorization rule. The rule typically needs to have an authorization profile specified. We've created those authorization profiles. Each of our current authorization profiles specifies a downloadable ACL to apply toward that user session. And we've just finished constructing those. Okay, at this point, we'll pause and we'll pick things up by actually developing the authorization rules themselves and utilising these components or elements that were built in this session.

ExamCollection provides the complete prep materials in vce files format which include Cisco CCNP Security certification exam dumps, practice test questions and answers, video training course and study guide which help the exam candidates to pass the exams quickly. Fast updates to Cisco CCNP Security certification exam dumps, practice test questions and accurate answers vce verified by industry experts are taken from the latest pool of questions.