Cisco CCNP Security 300-715 SISE – Cisco ISE BYOD

1. Introducing the Cisco ISE BYOD Process

Organizations that have accepted a Bringyourown device or BYOD policy have observed improved user experiences and productivity, as well as simplified operations and reduced risk. However, many organizations are still reluctant to implement BYOD out of security concerns. The problem is that BYOD introduces previously unmanaged devices into the network, and their access to internal resources must be controlled. This is where a Cisco Identity Services engine, or Ice can be used to create different policy levels. Not all guests to the network should be treated the same. For example, full time employees should have more access to resources within the organization than temporary workers, and the temp should have more access than ordinary guest users.

A BYOD policy is important because today’s employees are more sophisticated than ever before and are already using their own personal devices to access the network. 40% are using their smartphones, 36% are using their personal laptops, and 26% are using tablets. This means that corporate and personal data are commingled on devices which create security as well as privacy concerns. Organizations can get ahead of these issues by implementing an easy to use policy based BYOD approach using Cisco Ice. This includes a single source of policy for wired, wireless and VPN connectivity. In addition, a fine grain control can define policies based on who is the user, what kind of device is being used, and other numerous factors.

Lastly, self registration portals can be used to reduce the workload of an already burdened It staff. This includes employees blacklisting their own devices if they are lost or stolen. BYOD can be implemented using a single or dual SSID design with a single SSID solution. Provisioning of new devices and network access are combined using a secure SSID which does not allow for guest access. The dual SSID design separates provisioning and network access by providing a secure SSID for employees and an open SSID for guests and provisioning of new devices. This method allows secure access for both employees and guests. Let’s take a closer look at the single SSID design. Using a personal device, an employee connects to the corporate secure SSID and enters a username and password. Cisco Ice authenticates the employee against a local or active directory database.

Then, Cisco Ice provides an accept authorization policy that redirects the user to the employee device registration portal. After the employee registers and provisions the personal device, Cisco Ice sends a change of authorization or CLA to the network access device or NAD, and the device reassociates with the secure SSID to access the network. Now let’s examine the dual SSID design. In this scenario, an additional BYOD open SSID is used for both guests and employee device provisioning. When new devices are connected to the BYOD open SSID, they are redirected to a Web authentication or Web Auth portal. Here, guest or employee credentials can be entered.

A guest user is typically required to sign an acceptable use policy or AUP and is immediately granted limited access to the network usually to the internet only the employee, however however is redirected to the employee BYOD provisioning portal to register the personal device which includes certificate provisioning and downloading the supplicant configuration onto the client. The employee can now connect to the corporate secure SSID with the new device to access the network.

2. Describing BYOD Flow

When an organization implements a Bring Your Own device or BYOD policy using Cisco Identity Services engine, new devices connected to the network are redirected to a BYOD portal. For onboarding, the portal requires an associated authorization profile. The purpose of the profile is to redirect the user to the BYOD portal. When the new device is connected, the authorization profile is required for native Supplicant provisioning or NSP. With NSP, Cisco Ice will have different client provisioning policies based on the operating system of the personal device being on boarded.

Each policy will contain a native Supplicant profile which dictates which authentication protocol to use, to which wireless SSID to connect, and more. The client provisioning policies also reference which provisioning wizard to use. This is because the Supplicant for provisioning an iPad is different from the Supplicant from an Android, and so on. Lastly, Cisco Ice evaluates the authorization policy rules and grants the user access to the network resources based on the authorization profile specified in a policy rule. Cisco Ice can retrieve user or machine attributes and groups from Active Directory for use in an authorization policy rule.

These attributes can then be used in Cisco Ice policies and determine the authorization level for a user or machine. Let’s take a closer look at some key rules in a Cisco Ice policy set. If an employee authenticates using a previously provisioned device, the Supplicant on the device connects to an EAP TLS SSID and the provisioned employee is given elevated access as defined in the profile named employee. If an employee authenticates using a new personal device, the WLC NSP profile redirects the employee to the BYOD portal to run through the NSP process. If users authenticate using guest credentials, they are assigned limited permissions via the profile named guest.

Users who connect to an Opens Sid are redirected to the Web authentication or weboff process using the Open role. If they provide guest credentials, they are assigned limited permissions via the guest profile. If they provide employee credentials, the Wlcnsp profile redirects them to the BYOD portal. Lastly, if none of the rules are matched, the default rule denies access. Let’s review the relationship between the BYOD authentication components. First a certificate authentication profile name CN username is created by Navigating from the BYOD Work Center to external sources.

Certificate authentication profile the profile is configured to specify that the certificate common name will be used as the login name as well as to identify the user. Next, an identity source sequence name one x x 509 username is created by Navigating from the BYOD Work Center to Identity’s identity source sequences.

It references the CN username certificate authentication profile and specifies that the Credential verification order will be active directory, then internal user database, and lastly, guest database. Finally, the authentication rule x 509 Augh is created by Navigating from the BYOD Work Center to Policy Sets policy rule which is added to a policy set, checks for valid criteria, and upon a match uses the identity source sequence name one xx 509 username.

3. Describing BYOD Flow 2

Let’s take a closer look at the BYOD flow when using an Openssid, which can be used by both guests who typically need Internet access via an organization’s network or employees using endpoints that have yet to be provisioned. In either case, the first step is to use the wireless utility on the personal device and connect to the Openssid. The user is then directed connected to the Web authentication or Web Auth portal where guest or employee credentials can be entered. A separate Acceptable use policy or AUP page can be used to acknowledge acceptable behavior outlined by the organization. When guest credentials are used to authenticate, a user can be checked against numerous login options, including the maximum number of devices allowed.

A post access banner can also be displayed to inform them of their access status and any other additional actions that may be required. Because the enable self provisioning flow option is not enabled for guests, they just continue to use the Openssid to access the Internet and any other allowed resources. When employee credentials are used to authenticate, the user is redirected to the employee client provisioning process. First, the BYOD welcome page displays whether device configuration is required or the previous certificate needs renewal. Next, the BYOD certificate registration process is performed.

Afterwards, the BYOD installation page provides the steps for installing the supplicant on the desktop, iOS or Android device. When complete, the BYOD success page displays the access status in any other additional actions that may be required with native supplicant. Provisioning for Employees A supplicant can be automatically provisioned with the certificate installation when the employee is connected to the BYOD portal. Cisco Ice provides a certificate authority or CA certificate and prompts the user to register the device.

Cisco Ice then adds the device to the registered device’s identity group and proceeds with the device enrollment process. You can create native supplicant profiles which determine the proper native supplicant provisioning wizard to use based on the operating system. This is where connectivity settings are configured for the employees.

Finally, a certificate template can be configured which contains the properties that are common to all certificates issued by the Cisco Casco. Ice comes with a default certificate templates for the Cisco CA and you can create additional certificate templates if needed. The default templates include EAP authentication, certificate template for EAP authentication, the PX grid certificate template for the PX grid controller while generating the certificate from the certificate provisioning portal, and the CA service certificate template for other network services that will use Cisco Ice as the certificate authority.

4. Describing BYOD Flow 3

Now let’s review Creating a client Provisioning policy for employees. These policies define the profiles that are provisioned on endpoints, which include identity, group, operating system, and other conditions. These policies also determine which users receive which version of resources from Cisco Ice upon login. This can include agents, agent compliant modules, and agent customization packages or profiles. After an employee endpoint is provisioned, it will reconnect to the network using the specified SSID and the security parameters assigned to it. During the provisioning process, the assigned authorization rules are listed in top down order in which they are processed.

Notice how the provision employee is listed before the employee rule. This is important to ensure that the proper permissions are assigned. Let’s examine a provisioning configuration example in the relationship between the BYOD provisioning components. First, the EAP authentication certificate template named BYOD EAP Off 365 is created by Navigating from the BYOD Work Center to portals and components, certificates and certificate templates.

The certificate templates define how the user certificate shall be created. In this example, the common name is the user’s login name and the subject alternative name is the Endpoints Mac address. Next, a native Supplicant profile or NSP named iOS WPA two Tlsbyod is created by Navigating from the BYOD Work Center to Client Provisioning and resources. The NSP defines how the endpoints native Supplicant is configured. In this example, the profile defines how an Apple iOS based device should connect to a particular SSID using specific protocols.

Notice how the Byodeap Off 365 is chosen as the certificate template. Finally, a provisioning policy rule named iOS WPA Two BYOD is created by Navigating from the BYOD work center to client provisioning and client provisioning policy. In this example, the rule states that if the device is Apple iOS based and the user is a member of the domain user group, then the NSP policy iOS WPA Two Tlsbyod will be used to provision the endpoint.

5. BYOD My Devices Portal Provisioning

In this session we’ll be configuring certificate provisioning using the internal CA or certificate authority capabilities of Ise. And then we’ll configure a client provisioning policy to deploy the components and ultimately a new ID cert to our BYOD endpoints. Okay, we’re still in BYOD portals and components configuration area. Let’s select certificates here on the left and certificate templates. We’ll kind of expand this list here to get a better look at the titles. And you can see there’s three certificate templates that Cisco adds in there. By default we’re looking at the one that will do Et authentication. Ultimately we’ll apply this to our endpoints that will complete this template as a certificate signing request. Let’s duplicate the existing default there, give it a somewhat meaningful title in terms of what this CSR certificate signing request will be utilized for.

And one of the nice things about the certificate template is that the end users interacting with the BYOD process will never really lay eyes on this component. There’s one piece that the endpoint will be needing to fill out on its behalf and we can’t modify that as an administrator. So the username being used for the login process into the portal itself will be filled out there. And then everything else we can utilize in a nice consistent fashion for all the fields needed within a typical certificate signing request. And notice that as part of the certificate template, it automatically adds the Mac address of the endpoint in as a subject alternative name into the ultimate to the both the certificate request and in the ultimate ID certificate will have the Mac address and the end point planted firmly in that ID start, providing some very tight integration there.

We’ll modify the validation period notice we can go to quite a large range there, but we’ll match it to what our template is and of course this will be utilized for client side authentication and we’ll submit and save that. Okay, so now we’ve got our new certificate template in place, we can move on to client provisioning and then client provisioning, we’re going to add a new provisioning policy and we’ll have it be the top on the list within client provisioning. This is a hierarchical list that is being analyzed in terms of processing. And we could tie this in terms of a policy match to an endpoint identity group or an internal user group, perhaps something that profiler was able to profile. We could specify something in there along those lines. And in this case we want to match it to the tablet in our lab environment. So Apple iOS all we can further define the group of users that we would like to have tied to this provisioning. Policy works just a little bit like authorization rules and we want domain users here and then we’ll move into results. And here we’re being asked to select a wizard profile. So this is interacting with the native iOS operating system from Apple to integrate this new WLAN or WiFi profile on that side, we’re going to create a new profile matching for Apple iOS all. And then this is where we’ll create a new wireless or WiFi profile to add to the device. And note this SSID value is case sensitive. It’s probably worth taking a quick little glance over to our W land controller to verify that’s actually the correct SSID value. Yeah, 19 WPA two E.

Notice we can put in some other proxy auto config type values in there. It’s automatically selected for WPA two enterprise which is also known as 802 and X. We’re going to compel use of TLS which will require that identity certificate is utilized on the client side and it’s already selected our new certificate template that we created there. And optionally, we could also select that this WiFi profile will work even if the SSID is hidden which is not interlapsed. So we’ll leave that unchecked. Can we consider new wireless WiFi profile added in the certificate template that will be deployed that has all the values pre filled out, including adding the Mac addresses, a subject alternative name we’re specifying the security that we’d like to use and component the use of and this wireless profile will be there upon completion with a prepared client side ID certificate for Rbwd endpoint to use.

We’ll save this get nice response, click done here to confirm we’re done editing that rule and then save our client provisioning policy. Just waiting for confirmation while that’s completing. Just in summary, we went through two pieces of configuration provisioning here. We created a certificate template can be definitely thought of as a certificate signing request template that will be used for our BYOD endpoints to obtain an ID cert. They’ll basically be filling that out effectively automatically on the endpoint side and completing the one wild card value necessary which would be the username which will go in as our common name for the endpoint ID certificate itself. And then we have just now completed the process of creating and adding a client provisioning policy rule. Client provisioning overall is an aspect that can be used on ise to deliver client components to endpoints and we’ve done that by applying a certificate template that we would like to have completed and ultimately the specification for a new wire list profile that will be added to that endpoint.

6. BYOD Provisioning Configuration

In this session. As part of the Isebyod solution, we’ll be creating a myDevices portal so that employees can manage their devices after they’ve been registered. And we’ll also take a look at the BYOD portal itself that will be used for device registration. We’ll start off with our work centers menu and look at BYOD and the overview. And as we have been going through the other work center overview portals, in most cases we’ve got all the preparation steps already completed. In this case we’ll be going directly into Define and building web portals.

You can see your My Devices portal listed on the left. We’ll be creating a new portal, give it a bit of a name and a description and then we’ll work through portal settings. We can see the standard stuff with respect to the port being utilized 8443 which is in common within most of our portals. And we’ll reselect this. So it’ll be using our identity circuit certificate that we have obtained for Ise. You’ll notice that we also have an opportunity to this is one of the other portals where we can enter an FQDN so that users can reach this portal directly without having to be redirected to it. But we could also redirect to it as well if we thought that would be something we needed to do. We’ll see that as devices get registered, they’ll end up in the endpoint identity Group register devices. We could create a separate group for that based on per portal or any of another variety of conditions.

We see that we’re tying authentication to the portal itself to a separate identity source sequence called My Devices Portal sequence. Let’s go ahead and take a look at that. And I think we’ll want to make a modification to the order of processing within this identity source sequence. So here’s My Devices portal and we can see that in order of processing it’s going to try looking for users that are logging into the My Devices portal. It’s going to look in internal users first and then Active Directory all ad join points. Let’s move this guy to the top of the list and we’ll save that.

Most of our employees, of course are Active Directory users also. So this will make for a somewhat more efficient processing in terms of getting authentication completed. And we can close this tab now that sequence is saved. Continuing on, we’ll take a look at the log on login page settings and we’ll want to include an AUP on page and require acceptance and then the AUP page itself will accept the defaults. There include an AUP page? We’ll also make sure that there’s a post login banner included, won’t allow users to change their passwords from the portal. That would be more of an internal user effect. And we will provide a support page which will include all the fields available and the portal itself will actually make customization to that for the rest of the portal. Configuration, save our work so far and then we’ll move into customization and we’ll modify the logos that we’re using and selected new logos for the mobile desktop type portals and then the banner image itself and we can clean. Up the image just a little bit by removing the title and we can see the net effects updated here and we’ll save this portal once again. Okay, we’ve got successful response that our portal was updated and now let’s go ahead and try out our portal access by utilizing the Portal Test URL.

We should open a new tab and we get redirected to our customized portal. And here we’ll want to log in as one of our Active Directory users and agree to the AUP and sign on, get our post access banner being provided and then do a continue. And if we had devices to manage, we could see those listed here, but fundamentally we can see that we’ve got good access to our customized portal and that authentication via Active Directory is working properly. So now when we get devices registered, we’ll be able to manage those devices from within our My Devices portal. Going back to our Portals configuration, we’ll close out our new My Devices portal and we can see BYOD portals here on the left and we won’t make any modifications to this, but we will be using it. We’ll build an authorization profile and authorization policy rule to redirect to this BYOD portal and you can see it’s got a fairly simple flow. Welcome to BYOD registration installation and then success.

The portal settings themselves are effectively identical to what we’ve seen with the other portals with the exception of not being able to provide a Nfqdn to reach this, we’ll redirect to it BYOD settings or including an Au. Again we’ll leave the defaults and of course we can provide a sort of support information if needed, but we’ll again accept the defaults in this case and then we’ll just close this portal. Okay, in review, we’ve created a new customized My Devices portal for our demo employees. We optimized the authentication into that portal by increasing the processing order for Active Directory evaluation. And then we reviewed and tested that customized portal using the Portal Test URL from within the Portal creation page. And then we took a quick tour of the BYOD Portal which we’ll utilize for provisioning and registration of our BYOD endpoints for our employees.

7. Configuring BYOD Policy Part 1

In this session we’ll be adding components and a new authentication policy rule to support the Ise BYOD solution. Okay, we’re still within our BYOD configuration area. Let’s go in and take a look at policy elements and results. And in particular we want to focus on allowed protocols under the category of default fault network access, which is generally what we’ve been applying for and particularly our policy set Access. But this will also apply towards authentication rules for authentication. With our new BYOD solution, we’ll be authenticating with a client side ID certificate and we’ll be wanting to make sure that EPTLS variations are allowed, including ETLS itself and Peep. Using ETLS as an inner method, you can see for both ETLS variations we have the option to select allowing authentication of expired certificates and they explain within the notes there we can match against conditions, the Cert Renewal Required condition in particular, and you can also create conditions which will anticipate the expiration of a certificate.

In either case, we can create authorization policy rules to redirect them back into BYOD provisioning and get that certificate renewed. Okay, no need to make any changes here, just wanted to make sure that ETLS was allowed as part of access. Okay, now we’ll go to external identity sources and we’ll be creating a certificate authentication profile. And in this case, what we’re trying to do is match the contents of the certificate. Ultimately the signature of the certificate will be validated against the copy of the root CA certificate that ise has a copy of.

The only other thing that we’re trying to guarantee is which value within that ID Cert is going to be applied as the username. So in this case, the subject common name which is dynamically set within the certificate template to be fulfilled by the endpoint as a dollar username dollar and that will match against user ID. And then we will not in this case be matching that certificate against an identity store where we might be able to do that. That would add overhead. In this case we just need to validate the signer of that ID Cert. Okay, next we’ll be wanting to create a new Identity store sequence to specify using that certificate authentication profile.

We’ll go into Identities and select Identity Source sequences and we’ll add a new one and we’ll select the certificate authentication profile that we just created and we’ll select all Active directory join points to be at the top of the list. We’ll select Internal Users as a possible option and we’ll select Guest Users as a final option and effectively it will be our hierarchy. And then we’ll modify this option down here below to treat as if the user is not found and proceed to the next identity source in the sequence. Okay, now we can go and modify our authentication policy and we can access policy sets directly here from the BYOD menu we see our wireless policy set and we’ll expand out authentication policy.

In this case we’ll be adding a new rule immediately above our existing wireless 821 x rule and add a new condition where we’ll be looking for the components of a certificate and I’m looking for issuer Common name and as listed in the ID certs that we’ll be receiving the sign or common name will be root in lowercase uppercase. If we meet that condition then we will supply access to the new identity source sequence that we created to support BYOD and we’ll investigate the options. The default should be fine to reject if authentication fails, reject if user not found and if process fail is to drop and we’ll save this authentication rule.

Okay, in a quick review, we reviewed allowed protocols for default network access to confirm that ETLS variations are allowed. We configured a new certificate authentication profile that specifically matches the common name within the ID cert as a username for the Identity Store. Then we configured an identity source sequence to use that certificate authentication profile and then we just completed adding a new authentication policy rule that looks for endpoint ID certs that have been signed by our root CA within the lab and then we’ll authenticate them against the Identity Store sequence that we specified and created for the.

8. Configuring BYOD Policy Part 2

In this session, we’ll be creating the Authorization Profiles and Authorization Policy rules to support our BYOD solution. Okay, we’ve just completed creating new authentication policy, so let’s begin with the Authorization components. We’ll select policy elements, results, and Authorization profiles. We’ll add a new Authorization profile to support redirection to our BYOD portal. So we’ll go down to common tasks and select web redirection. And in this case, we’re driving them towards native Supplicate provisioning. And we’ve got a redirect ACL specific to that purpose built on the WLAN controller. And we’ll be redirecting to the default BYOD portal. Down below, we can see the Radius authorization will be sent back to the WLAN controller, including the redirect ACL and the redirect URL itself. We’ll add additional Authorization profile to provide user privileges once they’ve gained access to a BYOD registered device.

And in this case, we’ll be specifying permissions via the access list that’s pre built on the WLAN controller, allowing them network access once they’ve properly matched the conditions for Bwaud. Okay, so now we’ve got our Authorization profiles. Let’s build out our new rules going to policy sets. We’re modifying Authorization within our wireless policy set. And then we’ll add some new rules pretty close to the top here, immediately below the blacklist rule that’s currently in place. In here, we’ll select a couple of conditions.

We’ll take advantage of a dictionary filter to look for network access. In here, we’re looking for the Network access authentication method of Ms chat V Two. This is what the iPad will be using as it authenticates to the demo local identity store. And then we’ll add an additional condition where we’re looking for the endpoint to not be a domain member computer as an endpoint accessing BYOD. It won’t be a domain computer which has already got the means to obtain an ID certificate. So this is specifically targeting non domain computer devices, and under those circumstances, we’ll provide them our new WLC NFP Authorization profile. Then we’ll add another rule below this. And here we’ll look for the criteria that we should be able to match once they have obtained an ID certificate. Here we’re looking for network access again, in this case, specifically looking at an authentication method of ETLS, which means that they’re using a client side ID certificate to authenticate with. Then we’ll add an additional condition. This is part of the unclassified category, and we’re looking for endpoints that have been added to the BYOD registration endpoint identity group. And then additionally, we’ll take advantage of this pre built library condition. If I highlight it for information, we can see that what it’s looking for is within the subject, the certificate subject alternative name field that there’s a value in there that’s equivalent to the Radius calling station ID or the Mac address of the endpoint. So we’ll drag and drop and add this as our third condition.

So it can be quite precise, including looking for values within the ID certificate. Now, that that’s been built with a consistent certificate signing request so we can look at those field values in there and with a little typo in my authorization profile. We’ve applied the user access authorization profile for that match and we’ll save our new policy set. Okay, a little bit of a review. We configured new authorization profiles to redirect endpoints to our BYOD native supplement provisioning and then to provide access after device registration.

And then we created new policy rules to match specific computers. The first one to look for nondomain computers that are authenticating with Ms. Chat v two and then send them to the BYOD redirection profile and then subsequently should be able to match an ETLS authentication indicating a valid client side ID certificate. And then further looking for validation values such as the Mac address being added to the subject alternative name field of the certificate itself. And we’ve got authorization policy in place. We should be ready to test in our next section.

9. Employee iPad BYOD Registration Part 1

In this session we’ll be doing the first part of employee iPad BYOD registration. We’ll use the iPad to log into the WPA two e network as an employee, which will redirect us to the BYOD provisioning process which we’ll step through. Once that’s completed, we will verify that we can connect with the iPad’s newly installed ID certificate. Okay, let’s go to the iPad, add and get it prepared and we’ll modify WiFi access and forget the 19 guest network and then temporarily disable WiFi and then we’ll go back to IAC and into context visibility endpoints. We’ll trash the Mac of the iPad endpoint. Then as a final check, we’ll look on the WLAN controller and remove that endpoint from the guest network completely and then go back and get our live log set up so we can review the connections inbound from the iPad and we’ll reconnect WiFi.

And now we’ll be connecting to the 19 WPA Two e SSID where we’ll get prompted for credentials and join that network and we’ll get immediately prompted for a trust warning from the ID certificate owned by Ise itself. This is part of the Radius server communication initiated back by that server and we need to trust that and that should get us authenticated. In this case we’ll have authenticated with Peep and then using Ms Chat V Two to authenticate to the demo local identity source. Now let’s try and reach an Internet destination and we should get redirected to the IAC BYOD portal. This is the default portal and so the messages are pretty generic but obviously this can be highly customized and does give us an indication that we’re about to step through a process which we’ll start.

The first step is to have us describe the device and the device name will show up in the ultimate description for the ID certificate and we get to see a representation of the Mac address for the endpoint. And we’ll continue on to step three where it instructs us we’ll be doing an installation, launching the Apple profile and certificate installers. The first piece that I will install will be a profile for the root CA itself and we’ll go ahead and launch that install process and lets us know that we’ll be adding it to the list of trusted certificates on our iPad. So it will be used for signature verification as we receive an ID cert with the root CA signature on there. We’ll use this for verification and we’ll continue that install and we’ve completed that. And now the next step it will continue on and install the WiFi profile which will include completion of the certificate template. We see it generating a key pair to complete that certificate template as a CSR and then completing the enrollment. And now our profile is completely installed at this point.

So now we’ve completed the certificate template as a certificate signing request back towards our certificate authority and ultimately received a completed ID certificate and a new WiFi profile to connect to. We’ll see done here. At this point we get the success page from the default BYOD portal and lets us know we should be able to connect to the secure network. Let’s go ahead and try and reach an internet destination while we’ve got the Safari browser open and it does appear that we are connected to the network. Go ahead and verify that via settings and scrolling up here. We can see that we are now for sure connected to the WPA Two e network and currently we’re on the general settings screen and it has already opened our profiles. As part of that installation we could see our root CA profile that has been installed and our new BYOD profile also. And looking at some of the details within there we can see the components that have been created.

So copies of the signing certificates used for certificate validation on received ID certificates, a copy of the root CA certificate, the new ID certificate for our iPad and a new WiFi profile that has got the pre built settings for EPLs and connecting to the 19 WPA two Essid. Let’s look at some of the details for our new ID Cert. We can see that the common name got fulfilled. Recall that within the Cert template that was a dollar username dollar wild card and so that got completed and then all the remaining fields were completed as specified, including down here at the bottom where we see the subject alternative name field and it lists as an email address, but this is the Mac address. Of course, the iPad has been listed as a Mac in the subject alternative name.

Okay. In summary, we’ve successfully completed the BYOD device registration process. We initially connected to our WPA Two e network and authenticated with Peep and Ms Chat V Two which redirected us to the BYOD portal and we stepped through that process. And then ultimately we see the completed effects on the iPad where we have a new ID certificate installed, all the appropriate trusted signing certificates in a new WiFi profile to connect to a secure network.

10. Employee iPad BYOD Registration Part 2

In this session we’ll be looking at Ise and reviewing the results of successfully completing BYOD registration with the iPad. Let’s start off by looking at live logs on Ise and we’ll pause this output to stop the refresh. And we can see our iPad having moved through the different phases where it began by being connected to the guest SSID and we disabled and included that access. And then on subsequent access, we logged in successfully as an employee and matched the 821 X authentication policy. And then that matched towards the authorization policy rule that redirected us towards BYOD provisioning and provided the authorization profile supplying the redirection. Then after device registration was completed, the iPad connected and matched the X 509 authentication policy rule which was looking for the certificate issuer. Then that matched towards by user access and provided the user access authorization profile.

Let’s look at some of the details within this session that got completed. Yeah, we can see in the overview that through the provisioning process we were identified as an iPad. The authentication authorization that was provided, we can see now we are a member of the Registered Devices Identity Group. We can see that we also used ETLS to authenticate with some of the details.

Over on the right, we can see the TLS negotiation occurring, looking up and validating certificates. And then down here towards the bottom, we can see as it was matching through authorization rules, where we queried the subject alternative name field within the certificate and also the radius calling station ID. Okay, from another perspective, let’s see what BYOD collected. If we go to Wild work Centers, BYOD and Identities, we’ll see our iPad endpoint listed.

They’re much like we would see within context visibility endpoints, except with BYOD. This is our only registered device currently. If we edit some of the details on there, that will provide a wealth of information. Again the Identity Group assignment and then in particular other attributes. Many, if not all of these could be considered viable for condition matching within, say, an authorization rule. For values that are collected, you can see how the description was provided from the BYOD process and added to the CenterPoint information. And as we get down towards the bottom here, we can see the contents of the ID certificate that’s tied to the CenterPoint.

Now the subject common name, as well as all the fields that were completed as part of the certificate template that was used as part of the BYOD process for the iPad. And let’s take a look at the certificate that was issued. If we go to Administration certificates and we’ll discard the small edit effect that we did there on the endpoint and under certificates, we’ll select Certificate Authority and Issued Certificates and we can see some revoke certificates from some previous attempts I made. And we’ll select this one on the bottom and view details.

And this is again a copy of the issued certificate that is residing on the iPad itself. And again we can see who it was issued to, who is issued by, when the expiration is. And if we scroll down just a little bit more, we can see listed within the subject alternative names is the Mac address of the iPad itself. Okay, in summary, we verified the results of BYOD provisioning and viewed many of the details that are collected regarding the authentication the iPad using its client side ID, Cert and TLS as an authentication mechanism. We viewed the many details collected about the endpoint itself and also the ID certificate that was issued to the iPad.