Cisco CCNP Security 300-715 SISE – Web Auth and Guest Services

10. Lab Demo Configure Guest Access with Guest Self Registration 2

In our last session, we just finished up Portal Behavior and Flow Settings configuration and did a quick summary of the new guest flow based on that new configuration. And now we’ll do some customization. And here we’ll combine a couple of new pieces that we haven’t seen yet, so we can add footer elements and as we can see, that will get added to our preview page. You should see this at the very bottom. All access is flawed. And further we’ll make a small modification on our support page that we’re also including and modify that phone number. And again with that being a principal element of the footer that we can see that that shows up on the support page as well.

The other things that we can provide are for the notification messages that are provided and that in addition to the fields that are already created there and drawn from values that are added by the self registration process that we can include some other field names as well, such as location and have a handy variable creator to allow us to insert that field name. And again we get the nice preview for these as the process continues. And now we’ve completed the process of creating our portal for self registration. And then we’ll close this which will take us back to our guest portals page. There it is. Authorization setup is still required.

Let’s go ahead and create the authorization profiles to support self registration and in this case we will take advantage of the duplicate process. So very similar in terms of the redirect that’s ultimately happening or happened with Hotspot. We will want to duplicate that for self registration, we’ll be access accept. The only other value that we want to modify is actually what will be going into redirection. In this case, it’s a separate process from Hotspot. This will be centralized, web auth will utilize the same redirect string, but now redirect to our new demo self region portal that we specified for that. And again ise automatically builds out the appropriate redirect string to send towards the endpoint to drive towards that process and we’ll save that authorization profile. Got my confirmation there and now we’ll add the policy to support this.

We’re again doing our testing and evaluation with wireless. So we’ll modify the wireless policy, set our authentication policy. In this case we will be doing a kind of a looping process that initially we will be attempted to be mad authenticated it and this again will cause a map failure upon initial access and we’ll get a user not found and continue to authorization. And then for our authorization policy, we’ll take again advantage of IC capabilities and duplicate our previous Hotspot rule, modify the WLAN ID to correspond with our guest SSID instead of the Hotspot SSID, and then provided the new authorization profile that we just got done creating. And further we’ll disable the original Hotspot rule so that we don’t run into any possible conflicts and then save this policy.

So, in review, we completed the process of configuring our portal, particularly around customization, and then we’ve added Authorization Profiles and Authorization policy in place to support Redirection. When our Guest user arrives, they’ll see the open Guest SSID, connect to that and again try to reach the Internet and get Redirected to our Self registration portal. As they complete that their Mac address will be added to our Guest Endpoints internal Identity Store. And so now we won’t have a map failure and won’t provide a Redirect on the subsequent access. And we’ll provide with our Authorization policy that ultimately that they will gain Guest access as a result of having a Mac that’s been added to Guest Endpoints. Further, the process of self registration will add their username and password to our Guest users within Isa as well.

11. Lab Demo Configure Guest Access with Guest Self Registration 3

In the last session we finished up by making modifications to our authorization policy. At this point, we can see our new demo self reads portal is being used with one rule in the authorization policy. We’re going to be doing our testing from the iPad in the lab. Let’s open that guy up, see, still connected to Yahoo here. Let’s make sure and validate the wireless connection. Okay, it’s still connected to Hotspot from the previous lab, so let’s forget this connection and we’ll temporarily disable WiFi here to clean up the information from the Isa side. If we go into context Visibility Endpoints, and we can see our iPad still listed within there, and if we view details on our iPad, we can see that it’s currently a member of Guest Endpoints, which means that we wouldn’t be ultimately getting to our redirect rule for self registration because it’s effectively already a member of Guest endpoints, which is what we’re providing guest access on.

So let’s delete this endpoint out of the database and then we’ll go back to our iPad and reconnect to WiFi. In this case, if you recall, our authorization rule was specifically looking to match WLAN ID Three, which is our guest SSID and we see a connection there. Let’s open up to a different internet destination and you can see we immediately get redirected to the IC One portal given an opportunity to provide credentials here. And this might be again used for a self registered user has already obtained credentials. Or we could use this for our employees where those users have valid credentials as well, get the opportunity to read through the AUP and accept it. But until we get valid credentials, none of that will make any difference. So let’s register for guest access, fill out necessary fields, and if you recall within the portal we could hide that username field and not create that sort of confusion.

And you can see we have the opportunity to select from the two locations we provided in the portal and then now we can register. And upon successful registration, again we can provide or modify the option around presenting this page. In this case, we ask for it to be presented. This gives the user the opportunity to see what their password is right there. We’ll take advantage of the print button here to open up that credentials box in a separate tab and notice that we have the opportunity to be able to print or email or text there as well. And notice our footer that we created within the portal is maintained throughout.

And here we’ll provide the opportunity to log in and I think I’ve got that correct. We’ll accept the AUP and sign on and we get successful confirmation and the opportunity to register devices. This would give us an opportunity to take into account other concepts there within Ise, like registering a printer, for example, noble skip device registration. And now we can continue and indicate that we should have access to the Internet or whatever resources were provided and then try and reach our original destination. Okay, and then going back and looking now in the Ise live logs, we can see our iPad is traversed through a couple of different states.

Previously, we had it set up via the Hotspot access. Now we see the initial attempt. We had Hotspot and then an attempt was made to access and we provided the self registration portal. And once self registration was completed, I incorrectly entered the password a couple of times. And then we see Jay Watson finally getting authenticated and being provided the Guest Access Authorization profile once again, and it being able to be added to being able to reach the Internet. And once again, here we can look within context, visibility endpoints, and we see now that our iPad now is being logged in with a username and not just a Mac address. If we click on details here, get a couple of other pieces of information, once again, we’re registered statically to Guest endpoints up until the point where that information gets purged from the database and then some of the other attributes that are collected as part of this operation.

We can see that which policies were matched to get this endpoint up to the state that it’s at. It’s been effectively profiled as an iPad based on interaction with the guest portal. We can see the login information, we could see that the AUP has been accepted and lots of details, all by virtue of interacting with our IC self registration portal. Okay, in a quick summary, that was a walkthrough of self registration guest access.

We set up a new guest type business daily, which creates a new User Identity group within Ise. We configured and customized the self registration portal, adding just a little bit of processing around the flow when to accept an Au, and then a little bit of modification to the text that’s being provided, including a new centralized footer. Ah. We created a new authorization profile specific to the new self registration portal and then provided that of course, with our to our authorization policy disabling the Hotspot rule. And then everything checked out. Okay, from perspective, the iPad.

12. Enable Self-Registration with Sponsor Approval 1

In this session we’ll be enabling Ise guest Selfregistration with Sponsor approval. This provides the same benefits as Selfregistration, but introduces the ability to have a sponsor approved the selfregistration. The sponsor can view the details and determine whether or not that access should be approved. We’ll spend more time with the Sponsor portal and sponsored groups in a future session. Starting out here, let’s go to our iPad in the lab and while we’re getting things configured, let’s make sure that we’ve got WiFi disabled temporarily and we’ll be using 19 guests for the subsequent access so we’ll remain connected to that. We won’t forget that we’ll just disable WiFi for the moment and then back on Ise. We’ll use a slightly different tactic for clearing out the endpoint.

If we go to administration identity management groups, we can see that we have endpoint identity groups established here and Guest Endpoints. So from our previous access with simple self registration in the previous lab, the Mac address for the iPad got added to this Guest Endpoints Identity Group and this is ultimately what is allowing the access to pass and provide guest Access authorization by virtue of a match in the internal Identity Store. This is the value that’s actually being matched. We’ll remove it here, that will clear it out from the ability to be used for authentication, but at the same time does not remove it from context visibility.

So two choices there context visibility. If you delete it from context visibility, that will remove it from this authentication identity store as well. Okay, then let’s use the work centers menu to get back into our portals and components under Guest Access. And this we’re going to take advantage of our already created demo selfread Portal and duplicate it because it has almost all the same elements that we’ll be using for self registration with Sponsor approval. So we’ve got the copy created here, let’s click and edit that and we’ll make sure to give it an appropriate title.

And as mentioned, all the settings will remain intact with respect to what we already created for self registration, including the login page. We’re still going to allow guests to create their own accounts and under the registration form, scroll down here and check the box for requiring the guest to be approved. And then we’ll send email approval request to sponsor email addresses listed below. In this case, this will be our admin and then we’ll check this box and this would be a convenience for the self registering guest user that they’ll receive a notification via email that their account has been approved and that will provide them their authentication credentials. One other modification for self registration success, this just kind of improves the flow from the perspective of the endpoint where they can transition a little easier from once they’ve received information that their account generation has been sent for approval. And this allows them to move back to that login page a little bit easier okay, so our new portal has been created. No other customization or anything like that is needed for our test.

And then we’ll close this and we can see our new self regal required portal is still requiring Authorization. We’ll take advantage of the quick link to move to Authorization profiles. And here we’ll again take advantage of the fact that we can duplicate existing entries. And in this case, all things will remain the same ultimately, except for our destination web portal. And we can see the Authorization results here below that we’ll submit. And now we’ll go into policy sets and modify our wireless Authorization rules. Again, authentication policy will remain attacked. We’re doing the same behavior where MAB authentication failure is expected. User not found will cause a continue to Authorization rules. In this case, we’ll modify our Authorization policy to redirect to our new self regal.

We’ll take advantage again of the existing rule that’s in place. We’ll do a duplicate above and again we’re matching the same SSID guest SSID as we were for self registration. We’ll just simply disable the previous rule. So no need for a match there. So that would be WLAN ID three. And we’ll clear out this existing Authorization profile and specify our new one requiring approval. No other changes required other than we want to disable this previous Authorization rule. Okay, in a quick summary, we have created a temporarily disabled WiFi on our iPad until we’re ready to test. We created a new portal requiring approval for self registration and also added notification emails to be sent out. And then we created new Authorization profiles and Authorization policy rules by duplicating the existing ones, specifying our new values for the self registration with approval requirements.

13. Enable Self-Registration with Sponsor Approval 2

So review the authorization policy here. Again, the expectation is now the new self registering Guest will connect to the network, which will cause a map failure and will continue if user not found. Again, we’ve accomplished that by removing that Mac address from the Guest Endpoints database. So we’ll compel a map failure to occur, and then as we continue down, we’ll be accessing with our endpoint via the Guest SSID, which is WLAN ID three on the WLAN controller. And as a virtue of accessing, that will direct towards self registration with approval, authorization profile and the portal that’s within there. After they complete the self registration process and get approved, that will then provide them Guest access to the network. Their Mac address will now be within the Guest Endpoints Identity store. Okay, let’s proceed to our tablet.

As you recall, we last disabled WiFi on there, but for this kind of test, particularly to a common SSID, it’s always a good idea to make sure that that connection is removed from the perspective of the NAD, where the NAD will retain the idea that that endpoint is still connected based on cached wireless access techniques. And as a result, the authorization is still applied to this particular Mac address. So let’s clear this out. Another tactic would be to take advantage of context visibility, endpoints on Ise and a change of authorization can be issued there. I think if we refresh on the screen, we should see no clients found. Okay, let’s go back to our iPad and we’ll reconnect to WiFi. And as we did not forget the Guest network, that should get us reconnected to that quickly.

And now that we’re connected as a Guest, we should be able to attempt reaching in an Internet destination again, as with self registration, we’ll want to do identical steps where we’ll want to register for new access. Notice we have the same self registration form being supplied there, and then we’ll register for access. And we might need to change this for this example, occasionally running into conflicts with a nonstandard suffix domain suffix, so we’ve just modified it temporarily. So now in this case, identical to self registration, except notice that we’ve got just a summary of information, but no credentials being provided in the messaging along here. We can also indicate to the self registering Guest user that their account is awaiting approval. And of course, kind of a natural transition here as we supplied within the portal to take us back to the Credential screen at this point. Now, as an admin, we should have received a new email and we see the request for Guest approval, and that within the email format and it’s a convenience for a sponsor.

They can quickly approve the request here. As an administrator and a tester, we need to obtain that password. So as opposed to approving it here, we just witnessed the fact that we can do that. Let’s actually manage that guest accounts from ise. And we’ll go into work centers, guest access and manage accounts. And by opening this button, this will take us into the default Sponsor Portal. And we’ll work with the Sponsor Portal and Sponsor groups in an upcoming session. And at this stage, we can see that there is a pending account request in place for an S Homes. And if we open that up, we can quickly see the details. It has already supplied the password. But we do need to approve the request and supply, as per the portal instructions, the email address that we want to notify as a sponsor. And so now no more pending accounts. Now we have two accounts to manage, original J Watson account and now our new as Homes account.

And again opening this up specifically so we can view the password. And again, these are privileges that we can modify within the Sponsor Group whether or not we want them to be able to view this. So now let’s try our credentials, accept the AUP once again and sign on. And we’ll skip device registration and be made aware that we should now be able to continue. And let’s try accessing an Internet destination. And that appears to be successful. So going back to Ise, let’s look within the live logs to review the flow and we can see our original temps from Jay Watson. And then after we cleared our iPad Mac address from the Endpoint Identity Store, I’m going to pause this display that we see our endpoint Mac address arrive on the network and being delivered and matching the self registration with approval authorization rule and the matching authorization profile.

Then S homes attempts a login again. And as a result of successful authentication, we provide and Ise sends a COA back for the NAD to authenticate and reauthorize that endpoint. And then as Homes completes and after complete successful authentication, is now provided guest access. And then we have summary information at the top. Okay, in a quick summary, we saw a little bit about how Sponsor Notification works through email, which we’ll work with a little bit more upcoming. And then we’ve all dated the perspective and the access of self registration with Sponsor approval from the iPad.

14. Create Guest Accounts as a Sponsor 1

We’ll begin by creating the guest portal that new guests will arrive at and creating the related authorization, profile and policy so that new guests will get redirected there. We’ll begin by accessing the iPad and temporarily disconnecting it from the WiFi network and we’ll go back to Ise and Context Visibility endpoints. We’ll identify the endpoint representing the iPad and take advantage of some administrative capabilities of Ise where we selected the endpoint and we select Change Authorization and we’ll do a COA session terminate and this will clear the session from the wireless land controller which we’ll verify. And then while we have it selected, we’ll do a delete or trash of the selected endpoint.

We’ll confirm that we want to delete it and that action will remove it from the Endpoint Identity Store within internal to Ise so it will fail map authentication on subsequent access, go back to our WLAN controller and we’ll click on Clients and sure enough we see that all endpoints have been removed. Okay, now we’ll take advantage of work centers, guest access portals and components. And here we’ll be creating a new portal. This will be a sponsored Guest portal type.

Give our new portal a name and modify some of the particular settings here. In this case, we’ll want to represent it with the same identity certificate that has been used on the other portals. It’ll be using the same guest portal sequence and will leave the type intact for when employees are accessing this portal. Modify the login page settings. In this case we’ll want to include an AUP and we’ll want that to be on page. And we do want to require acceptance and we’ll require scrolling. To further on this case, this would be advisable where we’ll give the opportunity for guests to be able to change their password after the initial login. The rest of the settings should be good, we’ll glance at them quickly.

AUP settings will leave to the default, guest change password will be left to the default device registration and BYOD will also be left to the defaults. Again. This will add the Endpoint Mac address into the guest endpoints Identity Store on Ise. Compliance and post login banner will also leave intact. And about the only other change that we’ll want to make is not to include a post login banner. And this will get a little creative in showing some of the things that can be done after authentication occurs. We’ll launch a web connection towards the Ise product page on Cisco’s website, go back up to the top and save our work and do a little bit of customization. And here we’ll do a quick replacement of the logos and clear the banner text.

We should see the refresh on this down below here. There we go. And we’ll save our customized demo sponsored portal. Let’s give a quick little edit to the name here and save one more time. Okay, we’ve successfully crafted a new demo sponsored portal we can see in the list here that it’s still requiring authorization setup. So we’ll take advantage of the link to go to authorization profiles and we can see our existing already created authorization profiles providing redirection. We’ll take advantage of self registration portal and duplicate that and we’ll call this the sponsored portal Authorization and we’ll go down to common tasks. We’re still taking advantage of CWA and the redirect ACL on the WLAN controller and modifying the redirection towards our new demo sponsored portal.

And again down below as we go to submit, we can see the new redirect URL having been crafted and get the confirmation on the save and go into policy sets to modify our wireless authorization policy. And again as a reminder, the anticipation is that an initial access map failure will occur and we’ll do a continue to authorization processing and we’ll take advantage of the existing self registration rule that’s active and do a duplicate.

Above we’re still matching the same W land ID of three which is the guest SSID and we’ll replace the self registration with approval with our new sponsored portal authorization profile and we’ll disable the self registration rule that had been active and we’ll save. Okay, we’ve just completed the quick provisioning of a new sponsored portal for our guest users. Again, this will not allow them to create their own login account, they need to interact with the sponsor. And we’ve created new author authorization profile and policy to redirect users to this new guest portal upon access to the guest network.

15. Create Guest Accounts as a Sponsor 2

We’ll start with our work centers, menu, guest access and portals and components. We’ll select Sponsored Groups and we can see that there are three Sponsored Groups already created with a brief description about what they’re capable of managing. We’ll select the All Accounts Sponsored Group and duplicate it. And now we see a copy of the All Accounts Group and we’ll edit that. We’ll rename the group to have more meaning within our lab and a brief description of what that Sponsored Group can do and the members that are currently allowed to be members of this Sponsor Group. We can add additional members and we can see the list of our demo local domain groups. And we’ll select employees that we also want to be able to have be members of this new Sponsor Group. We can provide some further filtering in terms of what the Sponsor Group can manage. These are all the guest types. We can add locations that the Sponsor Group can manage.

We can check the box for automatically emailing guests and Sponsors can notify guests as they’re creating guest accounts. We’ll disallow the ability to generate multiple accounts assigned to specific guests, but we will do a random generation, and in this case we’ll support that random generation by creating a prefix. In this case, as random accounts are created, they’ll all have this prefix and we’ll leave a little bit of a trail for auditing purposes and future needs. And then we can allow that Sponsor to create allow them to modify that prefix or not. We’ll deselect that and we can limit the number of batch accounts that they can create. We can further tune what guest accounts they can manage. In this case we’ll leave it as all Guest Accounts.

But notice we can tune this in other fashions. We’ll require the Sponsor to require a reason for suspending an account and we’ll leave the rest of the values to the defaults for the Sponsored Group and get a confirmation save. We’ll go over here to Sponsored Portals and we see that there’s already an existing default Sponsored Portal in place. We’ll select that and duplicate it, select it and edit it. We’ll provide a more meaningful name and we’ll modify some of the settings. You’ll notice a couple of things that are unique to the Sponsor Portal. One is that it runs on a different port typically than the Guest portals, which makes sense. Some of this will allow some isolation for access. We can modify the identity cert that we want to apply here and we’ll get a warning as we save this portal about the fact that we’re modifying the ID cert tied to that port. We also have a different Identity store sequence for authentication purposes. Let’s take a quick look at that.

You can see our Guest Portal sequence is including internal users and guest users, where the Sponsor Portal sequence does not include guest users, only internal users and Active directory join points. The other values that will leave the same. One other exception to this particular portal is that we can tie it to an A record within our DNS and allow Sponsors to be able to reach it without having to provide a Redirection policy for them to reach this portal.

We could also isolate Sponsors to particular SSIDs. Those would have to be added within the settings page if we wanted to limit which SSIDs can be utilized to access this portal. We could do that there we’ll save our work. You can see it’s a very simple flow. And we’ll also demonstrate single click approval through email later on. And we get the notification about all portals on the same 8445 port will now be utilizing a different ID certificate. So get the confirmation.

We’ll do a little customization and we should see all these updates applied in our demonstration applet down here. And we’ll save our work. And as we get confirmation of the save, we’ve just now created a new Sponsor Group which includes our demo employees, users from our demo domain and define what privileges they are allowed to operate within the Sponsor Portal. And we’ve just now created a new Sponsor Portal for those Sponsors to utilize. And we’ve set things up in such a way that Redirection is not required to reach the Sponsor Portal. They can type in, enter in an FQDN Direct to directly reach it.

16. Create Guest Accounts as a Sponsor 3

Let’s open up our iPad and we see that it’s not connected to WiFi. If you recall that we removed it from context visibility endpoints, which also removed it from Guest endpoints. And so to compel a map failure upon access, we see that it did connect to Guest. Let’s open up to an internet destination and we should get a redirection to occur. Now, one thing that will distinguish this portal from the other portals that we’ve been interacting with is notice that we do not have the opportunity to self register or to create our own account. So let’s go back over to the Admin PC and on the Firefox browser we’ll open a new tab and try and reach our new Sponsor Portal. And recall that we’ve tied this to where the domain Employees Group should be able to access this.

And we could see that we’ve got the opportunity to create accounts. And when we create random accounts, they are automatically set with a prefix that we specified for this Sponsor Portal and Sponsor Group. This Sponsor Group can also manage all other guest accounts that have been created, including through self registration. Let’s go ahead and create a couple of random accounts to use with our new Sponsored Portal. We’ll create two accounts, we’ll automatically have the prefix applied, it will automatically create dynamic random usernames. From that we’ll create a duration of two days and we’ll do it from my local time and date to tomorrow’s time and date from roughly midnight to midnight. And we’ll do that based on Denver time zone.

And we’ll create the account. You’ll notice that we asked for two accounts, so we have two new usernames created, both with that common prefix and dynamic random user passwords also created. So now let’s try logging in with our iPad, agree to the AUP and sign on and that appears to work. Okay, now let’s investigate on IAC and the live logs to validate the flow. And we can see here, as specified the initial access to the Guest. WiFi attempted a map authentication and as a result the map failure redirected us to the Sponsored Portal. Then we attempted a login with one of the new randomly created guest accounts and as a result of that, a change of authorization was issued and finally new authorization was provided along full guest access.

And also of course having profiled that endpoint as an Apple iPad. Okay, in a quick review, we have done multiple things for Sponsored Guest access. We created and customized a sponsored guest portal. We created for our guests to be redirected to. We created appropriate authorization, profile and policy to cause that redirection. Then additionally, we created a new Sponsor Group and a new related Sponsored Portal to allow sponsors to create user accounts and manage them. And then we attempted the access via that Sponsored Portal with a newly created Guest account from the iPad and got success for the most part. From there.

17. Guest Account Management via Sponsor Portal

Let’s go ahead and open that sponsor portal. If you recall, we created one specific for our demo domain and have tied that to authentication for domain employee users. We’ll sign on with our employee account and we can currently see, as with available to the Sponsor Group, that all guest accounts can be managed, including self registered and by other sponsored groups. We could see our two self registered guest users already created and our two randomly created guest accounts. Only one of them is active by virtue of actually having been accessed and logged into, the other one is still in a created status.

Let’s take this second account and suspend it. And as per configuration of the portal, we were compelled to provide a reason for suspending an account. And now we can see that second account in a state of suspended and as we select that account, our options are now limited to delete, reinstate or refresh. Let’s go ahead and reinstate that account while we have it selected. Let’s reset the password and we can provide notification for that if we wish. In this case we’ll just say okay, and the password on that account has been reset on this first account, let’s select it and edit it and this may be helpful. We can provide additional details for future management of this guest account.

Just now we have some more visible details as to who this guest account has actually been assigned to. We see those details represented in summary. And as we go back to manage accounts, we can see now the first and last name listed for that first randomly created account, some of our other capabilities. Let’s select our previously self registered account J Watson and edit it and notice per the template of the guest type business daily and to some extent the restrictions provided by our Sponsor group were provided the ability to extend the account only up to a maximum of five days and let’s go ahead and do that. Currently see it ending on 1231.

We should see that modified, see that now going up to January 4. And then finally, the last thing to demonstrate is the ability to delete an account. So let’s select that randomly generated second account and delete it. No reason required for that, just confirmation of deleting the account and it has been removed from the list. In quick summary, this is management of guest accounts from the Sponsor portal. Again, privileges and capabilities are indicated and dictated to some extent by the guest type and also limitations of the Sponsor Group group that a sponsor is doing, their management of those users within, and different capabilities and restrictions can apply.

18. Lab Demo Create Guest Reports

As you can see here, we’re currently on the Home tab for Ise and in the top part of the menu section we see an area for authenticated guests. If we click on the number one here that will take us to a quick visual report on currently authenticated guests. We can see we’re filtering around authenticated guests automatically by by clicking on that portion of the Home page and we see our one authenticated Mac which is our iPad within the lab environment and the currently logged in guest username is one of our randomly created guest accounts. If we click on the Mac address it will take us to a wealth of information particularly around the Attributes tab and we get several pages of information regarding how this endpoint and guest endpoint arrived with access and how it conveyed its information towards gaining that access.

We’ve seen IIC make a determination about the type of device via the Portal interaction could see the network access device that governed the access, the Portal that provided the interaction, the sponsor that created this guest account, this randomly created guest account Cissoids that were used for access the username. Ultimately it’s a user type of guest user and the operating system again all determined by interaction with the Portal and the processing on Ise. Additional details in a different summary are specific to authentication for this particular guest user and endpoint. Going back to the Home tab we’ll select Guests and again a different arrangement of widgets or dash lets.

On this dashboard we’ll select the Guest status and here this will list out guest status as well as type failure reasons and location information. And if we click on the Mac address here that would take us to that same information screen that we just saw with the attributes and authentication information. Another variation is by going into context visibility and endpoints. And of course this is similar to the Home screen and basic approach. One benefit as we’re viewing details such as the Mac address is that it doesn’t open a new tab, it retains the current tab that we’re on without opening a new one and we can again view those details. Okay, for actual reports that can be ran, we’ll go to the operations tab and reports select reports on the left.

And some of the reports that we can run that are relatable, we’ll run this audit report and some of the things that can be evaluated are administrator logins showing the login attempts and when those attempts occurred. Can also view the operations audit, which will let us see configuration changes that have occurred by particular administrators. And then further down here we can see guest reports and among some of the guest reports that are valuable or could be helpful are AUP acceptance status. We can see our randomly created guest user has accepted the Use policy and the Master of guest report showing basic interactions.

The login attempts the suspension of accounts, change of authorizations that have occurred for guest activities overall and some of those would be related to sponsor logins and audits where we can see a sponsor that is logged in and manipulated. Guest accounts provided updates, suspensions, bulk ads for user account creation. Okay, in a quick summary, that’s an example of some of the reports that can be ran on ise lots of helpful information within the home and context visibility screens, often providing quick answers towards the problem that you’re trying to resolve. And then a very nice set of reports providing a nice audit trail for activities, operational administration, and then of course, endpoints and guests, among many other reports that are available.