Cisco CCNP Security 300-715 SISE – ISE Profiler Part 2

  1. Verification for NAD Configuration for Profiling

Hello. In this video, we will walk through verifying the profiling configuration on our pods, virtual Wireless LAN controller, and three k access switch. We’ll start by opening a new browser tab and then going to the web console of the Wireless LAN controller. I already have a bookmark on my browser that I can click on to go to that URL. I’ll log in to the Wireless Lancontroller with the correct credential that I’ve already saved on my PC. Once I’m logged in and on the Web interface, I’ll navigate to the wireless LAN or WLAN’s section by clicking that tab at the top of the page and then clicking the WLAN’s navigation link on the left side of the new page that shows I’ll click on WLAN. ID one to view the settings for that WLAN, which is the WPA two e w land for my pod.

Next, I’ll click on the Advanced tab to see those configuration settings for WLAN one. Then I’ll scroll down to about halfway down the page until I see the settings for local client profiling. Here I can see that the HTP profiling and Http profiling are both selected. If I had needed to enable one or both of these settings, I’d need to click on Apply to apply the new configuration. That clicking on Apply will also ensure that those settings are applied regardless, I’ll click on OK to close the warning message about changes affecting the WLN. I’ve verified the settings for the clients on that Wireless LAN, so I’ll now return to the Ise console by clicking on that tab in my browser.

Next, I’ll open the console connection to the three k access switch. I’ll log into the switch with the username of Admin and the password of Ice is Cool. Once I’m logged in, I’ll use the En or Enable command to enter Privilege mode on the switch so I can view the configuration of the switch. Now I can use the Show run command with the pipe symbol and then section SNMP server to limit the output of the command to show only the section of the configuration related to the SNMP server settings. From the output I can see that the read only or Ro community is set to ISIS Cool, which matches the configuration in the Ise profiler settings. We disabled SNMP Mac trap queries in the Ise server. The switch is showing that it is set to generate Mac notification traps due to its use in another training lab. This will not affect its interaction with Ise.

I can also see that the SNMP server is set to be the Ise server at ten one. That SNMP version two C will be used with that server. After that, I can use the Show run command with the pipe symbol and then section Mac to limit the output of my command to show only the section of the configuration related to the Mac address notification settings. I see that the switch is configured to notify the SNMP server about any Mac changes, which would include when a Mac address is added or removed from the switch’s address table, or also when a Mac address moves from one switch port to another.

Show run interface VLAN ten shows me that VLAN Ten is configured with two IP helper addresses. One is set to send DHCP probes and requests to the DHCP server in my network, which is at ten 1110. But the other helper address command sends those same DHCP probes and requests to the ISC server at ten 1121 to help with profiling. The endpoints. The lab VLAN ten is used as the regular access VLAN and VLAN 50 is used for guest access. So I’ll repeat the show run command but now for interface VLAN 50 and can see the same IP helper addresses configured on VLAN 50 as well.

  1. Examine Endpoint Data

Hello. In this video we will examine the endpoint data collected since enabling profiling on Cisco Ise. We will start from the Ise admin portal by navigating to Contacts, Visibility and then Endpoints. Here is a list of Endpoints that have been learned since enabling profiling on the server. As a reminder, I can sort this list on any column heading in either either ascending or descending order. As you can see by the Endpoint profile, the first endpoint in the list is the virtual WLC in the lab. I will click on its Mac address to see more details about that endpoint. I’m interested in what attributes have been identified or assigned to this endpoint.

So from here I’ll click on the Attributes tab. In the General Attributes section, I can see the Endpoint policy assigned and also that the Identity Group assignment has been based on profiling. If I scroll down the page to see more under Other Attributes, I can see that the Endpoint source was an SNMP query pro. After scrolling all the way to the bottom of the page, I have counted a total of 21 attributes listed under General Attributes for this endpoint. Clicking the Endpoints tab takes me back to the list of Endpoints. Now I’ll go to the Guest PC in the lab by opening up the Lab Topology map and then clicking the icon for the Guest PC. To save some time.

I’ve already logged onto the guest PC as admin, and I’ve already opened the Windows Seven network and Sharing Center page. Currently the nick shows is disconnected. I’ll click on Change Adapter Settings and I can see that the neck has been disabled. I’ll right click and enable the nick. Now after a few moments, it shows that it is now connected to the Demo local network. Right clicking again, but now selecting Status opens another dialog box. If I click on Details here, I can see that the neck has been assigned an IP address of ten 152 one.

Now I’ll close all of these dialog boxes and return to the Ise admin portal on my Admin PC. I’m still on the list of Endpoints, so I’ll refresh the list to ensure that the entry for the Guest PC is up to date. It shows as the third entry in the list. I will click on this entry and then view the attributes for this Windows Seven PC. I’ll go through them slowly and you can pause the video if you want to look closer at any particular attribute. But there are more than 70 attributes listed for this endpoint.

  1. Creating New Autho Policy with New Logical Profile

Hello. In this video, we will walk through the steps to create a new authorization policy with a new logical profile. Our first step is to create a new logical profile. We will start from the Ise Admin portal by navigating to Work Centers Profiler and then profiling Policies. Once the page loads, I’ll select Logical Profiles from the list on the left. From the list of logical profiles on the right, I will click the Add button to create a new logical profile. The name of my new logical profile will be approved underscore Smart Underscore Devices, and the description will be Devices on the corporate approved Smart Devices list. To assign policies, I’ll select multiple policies from the list on the left by holding down the control key on my keyboard and then selecting each policy that I want to assign. In my case, I want to assign five policies starting with Android, so I’ll select that first.

Then I’ll scroll down the list and also click on Apple iPad, Apple iPhone, Apple iPod, and finally Apple Device. After that, I’ll click on the single right arrow to move the selected policies into the assigned Policies box. Once I verified the configuration, I’ll click on Submit to create the new logical profile. After that, I’m returned to the Logical Profiles list and my new profile shows in the list. I can click on the profile name at any time to verify it or to make changes to it. Note that an endpoint has already been identified as part of this logical profile. My Apple iPad device. Now that our new approved underscore Smart Underscore Devices Logical Profile has been created, the next step is to create the authorization policy that will use the newly created profile. To start, we’ll navigate from the ISC Admin portal to Policy and then Policy sets. Once the page loads, we’ll enter the wireless underscore Access Policy Set, and once there we’ll open the Authorization policy.

Then we’ll click the gear icon next to the Guest Access rule and we will insert a new rule above that policy. The new authorization rule will be named Smart Devices. Then I’ll click on the plus sign to create the condition for the rule. This will open up the Condition Studio, and there I will click on the field to add an attribute. I’ll limit the list of attributes by selecting the Endpoints dictionary. Then from that dictionary, I will select the Logical profile attribute.

The condition box is filled in and next I need to select a profile from the list of profiles in. IFC I’ll click on the empty field to get a list of profiles to choose from, my new profile shows as the first in the list, so I’ll select it. Once my condition looks correct, I’ll click the Use button to close the Condition Studio and return to the Authorization policy. The final step is to apply the Guest Access profile to the rule. I’ll click on the empty field and scroll down the list to where I can select it. The rule is now complete. So I’ll scroll down the page and click on save to save my changes. This new authorization policy is now ready to be tested.

  1. Create a Custom Profile Policy

Hello. In this video, we will walk through the steps to create a custom profile policy for the virtual wireless LAN controller in the lab. We will start from the Ise admin portal by navigating to work centers profiler and then endpoint classification. I could have also reached this page by Navigating to context visibility and then Endpoints. First, we’ll locate our virtual wireless LAN controller, or WL, from the list of Endpoints at the bottom of the page. The Wireless Lang controller may show with an IP address of ten one 10 61, or it may also show with an endpoint profile of Cisco WLC. If neither of these items show, then we may look for a device with an Oui of VMware Inc. Since the WLC in the lab is a virtual WLC running on VMware, in my example, the virtual WLC is the first endpoint showing in the list. I’ll click on the Mac address of the WLC to see more information about that end point. We want to look at some of the attributes for the WLC. So I’ll click on the attributes tab under the general attributes section. Note that the Endpoint policy is currently set to Cisco WLC.

We’ll look under the other Attributes section for three other attributes that we’re interested in. So I’ll scroll down the page. All three of the attributes are now visible for us to see. They are the Oui, which shows as VMware inc. The SNMP system description which shows as Cisco controller. And finally the SNMP system object ID. Which is one 3614-191-1631. We’re going to use these three attributes in the Custom Profile policy that we’re about to create. We can probably remember the Oui and the system description, but I’ll copy the Object ID to my computer’s clipboard so that I don’t have to remember that long string of digits. Next, I could navigate to work centers profiler and then profiling policies. But since I’m already on the Work Centers Profiler page, I’ll just click on the tab for Profiling Policies. Once the page loads, I’ll ensure that Profiling Policies is selected in the list on the left side of the page. Then I’ll click the Add button on the right side of the page to add a new profiling policy.

I’ll give this new policy the name of Cisco Vwlc. Note the V in the name. I’ll also type in a description of Policy to detect Cisco Vwlc. Then I’ll change the minimum certainty factor from ten to 20. We’ll create a rule for this policy in a few moments. Each rule in a profiling policy has a minimum certainty metric associated with it to determine how important that rule is in profiling an endpoint. When an endpoint is profiled, the certainty value for each rule that matches with the endpoint is added up. If the value of the rules add up to at least the value I enter into this field, then this is a valid profile for that endpoint. If an endpoint doesn’t match on enough rules to meet this minimum certainty factor, then this profile will not be assigned to that end point.

After that, we’ll leave the radio button set so that ISC will create a matching identity group when this profile policy is created. Next, I’ll choose the parent policy. For this new policy, I’ll scroll about three quarters of the way down the list and then click on VMware Device. Then I’ll move on to create the single rule that this policy will use to profile endpoints. I start by clicking on the plus sign in the Conditions field. This allows me to either select an existing condition from the library to match on or to create a new condition to match the endpoint on. I’ll click on the Create new condition button. I’ll exit out of this for a moment to scroll down the page a bit, but when I click on the plus sign, I’m returned to where I was in editing the condition. I won’t do anything with the condition name. Since this is a new condition, I will click on the arrow in the select attribute box.

This opens up a list of attribute categories for me to choose an attribute from. My first attribute will be the SNMP system description. So I’ll scroll down and open the SNMP folder. In that folder I will scroll down and click on Syscr, which is the shorthand for the System description attribute. SNMP escrow is now in the first part of the expression. In the middle box, I’ll select a comparison operator. I’ll choose equals. Then I’ll type in the value that I want the SNMP system description to equal in the third text box. If you remember from looking at the virtual WLCS attributes the system description with Cisco controller this is a good start. But looking for endpoints with a system description of Cisco controller is probably not specific enough to only identify Cisco virtual WLCS. So I’ll click on the gear icon to the right and then add another attribute to this condition before I configure the second attribute. Note that we can set the attribute matching to either match all attributes or to match any of the attributes. We’ll leave the matching requirement to require a match of all the attributes listed. For the second attribute, I’ll click the dropdown arrow and then scroll down to SMMP again.

But this time I’ll select the sys object ID attribute. I also want that attribute to equal a specific value, so I’ll select equals again. But for the value here, I’ll paste in the System Object ID that I had copied to my Clipboard earlier. Now, this condition requires that the endpoint system description equals Cisco controller and that the endpoint System Object ID equals that big long string of one 3614-191-1631. With these two attributes, we can be pretty sure that the only endpoint that this rule will match is a Cisco virtual WLC. I’ll click outside of this edit box to close it. My final configuration is to change the certainty factor value for this rule from ten to 70. Remember, we set the minimum certainty factor for the profile to be 20.

So if I left this rule at the default value of ten, even when the rule matched the end point, there wouldn’t be enough certainty points to reach the minimum level. Setting this rule to 70 certainty points leaves no doubt that once this rule matches an endpoint, that this profile can be applied to the endpoint. After all of my configuration is complete, I’ll now click on Submit to create the policy. Note the success message indicating that not only the policy is created, but the matching identity group was also created.

I’m returned to the long list of Cisco provided policies, and to make it easy to see my new policy, I’ll click on the System type column header to sort by that column. And now my one administrator created profiling policy is at the top of the list. I’ll return to the Endpoint classification page by clicking that tab. And now I can see that the endpoint profile of Cisco Vwlc has already been applied to my wireless LAN controller. At the top of the list, clicking on the Mac address and then returning to the Attributes tab, I can see that the endpoint policy is Cisco VWL, but the identity group of Cisco Vwlc has also been assigned to this endpoint. Those same assignments show under the other attributes listing as well.

  1. Testing Autho Policies with Profiling Data

Hello. In this video, we will access the lab network with our iPad to see that it matches the Smart Devices authorization policy that was created in another lab task. We’ll start by accessing the iPad in the lab. Once on the iPad, we’ll click on Settings and then WiFi to verify the WiFi status of the iPad. The iPad in my lab isn’t currently connected to any WiFi Fi networks.

However, I’ll go ahead and connect to my Pods Guest Network 20 Guest to show you the steps that you may need to follow if your lab iPad is already connected to a network. The Blue check mark next to the network name indicates that the iPad is connected. To disconnect it, I’ll click on the Blue information circle with the I to the right of the network name. Then I’ll click on Forget this Network and then click on Forget a second time in the Confirmation dialog box. The goal before moving forward is that the WiFi status on the iPad shows as not connected. After we’ve verified that the iPad is not connected, we’ll return to the ISC admin portal and then navigate to Work Centers Profiler and then Endpoint Classification. We’ll locate the entry for the iPad and the list of endpoints based on the Endpoint profile showing us Apple Nash iPad, along with the Oui showing as Apple Inc.

I can see that the iPad is the fifth device listed on my system. I’ll click the checkbox to select that endpoint and then click on the trash can at the top of the list to start the deletion of that entry. I’ll choose Selected to delete only the selected entry, and then I’ll click on yes to confirm the deletion of the entry. The entry is then deleted from the list. Next, I’ll go to the web console of the Virtual Wireless LAN Controller, or Vwlc in my lab. On the Vwlc, I’ll navigate to Monitor on the top tab and then click on Clients in the left navigation bar. If the client list still shows the iPad, I’ll click on the Mac address for the client to view the client details, and from there, I’ll click on the Remove button at the top right part of the page to remove this client from the WLC’s client list, I’ll click on OK to close the confirmation box and to return to the client list. If the client still shows, I may need to refresh the display to verify that it has been removed. Now I’ll return to the iPad and reconnect it to the guest network for my pod. If I’m not still on the WiFi Settings page, I’d click on Settings and then WiFi to get back to this page.

Then I’ll scroll down the list of available networks and click on my podcast Guest Network 20 Guest to connect back to it. The Blue check mark indicates a successful connection, but I’ll use the Home button to return to the Home screen on the iPad and then run the Safari browser from there. Note that if your lab has been configured with a captive portal on the guest WLAN, you may need to log into the portal using the username of employee one at Demo local and the password of Isiscool. My guest network is not configured with a captive portal. Once I verified connectivity, I’ll close my iPad viewer and return to the Ise Admin portal. From the Admin portal, I’ll navigate to Operations radius and then live logs. Once I locate my iPad and then scroll to the right, I can see that it has assigned the guest Access authorization profile.

Next, I’ll navigate to context visibility and then endpoints. The iPad is showing in the endpoint list again. When I click on its Mac address and then click on the Attributes tab. I’ll scroll about halfway down the page and from there I can see that the logical profile assignment is Mobile Devices and then approved Smart Devices, which is the logical profile that was created in an earlier lab. In the final few steps in this lab, I’ll do some clean up. I’ll now navigate the policy and then policy sets. Once that page loads, I’ll enter into the wireless access policy set. Then I’ll open the authorization policy. In there, I’ll locate the Smart Devices rule and then click on the checkmark to the left of it. To disable that rule. The green checkmark should turn into a gray disabled symbol. Once I’m sure that the rule has been disabled, I will scroll to the bottom of the page and then click Save to save my change.

  1. Create Cisco ISE Profiling Reports 1

Hello. In this video we will look at profiler feed reports. We’ll start off by reviewing reports that are based on profiling data that was gathered in previous labs. Our first step in doing so is to navigate to Work Centers Profiler and then Feed. We’ll scroll to the bottom of Profiler Feed service configuration page where we can see information about the latest profiler feed update. Here we’ll see first verify that there is a timestamp showing when the latest applied feed occurred. If you are not able to see a time stamp in your own lab, you may need to verify and troubleshoot why the Cisco Profile feed service is not working for your lab. There is a button here that allows me to undo the latest changes that were made based on the feed shown by the timestamp, but I’m more interested in the link below the button that says Go to Update Report page.

I’ll click on that link and a new tab opens in my browser. On this new page, the change configuration auto report is shown but it has been filtered to show only the entries where the administrator of the change is the Cisco feed service. Scrolling down the list of entries shows where the feed service has changed existing profile configurations and also where the feed service has added new profile configurations, both shown as the type of event. Under objects you can see different types of endpoints and also some of the rules used when profiling. I’ll scroll down the list of changes until I find an entry where the event type shows as added configuration.

Clicking on that event opens another tab with more details about the entry. From the Details page I can see the object type was an endpoint policy and that the object in this case was workstations running the Catalina release of macOS. Again, the event was that this configuration was added to my Ise system. A lot more details are shown under Modified Properties. If I hover my mouse over the entry, I can see the full details of the event. I’ll close the Details tab for the added configuration event. Next, let’s click to see the details of a change configuration event. Another tab opens up with those details. In this case, the object type was a rule for an HP color laser Jet multifunction cleaner. The server details remain the same and more details show under the Modified Property section. And again, hovering my mouse over this item shows even more information about the change configuration.

I’ll close the two report tabs on my browser and will now load the Opera email client by clicking on its icon which is located on the desktop of my admin PC. The Opera client shows that I have a number of emails related to the Ise feed. The very top message is not part of the plan lab, but I’ll point it out. This email indicates that the automated feed service failed at 100 and 06:00 a. m. On Friday. This is likely related to certificate issues between my Ise server and the Cisco feed service. I’ll try to resolve that issue later. We can, however, follow the Lap steps and view the emails that were received on Thursday when the feed updated successfully.

The top message from Thursday is the feed our applied. Update email. If I click on it, I can see that when the update occurred, 5374 Ouis were added and 766 Ouis were updated. This large number shows because this is the very first time that the update was run on my ISC system, the numbers of additions and updates shown on your own system will probably be different. The second email that we’ll look at is the one titled Feed Policy is Applied Update. This email shows that version one, version two, and version three policies were downloaded, 243 policies were identified to be applied, and 243 policies were applied to my system. As with the Our updates, the number that you see on your own system may be different from what I show here.

  1. Create Cisco ISE Profiling Reports 2

Hello. In this video, we will look at Endpoint profile changes and Summary reports. And finally we’ll view the homepage dash lets Reports. I could navigate to Work Centers, Profiler and then Reports, but since I’m already in the profiler pages under Work Centers, I’ll click on the tab for Reports. From here in the report selector pane I’ll navigate to reports, profiler reports and then endpoint profile changes. The Endpoint profile change report has two sections. At the very top of the report, I can set a filter to have one or more rules. The first rule is always the time range. I’ll set that time range to be seven days. If I want more specific filtering, I can click the plus sign to add another rule.

For the other rules, I can filter based on the Endpoint profile, the Endpoint ID or to show only changes as a result of the feed service, or to show only endpoints with change profiles in the totals that will be shown in the pie charts. For this lab, I only care about setting the time range to be seven days, so I will not set any other rules. And I’ll click the Go button to generate the pie chart. Report. The first pie chart shows the endpoint allocations prior to the last seven days. I can see there were six endpoints, two of which were 33. 33% of which were unknown, and of the other four endpoints, each accounting for 16. 67% of the endpoints were assigned different profiles. Two of the profiles are easy to identify cisco Vwlc and Apple iPad. If I hover over the profile names, I can see the full names. The top one is Windows seven Dash Workstation.

And the bottom one is Microsoft Workstation. Hovering over each name also shows the number of endpoints for each profile in parentheses. After the profile name scrolling down to the after pie chart shows much the same, except it looks like the two unknown endpoints above were assigned the Android profile. In the artery chart. Scrolling down to the bottom of the page shows a list of endpoint profile changes. Expanding out the third column in the list better shows that that column is an indicator of whether the profile change was due to a feed service update. The green boxes with check marks mean yes and the red circles with X’s mean no. I can also see when the profile change occurred. Clicking the Details icon for any entry loads a new browser tab with a large number of details, including the probe that caused the assignment of the profile, but also a history of the profile changes. For that endpoint, I’ll close this tab and return to the Reports portal.

Now I’ll select profiled endpoint summary from the list of reports. The Profiled Endpoint Summary Report provides profiling details about endpoints that access the network during the time period selected. In my example, there are three endpoints currently connected to my network and assign profiles my virtual WLC, my admin PC showing as Microsoft Workstation and the iPad that is in my laptop. If I expand the time frame out to be the last seven days, I see two other endpoints in the list. As with most lists and Ise, I can use the Gear icon to choose which columns are shown and which order they are shown in. I can also choose between the Quick filter of certain columns or the Advanced filter.

I do not need to filter my short list of endpoints, so I’ll go back to the list and now click on the Details icon for the iPad. As before, a new tab is open in my browser and now I see the details for that device, much the same as what was shown for details in the Endpoint Profile Changes report earlier. Clicking on the Raw log icon for the iPad opens a tab to show each logged event related to that profile endpoint. If I scroll all the way to the right, I can go down the list of endpoint properties next to each entry. There I can click on the Target icon to see a very long list of details around that entry. I will close this tab and also return to the Ise Admin portal homepage. For the final part of this video, we will view the metrics available via the Context Visibility feature.

As such, I’ll navigate to context visibility and then endpoints. Once there, I’ll click on the tab for Endpoint classification. I’ll click the new window icon in the Endpoints dashboard to Detach, and then open that dashboard in a new tab to allow me to drill down for more details. Once the new tab is loaded, I click on the Profile tab to observe all of the profile endpoints that if he has seen. As with the pie charts we saw a few minutes ago, hovering over the name of a profile shows me the full profile name and the number of endpoints that were assigned that profile. However, in this display, clicking on that portion of the ring also shows the number of devices in the center of the ring. Remember that originally two devices were unknown, and then later they were assigned the Android profile. That is why this graph adds up to a total of eight devices showing the two after they were assigned the Android profile, but showing them again as two when they were unknown. I can see the same information by also navigating to Home, then Summary, and then Endpoints from there.