Hello again. In this part, we will discuss student devices. Some of student devices are managed by Google MDM, and we want to give these devices some privilege more than Internet only. Let's discuss the scenario more. This is mainly for student users. They can use personal devices like their mobile phones maybe or laptops, and they can use devices provided by the school, and these devices are mainly Chromebook. School provided Chromebook are managed by Google MDM and the rules are simple. If the student uses school-provided Chromebook, in this case, the student will get student role. This means he can access or they can access some resources internal in the school. If they provide their own devices which are not managed by MDM or not managed by Google MDM mainly, in this case, they will get Internet access only. They will not be able to access any internal resources. Let's start or let's try to analyze this more. The first question, should we use EAP-PEAP or EAP-TLS? This has nothing to do with the scenario actually, you can use any of these. In my lab I have EAP-PEAP and I will use it in this course. You may have EAP-TLS and the requirements or the changes are minimal. The configuration is very similar between EAP-PEAP and EAP-TLS. It is not the same. But when it comes to MDM Integration, it is the same method. MDM Integration is mainly with endpoint database, which means everything will be an endpoint database. Whatever method you have right now you need to integrate it or you need to add to the logic endpoint information. Somehow you need to add some rules or in your enforcement policy, you need to add few lines that will evaluate attributes and endpoint database, and based on the value of these attributes, the user will get certain enforcement policy. We will see how to do it with EAP-PEAP and you can customize it for EAP-TLS or any other method you have in your environment based on what you see in this course. Now the other question, how to know if a device is managed by MDM. The method we will use is called external context server in a ClearPass, which means ClearPass will integrate with Google MDM as an endpoint context server. It will sync with that server and we'll get information and store it in endpoint database. We will see this in more details. Now what attribute to use? We will use an attribute called source. If information are received by Google, then it is a student device. If information are received from Google or if the endpoint has attributes for Google Admin Console, then this device is managed by Google and the user will get student role. If the device is not managed by Google MDM, because we don't see an endpoint, any attributes from google for that MAC address, then this device is personal and the user will get Internet only. These are the rules, they are very simple and we are ready for the next step, which is discussing the scenario in more details. Now, let's discuss the workflow and the steps needed for connectivity. We have two devices in my lab; we have a Chromebook, which is managed by Google MDM. This Chromebook is provided by the school, and this is the MAC address. We can identify it easily by the MAC address in our access tracker. The other device is personal, it is a mobile phone and the same user a student is connecting to both of them. Both will connect to secure SSID. They will use EAP-PEAP to authenticate against on-prem AD. ClearPass needs to verify the MAC address against the endpoint management or against Google MDM. Actually it is not directly with Google MDM, ClearPass will sync database from time to time with Google MDM and will store the information internally in ClearPass and endpoint database. It is not actually this way, it is not with every MAC address. ClearPass will do the sync with database between endpoint database and Google MDM. Whenever any user connect ClearPass will verify the endpoint for that MAC address. It will see if there's any attribute in that endpoint MAC address coming from Google. If any, it will assume that this device is managed by Google MDM, and will give it different role. So EAP-PEAP authentication will be against on-prem AD, the same way as before. But when it comes to authorization, we are adding another source. We are adding endpoint database, which is synced already with Google MDM. Although we are authorizing against endpoint database, we actually depend on the information that was synced with Google MDM. The rules are simple. If the device is managed by Google MDM, then it will get student role. Otherwise the device will get Internet role only in instant AP. Now let's discuss configuration steps. First of all, we need to enable OAuth2.0 and we need to enable API in Google. This is done from another, both are in Google, it has Google Cloud Platform or GCP. We will create a project in this platform and we will enable API. We will see the configuration in details in our lab and the configuration steps are provided in our documentation. Actually, I will depend on these two links. This link here discuss the feature when it was added in 6.5.0. In this description, you can see a lot of details about this feature and the steps needed to enable this feature. This is an old document, maybe it was 6.5.0. I will combine the information here with the information in this link here. This link is 6.9 and it has more updated steps. Let's go back to our slide and see the other steps. After we configure this API and we enable OAuth2.0, we need to go to ClearPass and configure external context server. We need to configure Google MDM as external context server in ClearPass. This way, ClearPass will sync with Google MDM and all information received from Google MDM will be saved in endpoint database in ClearPass. We may customize some attributes or timers. We can customize the polling interval and start time. If you have a large database, you may want to have these numbers customized or two on the bit to match your requirements. I will show you from where to customize this information or these timers, and in my lab I will use the default timers. Then we need to configure SSID service. We will modify the enforcement policy and maybe RoleMapping to match exactly our requirements and to send the enforcement before I need it in each case. In this video, we discussed the student's scenario. We discussed the requirement and configuration steps. In the next video, we'll configure these requirements and configure these steps in our lab. Thank you for joining, and see you in the next video.
