All Cisco CCNP Security certification exam dumps, study guide, training courses are prepared by industry experts. Cisco CCNP Security certification practice test questions and answers, exam dumps, study guide and training courses help candidates to study and pass hassle-free!

Web Auth and Guest Services

6. Lab Demo Configure Guest Access with Hotspot Portal 2

Okay, we're on our Portal configuration page. We just configured portal behaviour settings. Now we're moving to portal page customization. As a quick review, we can see how the portal itself will be represented in this preview on the lower left. And as we modify settings within customization, we'll see them updated on this live view of the portal, effectively a mobile representation of the guest portal itself. And we can later on do a desktop preview of that portal and see what it looks like from that perspective as well. In preparation, we'll download some new logos that we can add and customise our portal with.

Notice some of the effects. As we want to modify logos, we have multiple choices. We can click X to remove a particular image, and we should see the portal update to go towards a blank banner. And we can also reset back to defaults, and we see that update applied here. In this case, we'll update our logos for mobile, use that same logo for the desktop representation, and update the banner. And again, we're seeing all these updates occur in a dynamic manner. In this case, to clear up the look and feel of that banner, we'll remove the banner title, which makes it look a little bit nicer.

Notice that as you're manipulating the particular logos in this case, we are modifying the page representing the actual Acceptable Use Policy, or AUP. We could modify the title of that page, and we'll modify it here. We also have an opportunity, while we're looking at that particular drawer, to modify settings within the portal behaviour and flow settings right from this customization page. In this case, we've got a specific text that will be applied within the Acceptable Use Policy, the main AUP text. And here we can actually modify the text.

We'll take advantage of a Microsoft application to do a little search and replace. Here they search for Cisco Systems, and we'll replace that with our lab organization. And notice how this allows us to make a very distinct representation of what we should have in our AUP with respect to our own individual organization. And we can also do some additional customization within this so that we can bold this and modify colors, et cetera. I should mention at this point that Cisco also provides a Portal Builder page. If you search the portal builder on Cisco's own website, you'll find some very creative portal templates to get started with. In addition to the verbiage, of course, the look and feel and interaction with the portal are also greatly enhanced by using the Portal Builder.

In addition, now that we've modified our AUP, we should see those represented on the example page. Now, for authentication success, we can provide some additional verbiage depending on the desires of our own organization, something along these lines, and again do some things to enhance the view. We can also modify colours and type. Faces can also be modified, and we can also link to an external URL to supply the text for any of the message boxes that we're looking at here. And then, for support information, this store becomes available as a result of having turned it on within Portal behavior. And we've got text that we can supply along with the fields that will also be representative.

We'll see how those fields are populated, and then we can provide a theoretically reachable phone number. In addition, we can customise error messages that are delivered, modify them, and provide somewhat more helpful text in the event of particular errors. And we can clear up some things for our example lab-based system. And then we can save this portal button at the top.

And again, as we click on the individual pages, we can see the representation of that in a preview with the effective mobile-based web pages. And we can likewise now do a desktop preview and see how it looks within a desktop browser screen as we look at our portals. here Overall, you can see that we have a new Mo hotspot portal created and that authorization setup is required. So we've effectively got all the pieces in place for the portal itself. Now we just need to create authorization profiles and add an authorization rule or two to support this new portal.

7. Lab Demo Configure Guest Access with Hotspot Portal 3

In our previous session, we completed the configuration of our new demo hotspot portal. The demo hotspot portal requires acceptance of an AUP and the entry of a correct hotspot code. And then we've customised that portal with different logos and modified the messages around the AUP and the support pages that will be offered up as needed.

We can see that the hotspot portal is still requiring authorization setup, and we'll take advantage of the link below to create new authorization profiles. OK, this first authorization profile will provide access to two new guest users as they arrive in our environment. They'll access the guest SSID, and upon access, it will identify them as an unknown Mac and cause a map failure. And upon map failure, we'll continue to authorise processing and send that endpoint a redirect string.

Upon access to the Internet, as soon as they see they're connected, they'll try and access the Internet, but instead they'll arrive at our new demo hotspot portal to do that. We choose web redirection as the authorization method for this authorization profile, and we redirect them to hotspot processing.

And we'll supply a redirect ACL that is locally created on the network access device itself, the WLN controller in this case, and that creates the circumstances where we want the NAD to send a redirect stringback towards the end point. When the endpoint connects to TCP port 80 or 443, But the redirect ACL would also allow us to create exceptions where we don't want to send that redirect string back to the endpoint. The numeric WLNID two corresponds to our hotspot guest SSID, according to Quincy for WLN information.

And then within the security and access lists where we specified a redirect ACL to be utilized, this is the access list that will be utilised for that. And then likewise, the guest has an ACL for access after the user provides the correct hotspot code. This is the traffic permission that they'll receive. And we've entered these access list names correctly within the authorization profiles that are using them. And then the real value will be our new demo hotspot portal.

And then down below we can see the radius authorization that he is going to be sending back towards the WLAN controller, which includes specifying the direct ACL for that NAD to use and a very precise session-based redirect string to drive that endpoint into our new demo hotspot portal. Then our next authorization profile will be after they've provided the correct hotspot code. Now we'll give them some sort of privileges for accessing our network, presumably for internet access, but there may be some other guest networks that we want to create reachability for, and we'll provide them that authorization here.

And in this case, where we're operating with the WLAN controller, we can't specify a DAC for that, but we can specify and tell the WLAN controller to use a specific policy-based ACL for this task. And again, this is locally created on the WLAN controller and needs to be specified accurately. Okay, now we'll go from here and build our new authorization rules at Hotspot Access. And again, we're operating in the wireless environment, and under the Wireless Policy set, we already have an authentication policy in place to deal with our guest users, particularly the Wireless Map Authentication rule where we're sending authentication towards internal endpoints.

In addition, we've changed authentication processing so that if an error not found is reported by internal endpoints, we'll proceed to Authorization Rule processing. And then for authorization policy, we'll add a couple of new rules above ContractorAccess to aid with our testing. And our first authorization rule will be for that Hotspot Access, where, when users match this particular rule, we'll send them to a redirect URL. In this case, we'll match to the specific guest SSID that's utilised for guest access on our wireless environment, click on the airspace icon, and filter things out so that we can filter around the specific WLN ID created on the WLAN controller for this purpose. And we'll review that WLN controller setting here in just a moment. Then there's the authorization rule for users who've set up a hotspot and entered the correct hotspot code.

And as a result of providing the correct hotspot code, we'll find them within a new local identity store group listed as guest endpoints. We could create a separate identity group for this purpose. We can do that for the portal if needed. In this case, we'll use the one created by Cisco for this purpose and then for authorizations. And then we'll save this policy. Okay, we just finished setting up new authorization rules for our demo Hotspot Access. If we go back to our portal view, we can see that our demo hotspot now has a green checkbox that indicates that we're using this portal access as a result of one rule within an authorization policy. Okay, this session we've completed all the necessary setup for our new demo hotspot portal, including the basic guest settings that we've reviewed. We've also set up the portal itself. Then we implemented an authorization policy to correspond specifically with endpoint points accessing guest or guest SSID.

8. Lab Demo Configure Guest Access with Hotspot Portal 4

In our previous sessions, we did all the configuration necessary to support our new demo hotspot portal. The portal itself has flow behaviour where we're compelling acceptance of an AUP and requiring hotspot code customization for the text and the AUP messages and support messages themselves. We've added a little bit of branding and colouring to our portal, and we've added that portal into an authorization rule, and we can see that reflected here.

And we've provided authorization profiles for initial access as well as subsequent granted access for hotspot access. Let's try testing things out with our wireless endpoint, which is our Apple iPad in the lab review settings, to see what we're connecting to for wireless. Currently WiFi is disabled, so we will enable that, and we can see it immediately connects to our WPA2 SSID, which is for 821X. We'll want to forget about this network so it doesn't try to connect to it again and gets out of the way of our hotspot access in the future. And for our test, we'll select the hotspot SSID, which you can see is an open SSID, and we'll get access right away to the hotspot.

Now at this point, a typical guest user would see that they're connected and try to access the internet, so we'll do likewise. I've requested Yahoo, and instead we get redirected. So, after being briefly redirected to IC One demo local and being asked to provide acceptable use policy information, notice that we've added new tax information to that AUP page. And then, after being asked to enter an access code in order to view the messages that we added to our error messages and modified within error messages, we see that we have modified text that I typed incorrectly there but his new text there. For what we provide for an error message in the event of an incorrect hotspot code, see the front desk for assistance. Then the user might likely contact support, and this will open up a new tab and allow filling in the checkboxes that we filled out on the flow behaviour side and then the field names on the customization side, including the modification of the phone number.

And we can see that by virtue of interacting with the portal, he has gained a little bit of information about this endpoint, the browser, and the operating system that are in operation, and now we'll provide the correct hot spot code and we'll get a connection success message. Again, this can be crafted in a number of ways. This includes our customization for the coupon code. We might also want to include information about the fact that they're successfully connected but they can now reach their original destination as IC doesn't automatically redirect back to the originally requested web page, but we should be able to reach that now, and sure enough, we're able to [email protected], which is investigating things back on the Ise side. Let's review the events as they occurred within the live blog.

We can see as we initially access the iPad and turn on WiFi that it connected to the WPA2 SSID, which triggered 821-x authentication. And then I disabled that, forgot that connection, and reconnected to the Hotspot SSID, which required MAB authentication and provided the Hotspot access authorization policy and profile. That authorization profile, of course, includes the redirect URL. So the end user sees that they're connected now and tries to access, ultimately providing the correct hotspot code, and now we provide them guest access privileges. As a result of that, you can see if we scroll over to the right that the endpoint has also been added to the Guest Endpoints Identity Group. As part of this process, we can verify their existence, their identity management groups, expand endpoint identity groups, and select guest endpoints. And we can see the Mac address for our iPad has been added and has been profiled as an Apple iPad.

You might recall that we do not have profiler activation within our ISV deployment at this point. Nevertheless, we get profiler effects merely by interacting with a portal page, and we've made some determinations about the aspects of this. Endpoint can further view some of those details, and we can see that we've been determined to be an Apple iPad and that we've been reassigned to End Point Identity Group Guest Endpoints. And it will remain in Guest Endpoints up until account expiration has occurred, which should be in about 24 hours, and then whatever the timers have been set around the purge policy, this Mac address will remain in the Guest Endpoints Identity Group until account expiration and purge have occurred.

9. Lab Demo Configure Guest Access with Guest Self Registration 1

The idea behind guest self-registration provides two basic things. One is for the guests to be able to set things up for themselves in order to provide something as simple as Internet access, and the other is for the organisation providing that access. They gain something of an audit trail by virtue of that self-registration process; the user's name, first name, last name, email address, and phone number, for example, are common components of the self-registration form. We'll begin by utilising our work centers, menu, guest access, portals, and components.

Before we create the portal itself, we will be creating a new guest type. Guest types provide a basic template function for the self-registration process. You can assign particular guest types to particular portals, which would provide limits for the length and time as a template that that guest type would be utilised for. We can add the custom fields that were created in a previous session. Custom fields are created within the settings area for GuestAccess, and if we need to, we can make this field mandatory or required within the portal itself.

We'll leave the defaults here in terms of duration when it actually starts, and I'll leave them unchecked for the sake of the lab. Although it is easy enough to provide limits around dates, days of the week, and times of the day, And these settings are also factored in by virtue of the guest locations that were also configured within the settings. Under Guest Access, we'll limit maximum simultaneous logins to two Mac addresses that self-registered guest users will be utilizing; these will be automatically added to Guest endpoints, and we will limit that to a maximum of five devices that they can utilise as a guest. We won't allow them to bypass the guest portal, and we will provide a little bit of an account expiration notification.

As an example, we'll make this 5 hours and we'll send that to them in an email, and we could factor that in the customization that was provided within an already credited portal. This would include logos and colors, and we can modify the message that gets sent out via email. Likewise for SMS, a variety of SMS providers are already added by default by Cisco, and others can be added, and notice that for both aspects that we have the opportunity to send a test email or send a test SMS via the facilities provided, we'll leave it at the global default, and then further sponsor groups that we have not yet talked about within IC would be allowed to manage the guest users that are being registered as part of this guest type, and we could provide further filtering and control there. We get our confirmation, then we'll go into GuestPortals and we'll be creating a new Guest Portal.

In this case, our Guest Portal template type itself is registered, and you'll notice as the page populates here that we have a somewhat more complex guest flow as compared to what was provided for the hotspot type. In this case, we have the loop around self-registration until self-registration success is achieved, at which point they can login and proceed with the rest of the portal configuration that we're doing. So we're introducing this loop fundamentally as part of this type of portal, and all portals have some very similar components with respect to portal settings.

So we have the TCP port value that the portal will reside on. The PSN for these portals will be running from the interface, and the only restriction on the TCP port value is the ID certificate that is used. So as long as all the portals can live with that same ID certificate, then 8443 will be no problem. A little note about the authentication method: we're gathering credentials via the portal instead of a network access device. It's important to kind of take a look and see how this process is done, where he is acting as its own authenticator. In effect, we'll be using the default-guest portal sequence that's provided, which simply provides a list of identity sources.

So this is an identity source sequence. We can factor in different available authentication identities and add to this list, and then this is hierarchical, right? So he will look at internal users first and then proceed forward, and this is also set to a continued state with respect to the identity sources that are listed in case a user is not found. Let's try the next ID source in the list and continue on. As a general template function, the login options will be initially inherited from the contractor, and then we'll modify them through the behaviour settings further on here in terms of where guests will actually be derived from not requiring an access code, but we do want to manipulate AUP capabilities of notice. We can manipulate the maximum number of failed login attempts between logins.

The AUP will be provided on a page and will require acceptance as well as scrolling to the bottom. Part of that is to facilitate seeing the link to start the self-registration process. Then on the registration form, here's where we can define the actual guest type that will be built out, and that's who will be our new business daily user.

We can see how the account validity is derived from that, and up to a maximum of five days, we're just going to do a one-day account. We can see all the fields that we want to include or require, and based on the time zone references, that may be a problem. We'll include just a couple of locations; let's add San Jose back in there. Additionally, we can turn on or off the SMS provider, including the other fields. We can allow or disallow guest registration from certain email domains, and we can provide a self-registration success page as well, which will actually provide them their credentials. And within that success of self-registration will be all the information that will be included in that email.

And we can further give that guest user the option to print, email, or SMS that same information to themselves on a full-page representation. We'll include an AUP page, and we'll use a different AUP page for employees. Again, by scrolling, we can modify guest password settings, which will lead to default device registration and BYOD. Yes, we're automatically registering guest devices, and we'll see how Mac addresses end up in guest endpoints. As a result of this process, BYOD is "bringing your own device," and we can drive employees through this process to begin registering their device via BYOD. In this case, we'll leave that off.

We can also perform a guest compliance check, which involves adding a client provisioning page to the guest flow and providing them with the necessary pieces, or we can perform a health evaluation. We also have similar options on the other portals with respect to post-login view and change and the authentication success page, which we're all providing; in this case, an option that we'll want to include is the support information page and all the fields that we want to have represented there. We'll go ahead and save this portal, and we'll do customization in our upcoming session. We can see a quick representation of the new flow in place as a result of turning on support information in particular, and now we have the first part of our portal created, and we'll do customization coming up.

CCNP Security certification practice test questions and answers, training course, study guide are uploaded in ETE files format by real users. Study and pass Cisco CCNP Security certification exam dumps & practice test questions and answers are the best available resource to help students pass at the first attempt.