Cisco ISE Policy Enforcement

13. Authorization Policy Part 2

In this session, we'll be completing the steps necessary to configure an Authorization Policy for our Wired Policy Set. In the previous session, we created components for those authorization rules, in particular theDACLs that we applied within Authorization Profilefiles for our wired contractors, wired employees,and wired domain computers. Now let's take a look at what we've got for authorization policy in place,currently within the Wired Policy set. So I've selected Policy Sets and we'll expand into that and recall that we have an Authentication Policy already created. And now we're focusing on the authorization policy that is currently in place. The only thing in existence is a defaultAuthorization Rule, which upon matching those with no other conditions to match, will deny access to whatever endpoints are attempting to utilise this. Examine that from the standpoint of our wired switch, and then simulate a client authentication from the standpoint of our network access device. And here we're implying the employee or user credentials and password and with the iOS switch, because we're working with AAA's new model to develop our local policy on that iOS switch, we're specifying a new code to create that authentication match and we quickly get a user rejected with that. All right, so let's develop an authorization policy and correct that. So back on ise, let's add a new authorization rule and this first one we'll create will be for our wired employees and we'll use the ConditionStudio and take advantage of our Active Directory integration and the groups that we imported when we did the Active Directory integration with the Joinpoint. We can select those attributes here. So the preexisting attributes will want Identity Group and we can see that Demo Local has been added to this list and is referencing external groups as an attribute. And then the group that we're wanting to match in this case is employees. And again, these groups are showing up as a result of that important operation that was done with the Joinpoint And again, we can save this if we desire to add it to the library, and we can drag and drop this as a selection in the future. We'll use this so it applies to our rule and we can see the full rule listed out. And then we'll select the authorization profile that we created to support employee access. Notice In addition to an authorization profile, we could also select a trust security group, and this is an either or or situation. A security group or an authorization profile could be involved. Or both. Let's add another rule immediately above this one before we save the policy set and add one for our contractusers. Select the contractors from our Demo Local domain. Again, if a particular group is not showing up on that list, we can always rerun the import operation at the Joinpoint and add those newly created Active Directory groups and add one for our domain computers. Again, for matching concepts. There is quite a bit of flexibility for components or objects that can be matched from within the Active Directory realm. And making that easy is, of course, the prebuilt ous that Active Directory places in there. And we get to take advantage of that. To make sure and add the authorization profile. So we've got the one for contractors and the one for domain computers. So add a couple more rules. For example, in this case, some of these are rules that are provided as examples within the default policy set. And here we're getting a little tour of some of the other conditions that we can match against. In this case, we'll take advantage of a prebuilt library object. If we hover over the internals of that,it's looking for a logical profile, which is a concept that is developed out with theprofiler, and we create a logical profile. This one was created by Cisco, of course. And as objects' Mac addresses are discovered to be non-Cisco phones, they'll be added to this IP phone's logical profile. And in this case, we'll make sure to apply a specific policy to support that. And in this case, Cisco has provided an authorization profile to support non-Cisco IP phone access. And then, in a similar fashion, we'll use the conditions studio and select another variation on identity matching for policy component matching. And then in this case, along with logical profiles, we also have identity groups. And these, again, are internal concepts. Both internal users and internal endpoints are added to these groups, and we're looking for a specific one for Cisco phones. And so again, same process with profiler that CiscoIP phones will be added to this endpoint identitygroup, and we'll provide policy to support those here. Okay, we'll save this policy set and it will apply. We can see the newly added rules with the pencil icon and know that we're going to be saving those rules. And it does an overall syntax check to make sure we're not missing any pieces. And in this case, we're all completely successful. And looking at our authorization policy, we can see the names, the conditions that we're matching, and the authorization profile or results that will be applied when these rules are matched. Again, the rule processing is hierarchical, so we will start at the top and work our way down towards the bottom. And ultimately, what we're trying to avoid is matching this default rule. We're trying to put conditions in place such that we're providing some sort of access. The labels are fairly important with respect to troubleshooting. When we go around and look in the live blog,these labels will be utilised as a final test here. Let's go back and retry from our access switch. And in this case, we get success. And we can see that as part of that authorization if it was a user endpoint session that applied ourACL employee DACL to that authorization, and this is what ISIS as a rating server would have received. All right, that completes our wired policy authorization rules, and we're ready to move forward with wireless in our next session.

14. Wireless Access Authorization Policy Rules

In this session, we'll be adding rules to create an authorization policy for our wireless policy set. And just like the rules for authorization rules under the Wired Policy Set, we need to create authorization profiles first before we create those authorization rules. So let's go back to policy and policy elements and results. And we're looking to create authorization profiles that we'll add in a similar fashion to WiredPolicy Authorization Profiles to support our wireless environment. Unlike in the wired environment, the WLAN controller is not able to support the downloadable ACL concept. An airspace ACL will be used to create an IP-based access policy for endpoints and users. The airspace ACL is precreated on the WLN controller in order for this function to be viable. In this case, we have no drop down because this is not a configured element or component on Ise. It's configured on the WLAN controller. So we need to make sure that we specify that exactly as created on the WLAN controller. And again, we can verify these results down here at the bottom. And while we've mentioned the WLAN controller, let's take a quick peek to see what we've got for access list components on that side. And you can see we've got a handful of ACLs in place. Let's open this employee ACL. And you can see, just like the DACA that we created, that we're denying access to particular elements of the network and permitting it elsewhere. Let's go back to Ise one, and we'll continue adding authorization profiles for wireless. And again, just like with all ACLs, both oniOS and airspace, those are case-sensitive entities. And one more for the domain computer. So now we've got our wireless authorization profiles created. Let's now create the authorization rules in order to support wireless access. Go back to policy sets. In this case, we're editing the Wireless PolicySet and Authorization rules to support wireless. And again, just like we saw originally with the Wired Policy Set, we've got just the default rule in place currently denying access. So we'll want to add rules. In this case, we'll use the exact same conditions that were used for matching under the Wired Policy Set. And we'll add the newly created Wireless Authorization Profile for this aspect. Let's add an additional rule for our employees. Let's add the Authorization Profile and an additional rule for our contractors. You can see where the condition studio prevents possible typo issues. A lot of drag and drop. These are all specific values. And in addition to just the visual name that we're looking at there for those ad groups, it's the sidvalue that's being returned and actually matched by IC. As well as the authorization profile for this. And we'll add another rule in a similar fashion to the default policy set to support blacklisting of wireless devices and see some of the other conditions that could be matched in the authorization profiles. In this case, ISC has a specific identity group to contain blacklist entities, and we can see that here. Devices that are reported lost or stolen can be automatically added to the blacklist in some cases, such as with BYOD Solutions. In most cases, This is a manual ad that we're adding Macaddresses to this list to take action on it.And the action that we'll take is the one that Cisco has provided for us by default. This black hole wireless accesspoint provides a redirection URL. So a device that's been blacklisted will still get access, but they'll be redirected to a portal, indicating that they've been blacklisted. So a blacklist portal? All right, we'll save this policy. And again, just as a reminder, this is an ahierarchical policy, so we'll be evaluating these rules from top to bottom until a match is found. We can rearrange that hierarchy by doing a drag and drop on the other side here. And the naming and labels are important. When we go to do troubleshooting with the livelog, etcetera, we'll see matches against these rule names, which will help us analyse exactly the flow through Ise. His rules are being matched and evaluated.

15. Creating Global Exception

In this session, we'll be updating our existing authorization policy rules by creating an exception policy. Let's take a look at our existing wiredpolicy set and explain what exception policy provides. , general processing within Iseis is handled hierarchically, as we see visibly here. We evaluate the authentication policy first, which drives us to a particular identity provider which collects additional attributes. And then we process it through authorization. And you'll notice that we've got two areas for exceptions here. Local exceptions which are local to this policy set and will only apply to this policy set. And then global exceptions and rules that we have within global exceptions would apply towards all policy sets. And then we would evaluate our standardisation policy for this policy set. In this case, again, the hierarchy is there. As a result, local exceptions are evaluated before global exceptions, which are evaluated before the authorization policy. They operate identically and they are configured identically to what we would put into a standard authorization rule. Let's go ahead and add a new rule for aglobal exception and we'll see that the Condition Studio works the same and we will see the same conditions in this list as we would see for any otherauthorization rule on our ISEE deployment here. Selecting one of our domain groups For our condition match, Focus on It staff for our And then if we match that particular group name with authentication, Then we will authorise the Cisco built-in permit access authorization profile. This particular authorization profile is not editable. You can't manage what's in there, but byinvestigating it, you'll be informed that what's happening is it's providing an access accept via theRadius authorization messages that go back towards theNAD for a user session. Let's save this policy and then let's try this out on our access switch. And we'll duplicate a user authentication from the commandline, domain user and domain password, and process throughAAA new model rules on this access switch. And of course, we get a quick message back that we're successfully authenticated. Unlike our previous test, we don't have any more specific authorization other than access, except we're not seeing any of those details other than the fact that we successfully authenticated our It One user. Let's investigate this from ISC's perspective. We'll open up operations and Radius live logs. Yeah, we should see a new entry for our It One local account. We can expand out and see what wematch for authentication and authorization and then, ultimately, the authorization profile that's being provided. So some nice summary details right up front should point out that because of the tests that we're running from the switch, neither 821.X or MAB are being utilised for this authentication access request. So we're matching the wire defaultrule and not the wired 821.X or Wiredman in this case. That's allowing that default authentication rule to allow access without interacting with an identity source. It drove that towards all user ID stores and matched them to our active directory domain and learned that they're part of the IT group and matched the authorization rule within our exception policy. We look at the details this will reveal in terms of the interactions. So ultimately, it accessed all user ID stores,went through all ad joinpoints, and finally determined that demo local was what needed to be accessed. At the bottom, we achieved our Radius access acceptance and we also see authentication successful here in the detail. Okay, going back to our policy sets, we can see that we've got one hit against our wired policy set, one hit against our new global exception rule, and one hit against our old global exception rule. And of course, now we're looking at this from within the wired policy set. Let's investigate the wireless policy set. In this case, we're seeing the global exception and one rule has been added to that global exception policy and we see the match counter on that particular rule. So it didn't match the policy set itself because it didn't come through from a wirelessNAD as part of evaluating the policy set. But we did get a hit on the individual rule itself. Okay, just a quick tour of the exception policy again can be advantageous to create systemic or environmental type exceptions. It could be a temporary exception for something that you're trying to work around, say something with network or some other sort of disruption and exceptions so that we can get a nice consistent set of authorization policies applied to all policy sets regardless of what else that they're achieving below.

16. Testing Wired Client Access Part 1

In this session, we'll be testing Wired client access utilising the policies within our Wired PolicySet and in conjunction with our Wired ThreeK access switch acting as an AAAA Radius client. Let's review the policies within the WiredPolicySet before we begin testing. And within the Wired Policy Set, we've got an Authentication Policy to address both MAB and 821X authentication as well as the default fortesting from the Wired Nat itself. MAB will authenticate against internal endpoints, while 821.X will authenticate against all user ID stores, which will, of course, include our demo local join point. We also have an Authorization Policy Global Exception in place, allowing our IT staff to have a generic permit access above and beyond Standard Authorization Policy.And that, of course, would apply to all policy sets as a global exception. And then we have our Standard Authorization Policy, which includes a variety of statements, some of which we need to focus on for our current testing. One thing to note is the hierarchy again. And as a reminder, things will be evaluated from the top down and we'll be matching the domain computers ahead of contractors or employees, which could be problematic. Once we create a match, we deliver the results and processing could be exacerbated and problematic as a result of this hierarchy. So let's modify this rule so Domain Computers is the last one on this list ahead of the default rule and then save this policy. Then, in preparation for testing, we will modify some settings within the live blog. By default, the live log is set up to never refresh automatically. You can manually refresh at any time by hitting the refresh button, but let's do something a little more dynamic and we'll update the refresh timer to every 10 seconds. You'll notice additional filtering can be applied as well in terms of the latest records and over the latest duration of time. Okay, now let's go ahead and open up a session on our Core PC, which is our wired computer within our lab environment and is also a domain member, which will allow us to do the 802 x authentication in our initial login. Here before testing, we will log in as the machine's local administrator before we log into our adomain account to make sure we can modify the next settings appropriately for our test. Here we'll open up Network and Sharing settings and look at the adapters available on the court PC. The Nic on the core PC is currently disabled, so we'll enable it. And as we investigate properties here, one thing to point out is that the Nic properties are missing the authentication tab, which is required for 802 One X authentication and modifying the settings related to that to launch the nativeWindows 802 One X Applicant for Windows. This is the Wired Auto Config Service. Let's check on its current status. And we can see the Wired AutoConfig Service has not started and is currently disabled. And as we open up properties, we can see this is the service responsible for performing 821 x authentication. We will set that service to automatically start on subsequent reboots and then we'll start the service. You can see almost right away that we got a warning. An informational warning pops up from the neck itself, and we see that the neck is attempting to authenticate. Now that Auto Config Services has started, let's review the settings quickly with the neck itself and under the authentication tab, we see that we've got it enabled for 802 next, performing peep based authentication and that we're validating a server certificate. This would be the ID certificate that ourIse Radius server would be delivering to perform the first step of authentication. And we'll be validating that server signature with a root CA, which is our Microsoft Domain controller certificate authority. Looking at some additional settings, we also have the Microsoft 820 x Supplicant configured to support either user or computer authentication. This would be effectively an and or and we've got the Supplicant and neck property set to remember credentials each time the Windows Core PC is logged into. Okay, now that we've verified the settings, let's go ahead and do a restart and we can evaluate the machine authentication. Go back to the live log and watch the operations continue.

17. Testing Wired Client Access Part 2

The core PC has been completely rebooted. And in the lab log, we see some reflections on the interactions that have occurred up to this point. begin by starting off with this particular entry. In fact, let's create a little bit of afilter to hide just the court PC Mac address. And we can see that we have an initial map authentication attempt which has failed. This is because we don't have that Mac address added to our internal identity endpoint data store. We see an authentication with Admin, which we did when we initially accessed the machine. And as soon as we fired up the 801 x supplicant,it attempted to log in with that local machine account. And then, subsequent to the reboot, we see that the machine has identified itself as W Seven Pccorp demo local. And we provided a domain computers authorization profile based on a wired eight OneX authentication policy domain computers authorization. And then finally, this session-related information. This would be the network access device receiving the contents of the DACA. Let's go back and validate that our authorization has been successful for WPC Seven Corp. And in this case, we'll log into a domain account. You can see that we are a domain member computer and the account that we're typing in is a domain account. Just to make sure our hood comes up authenticated. We see that we've got Internet access from the perspective of the domain computer. And if you'll recall, our authorization policy was limiting access to particular networks, in this case, the quarantine network. Let's do a quick pink test here. With authorization on employees, we disallowed access to the quarantine network, which was the ten 130.And here we're paying in the gateway address for that, which actually resides on the three K access switches that we're currently accessing. And we can see that we're not able to achieve that. The other network that we were trying to create policy around was the AP network. In this case, we allowed employees to access the APnetwork and we see the positive results of that. OK, well, let's investigate things from the perspective of the wired access switch. And here we can do a show command which will reflect the authentication status of the interface that the core PC is connected to. And we'll do the detail screen to see the authorizations that were provided. So here we can see on G 101 that we have authenticated with demo employee One and that the status of that session is authorized. And we can see that we delivered as part of that authorization our ACL employee Dacle, which the iOS NADhas prefixed and suffixed with its own values to make a unique session-based access list. And we can see finally at the bottom that we have authentication success with One X. Now for the final part of our test, let's return to the port PC and log out as employee. Then we'll log back in as the contractor user, and see that we've got a valid Nic session in place. We'll do a similar test, as we did with the employee, to verify network access. And as a reminder, in the case of the contractor authorization profile, we disallowed access to both the quarantine networks and the AP networks. So we should have a lack of success for both of these tests. In this case, yes, we see a lack of success. The TTL expired, not being able to reach that particular IP, and we should see similar negative impacts on 90, which would be the AP network. And so our authorization appears to be valid from the perspective of the client. The PC itself can go back and review information within the live log, and we can see a transition. We logged in as employee one, and as we logged out as employee one, the computer logged itself back in, and then we logged in as contractor one, which matched our authentication policy and the desired authorization policy and delivered the correct authorization profile for that. And just to review, we successfully accomplished wired access tests for our wired clients and wired endpoints and saw the positive results both within the live log as well as on the network access device and the end point client, PC Corp. PC itself.

ExamSnap's Cisco 300-715 Practice Test Questions and Exam Dumps, study guide, and video training course are complicated in premium bundle. The Exam Updated are monitored by Industry Leading IT Trainers with over 15 years of experience, Cisco 300-715 Exam Dumps and Practice Test Questions cover all the Exam Objectives to make sure you pass your exam easily.