Compliance with ISE and MDM

Good morning, everyone. Thank you for joining us today. We will continue our ICE integrations, expected site series today.00:09And, we will be discussing integration of ICE with the mobile device management or MDM today. Let's move to next slide please. Thank you.00:18As always, we would like the session to be really interactive, so you have the options to ask your questions. A Q and A panel was moved from Webex to Slido, so if you follow the steps highlighted on this screen here.00:39You will find a slider button on the bottom right corner, and once you open it, there will be a Q and A tab available for you. Please ask the questions. We have the panelists ready to answer those questions. Use the opportunity.00:53And let me introduce a team for today. Our presenters will be Farid and Jeffrey and we will have Mohammed, Tarek, Surrendra, and Henry helping with the questions and answering them. And when it comes to agenda, Farid will start with the overview.01:11Review of MDM or UEM, what's the difference and we will explain us what it is. We will as well discuss the differences between MDM version two APIs and version three APIs why we need both of them and when to use those. We will as well discuss some optimization tips, examples of.01:31Policies and best practices. And after this section we will have a 15 min break. After the break, Jeffrey will show us demos of Intune jump and Meraki integration with ICE, and we'll as well discuss multi MDM integration.01:51So with that, let me hand over to Both. Thank you everyone, so let's start with the overview and before we get into the APIs and policies, we need to be clear on three things.02:10What is UEM? What is MDM? And what ICE actually does with the data provided by the UEM or NDM. MDM evolves into UEM. In ICE, you will still see the feature called MDM. However, in the industry.02:28The platform you actually integrate with is usually a UEM.02:48MDM or mobile device management is used to secure access and your organization data on managed endpoints. E.g., your phones, laptops, desktops, printers, IoT or similar devices.02:56UEM or unified endpoint management, it's an involved form from MDM. However, MDM did not disappear, it just became one component of the UEM. UEM have four components.03:12So we have the MDM, we already talk about it. We have the MAM or the mobile application management. We have the MCM or mobile content management, and we have the MIM or mobile identity management.03:29When I stop about an MDM server, it's just query one of the components of the uemiss or compliance and registration. So we can divide what actually UEM controls into four boxes.03:46We have the MDM, so here we know what, is controlling the device itself, so who wants it, which OS is running, whether this device is just broken or whether it's installed or is lost and how you troubleshoot.04:04With the MIM, we control the applications itself or we, which applications can be installed in the device and how they are deployed and licenses. Whether the the device or the application requires.04:24Updates and how these apps and data are removed. With the MCM, we control the content. What can be accessed, what can be blocked while sharing, whether VPN is required for corporate data.04:40Copy paste work or not and even if you're allowed to do email attachments. And with the MIM, we control the identity of who is using the device and whether the user and the device are trusted and whether can be limited by time or location.04:57So if UEM already manage apps certificates and profiles, why they need to integrate with ICE? So from UEM, you can revoke certificates, block applications, and that is endpoint controls.05:16Those same devices also attached to wire wireless and VPN networks and UEM is not your radius policy engine. ICE is when a certificate is revoked, the device is not compliant or rooted, the ping long is missing that this encryption is off.05:35UEM already knows this. However, after the integration, ICE can use that status in the authorizations and can change the device access to the network. So you can add different VLANs, different ACLs, different SGT.05:55You can redirect it to a different network or even deny access to to the network. So we think that the controls on the endpoints and why ICE is the radio side of that.06:11So now I would like to talk about ICE itself, where this MDM sits among the compliance services of ICE and and what other compliance services ICE offers. So let me start by defining.06:27That is ICE. ICE is the network access control and you can run it as a standalone deployment or a distributed deployment. You can deploy it on a virtual machine, physical appliance or in the cloud.06:47At the scaled it support up to 2 million endpoints. And on the protocol side, it is a radius and packets mainly. Endpoints connect on wire wireless or VPN. ICE authenticate those endpoints against identity stores.07:04Oh, things like Active directory, LDAP, MFA, and others. During the authentication, under authorization, I start building context. That context gives you visibility.07:24It drives segmentation and you will share this information with the partners. If a partner reports a malicious or suspicious behavior, you can contain that session. So how does MDM fit in here?07:41MDM is just one more context source. ICE ask the UEM whether the endpoint is enrolled and compliant and then uses that answer in the authorization decision. So.07:58What is compliance? Compliance means the endpoint is adhering to the rules your organization define encryption, team, managed status, OS versions and similar checks that you may have.08:14For NDM, those rules are evaluated in the UGM and ICE does not run the checks itself. It just received the results and then apply network policies from that. ICE has three compliance related services, and all of them.08:31Sits in the premier licenses. So we have a posture is where ICE evaluate the checks you configure directly in ICE, it uses the Cisco secure client to gather information from the endpoints.08:51The result of those checks is what ICE is used to grant access. MDM is a little bit different. With MDM ICE.us does not run the checks. It just query the UEM API for registration and compliance.09:08Then it use those attributes in authorization policies. We also have TCNAC, which brings in threat and vulnerability information. So access sorry so access can also consider exposure.09:26Not only a compliance flag. Osture and MDM both answer whether the device meets policy and TCNAC adds threat and vulnerability. For today we will stay just with MDM.09:41Oh, austrial and NDN both provide compliance. We are clear in that one. Which one you use? It will depend on who owns the check. Let's just see a quick comparison of both. So this is a comparative state.09:59Table between both of them.10:19Posture and NDN again both gave you compliance, both need premier licenses to work. The difference, however, is who owns the check. Posture built and evaluate them in ICE, so those checks are built and evaluate directly in the ICE.10:21You you you will use Cisco secure client with agentless stealth and temp temporal options. You can remediate directly from the ice and you can deploy apps for that remediation. It can also give you the chance to do list.10:39Very of this reassessment or even grace period. With MDM, MDM leave those checks directly to the UEM. So what it's going to do is ask where is the registration and compliance, uses the UEM agent or the profile you already push.10:59And it does not remediate from ICE. The user remediates in company portals or directly in the UEM console. And ICE only sees the new status after catch expired.11:19Holding or even new authentications. What MDM does give you is visibility and profiling attributes directly from the UEM, plus OS coverage beyond Windows, Mac OS.11:35And Linux. Typically adding things like iOS, Android and more in terms of policies both can be granular and both can grant network access based on compliance. However, the timing.11:51Is a little bit different. Posture evaluates in ICE when the endpoint connects basically on real time while MDM is whatever status ICE gets from the UEM, which might be seconds or even hours old.12:09Operationally posture means maintaining checks, agents, OS coverage, and ICE, and MDM means deploying certificates and keeping those certificates correct in the UEM. So to answer the question, if you already have UEM.12:27Just integrated and consume it with the compliance it already produced. If you don't have posture is the is the path. You can create your own checks in ICE and you can grant access based on on that result.12:46Add threat and vulnerability on top of compliance. You can combine it with posture with MDM or with both. Then the access consider exposure and not only a compliance flag.13:08However, the focus for today is MDM, but I would like to encourage you to visit the following links so you have more information on poster, TCNAC or other compliance topics that we just touched.13:25So this is eyes before we add the MDM integration. So MDM is not in the picture, we have basic services radios, tacacs, we have profiling, guests, posture, things that you're basically running your in your eyes and connected to IDM.13:49Stores.14:09And those endpoints authenticates to those ideas to basic AAA, right? So let's add UEM to the picture. So in here I just query the UEM over the MDM API. The response include attributes such as registration status.14:10Compliance status, OS, serial UDI. The exact list will depend on the vendor. The thing is those attributes become NDM dictionary attributes in ICE, and you can use them in the authorization profiles.14:31Regarding the API versions, so I stock to the UEM using APIs and there are two different flavors of APIs. We have MBDM version two.14:55We have NDM version three. For NDM version two, it looks up for the MAC address from the radius packages. So there there is a radius attributes calling calling station ID. So that's what we search in the MDM version two. For the MDM version three, we look at.15:11Up by a unique ID, so the UUID, the management ID, and it's usually taken for a certificate.15:31Either the subject alternative name or the common name. However, this MDM version three keeps Mac as a fallback mechanism in case the device do not support a certificate registration.15:41So this is how MDM version two works. The endpoint connects to the switch or WLC, the network access device sends a radius access request to ICE, and in that request you have username, authentication, protocols, and something very important.16:05Calling station ID. The calling station ID is the Mac address ICE used as the lookup key. ICE calls the UEM NDM version two and give and ask him hey give me the compliance for this Mac.16:25The UEM will respond with the attributes associated to that Mac, so typically, device compliance status, device registration status, this encryption status, manufacture the set again.16:43Totally depending on the vendor. ICE then runs authorization against those attributes and return access accept with the ACL, sgts redirect or deny. Two conditions for this to work is 1st.17:00The Mac in the radius must be the same Mac you have in the UEM inventory. If for some reason they are different, then it won't work. Second thing, the UEM must implement the Cisco MDM API.17:20So it can answer that query. If the vendor never implement version and the n version two or version three, ICE cannot get a full response or even useful response and the end version two.17:37Breaks when the calling station ID is not in the Mac. So this is what I was mentioning before. So what happened is, e.g., we have things like Wi Fi Mac randomization, phones sometimes present random Mac address.17:57And the UEM has the real one. So in that case, when the ice queries the UEM with that address and the UEM never have that Mac address store, the API returns an unknown or not enrolled.18:16For these Mac addresses and policies and will start treating your corporate laptop e.g. as a managed devices because it never finds the MAC address in the UEM.18:34And that's why we create MDM version three. So MDM version three is available in ICE 3.13 .1 and later.18:49The UEM provisions a certificate with unique ID in the subject alternative name or the common name. However, the sun subjective the subject alternative name is the preferred field for this. When the endpoint authenticates with ITLS, ICE can.19:07Parse the certificate.19:27It will read that ID and then queries the UEM with MDM version three. The UEM will send a response to ICE and ICE can provide the necessary permissions based on the information.19:28From the UEM. The attributes returned and the same type of inversion two. The only thing that changed is the lookup key. So from MAC address to subject alternative name or or.19:47So a unique ID, and you will find them in the subject alternative name on the common name. But what happened if there is NO unique ID in the certificate? What I mentioned before, I still can can query by MAC addresses. It will use the same calling station.20:04ID.20:24Even that we are using version three APIs, so the lookup is the preferred method, but the Mac is the fallback mechanism. This is the suggested format for the identifier in the subject alternative name.20:26Or the common name. So the format is the ID column UEM vendor name column, GUID column, then the identifier. So we have here an example of you can see ID, then vendor name column.20:45Go it.21:05And the ID. The last value can be the GUI, it could be the UI UDID, the Intune device ID, the jamf F management ID or whatever uniquely identifies that device in the UEM is the ID. So I.21:06This will read it from the certificate and will be using.21:26It on the version three lookup. So common question is, hey, my endpoint authenticates with different protocols. Do I use MDM version three or version two?21:30If the managed device authenticate with ITLS, use MDM version three because ICE will read the GUID from the certificate, then queries back the UEM and get the compliance. Or other methods like I don't know, username password, MS chap.21:50Or anything without the device certificate, ICE won't be able to see the identifier in the radius access request so there is NO certificate to parse or ICE will fall back to the calling station ID.22:09The Mac address, right? At this point, you are doing Mac lookup, so if you think about this time, you can implement version three because it covers both scenarios. So how it works?22:24The NAT or network access device sends a radius access request that includes the certificate. ICE does not query the UEM yet 1st, it has to validate that certificate. That happened through the certificate authentication profile in ICE.22:44ICE checks the certificate against that profile. If the certificate is not valid, authentication fails and you stop there. If you also have user identity, you can do directory lookup, so active directory.23:04All that's the one.23:24If the certificate is valid, the authentication is done, then the authorization starts. ICE already has the good from the common name or subject alternative name and it queries the UEM. It gets the compliant back and grants access based on that result.23:26So it will permit, restrict, redirect, give this SGT or whatever you have configured in your policies. So that that is for the wire and wireless flow.23:45Sorry. However, for BPM is a little bit different. On BPM, the certificate is presented to the head end and often terminates there. So ICE never received the client certificate in the same way it respon.24:06The one X and cannot read the GUID from the SAN or the CN.24:26Something has to send those identifiers to ice. In our case with Cisco secure client, that is the Accidex. The client parses attributes such as subject alternative name.24:32Common name into the session, ICE use those values to query the UEM and then get compliance back. If those attributes never reach ICE, the MDM lookup cannot use certificate ID. Again, you fall back to my address with the same limitations as before.24:48Yeah, at the end of the day, the difference is very simple. MDM version two can only look up the device back address and MDM version three can look up by the ID and the certificate, and if the ID is not there, it's missing.25:07Then we can still fall back to MAC address. Both options have a cost to run. Neither is set and forget. Some name points will never use certificates. E.g..25:27All devices, printers, username and password devices. For those ICE has NO way to read. The only identifier is the calling station ID, the MAC address that ICE will see. On version two that is a problem because if the Mac in the radius is not the same.25:42Mac in the UEM, it won't work, so things like Wi Fi randomizations is like the usual example. The phone shows one Mac, the UEM has another and the lookup fails. People then try to turn randomization up so the two macs can match.26:02On version three, devices that authenticates with IPTLS do not have that problem. ICE uses the ID from the certificate, not the Mac. Version three does not remove the work, it just moved the the work to something else. Now you have to create certificates in the right format.26:23Put the ID in the subject alternative name or the common name. You need to revocate when it's needed, renew it, push to the wire or Wi Fi profiles and then use that certificate. That is UEM and PKA work, not a radius Mac problem.26:43So version two version two is hard part is Mac address. Version three, the hard part is just the certificate life cycle. For me, use version three whenever you can push certificates and for devices that cannot accept.27:00Certificates, just use the Mac look up and design around these limitations. So this is how the partner ecosystem looks like.27:19On the left, those vendors are still on NDN version two. On the other side we have vendors like Yvanti, Meraki, Jamf, Omnisa, and Ninton, and they already are on version three.27:35Version two still here for two reasons. The 1st one, the UEM has not implemented version three yet. And 2nd one is that we still have plenty of endpoints that cannot support authentications through certificate, so it has NO good and then.27:53You just do Mac address.28:13The end goal is for every UEM to move to version three. Then you will have both options in the same API. ID lookup when there is a certificate, a MAC address lookup when there is not. And that's give you the flexibility to connect any kind of device in.28:15Your deployment.28:35Now let's talk a little bit more about optimization policy examples and recommendations around it. Let's start with the optimization. There are two settings here to check. We have the compliance catch expiration time.28:39And the polling interval. When an endpoint is stayed on wire port, it often authenticates once and does not coming back. Laptops are different. So we have laptops go to sleep, you can.28:58Can close the lead, you can go to break, restart the laptop. Each of those can trigger another radius authentication. Homes do this even more. You can see even around eight authentications a day.29:18Laptops might be, I don't know, two or three. However, the important thing here is that every reconnect is an access request and without cache, every access request is another query from the ICE to the UEM.29:35It reconnects means eight calls to the intern or the jump for those devices and that is what compliance cash expiration time is for.29:51After the 1st successful UEM lookup, ice can reuse that result. You can set the timer from 1 min up to seven days. Inside that windows, a reconnect does not hit the UEM again.30:07So Shorter timer means we assert data, but more load to the UEM. Long timers means few queries, but higher chance the status is is old. So here is what happens on reconnect.30:23If the endpoint comes back inside the compliance cache window, ICE does not query the UEM. It uses the result already stored locally and authorized from that. That is how you cut the number of calls to into without changing how the.30:43User connects. Pulling interval is 2nd setting. Here, not every managed device take compliant, don't go out of compliance while they are already on the network.31:03And your policies then give them restricted access from the user perspective or the user point of view, resources just stop to work and there is NO notification around it.31:23In those cases, you may need an authorization rule that redirects them to a page that helps them out of that state. So e.g., enable firewall, install patches.31:38Open company portal, whatever your UEM is expecting. However, in the background, ICE still has not learned the new status. Let's put a simple example. The let's assume we have 10000 endpoints authenticated.31:551 % or I don't know, 2 % are not compliant. ICE is not going to query every entry. What ICE is going to do is just bulk query the UEM for those non compliant devices, so those one or 2 % devices and we'll ask hey.32:13Uem has anything changed?32:33How often that bold query runs? That is what we knew as polling interval The polling interval so is how often I ask to the UEM, hey, this is my compliance set.32:36Gives me the latest compliance status. This is a bulk query and the UEM answer with the status for that list. You can set it from 15 min to 1440 min. The default here is 4 h.32:55And that's the recommended starting point. If you drop it to 15 min, one thing you need to watch is the size of the list. When a quiet period maybe 1 % or 2 % of the devices you own are non compliant.33:14However, after a Windows or Apple update, you can jump to 5 % or even more. So the bulk query gets larger and that loss hits both ICE and the UEM and the UEM.33:32Will suffer from that amount of checks. So that's why the call is paginated and why it's designed scale is about 20000 endpoints per retrieval, something to keep in mind.33:48This is actually what happens when we do the polling interval. I send a bulk query for the non compliance set, so it asks hey gave me the latest status. The UEM does not reply with.34:05This one changed, this one changed, this one note, it just returned everything. Just return the current compliance status for their entire list. ICE then compares that with what it has before. So if a device was not compliant.34:22And now it's compliant, I can send a change of authorization to the network device so it reauthorized the session and the user leave their restricted state.34:40This is what polling is for. So pick up the status change while the session is still up, then change of authorization to apply the new access. Let me show you a little bit of authorization policies, examples.34:55So here, this is a deployment it's already integrated with in this case, more than one you can see here in the video. We have.35:15Oh, let me show you, so you need to have at least one UEM integrated so you can see the MDM dictionary. As you can see here since we have two, it will show you here MDM dictionary.35:35Let me see if I can do better. Oh, yeah, I missed it there, but yeah, it will show you the MDN dictionary. Again, this only will appear if you have at least one MDN server added. If not, then you won't get this MDN dictionary.35:55Here you will see the dictionary attributes so all of these are attributes that comes directly from the MDM servers. The exact list again will depend on the vendor, and here is an example of policies.36:17So this is a very basic policy. You can do even more complex policies, but here in the policies you can, you know, check by last checking manufacturer operating system. You can use the entire dictionary I show you before.36:34You can have, e.g., in here I will show you, so you can have policies if the device's status is compliant, if the device's status is registered.36:55If the device status is registered but not compliant ready to this page or that page. If it's registered and compliant grant employee access, you can do a lot of things with the policies and the dictionary.37:13So this is the example that we just saw is just solely based on registration status and compliance, but you can even also match the MDM server and this is actually one of the recommendations.37:34To add the MDM server name, even if you only have one, this is recommended because, ICE here will check also for the MDM name.37:53And doesn't rely only on cache. Here's another example you can do more granular policies, so you can see here that MD, you can use more MDN attributes like server name register.38:08Compliance.38:29This encryption, whatever you have in the directory and the vendor or the UEM is sending you, you can use it in your policies. You can also combine those attributes with identity groups and with different protocols. So, e.g., you can have same, same NDN results, but different.38:31And access depending on who the user is and how the device authenticates. So this is how authentication based on protocol looks like and this for sure gave you more granularity to your policies.38:51There are some cases where ICE cannot reach the UEM, so maybe there is a network connectivity issue or the UEM itself is down. You can play around that. You can mark, you can put the the policy and mark the devices unreachable and you, you know, you can create.39:11Policies depending on that.39:31And that was everything for the overview, so how the integration works and the n version two and version three hash polling and policy. Next, next is the demo part. So let's take a short break and when we come back, Jeffrey will take us straight to the demo.39:37All works.39:57Thank you all. I hope you had time to refresh, and we will continue with Jeffrey. As mentioned he will be showing us how to integrate ICE with different MDM vendors, so I hope you enjoy it. Over to you Jeffrey. Thank you, Veronica.40:00Yeah, welcome back, everybody, everyone. So we're gonna start with Microsoft endpoint Manager Intune. We will see that ICE can also integrate with multiple MDM UEM vendors. Before we jump into the demonstration.40:18And I would like you to understand the packet flow.40:38You might've seen already this, but everything starts with an authentication, right? Once the user is authenticated, ICE will take the Intune device ID, either from the subject alternative name of the certificate or the common.40:43Name, ok? Once ICE has this information, it will query to the MDM server in this case Intune, then Intune will reply only with these four attributes, ok?41:02We have the managed by Intune, the compliance status, MAC address and Intune device ID, ok? With this we will create our policies as mentioned before and.41:19And then based on your network requirements you you will send the, a specific access to the network, ok? Cool. So we're gonna start, I have my.41:35Computer and I'm gonna connect it to Intune, ok? I'm doing it on the settings, but you can also do this on the company portal, ok?41:52So this will take a while. Once this is done, we will see that the device is successfully enrolled. Again, we can do this on the company portal. We're gonna access to it and see that the.42:09Devices successfully, enrolled, they can access the company resources. What we can do sometimes that the synchronization may take some time to get all the certificates and profiles from Intune. We can do a manual sync.42:26Like I'm doing in this, in this case, we can see that it's successful. Again, you can access the company and resources. Now, let's take a look at what we have on.42:44The machine, so this is a certificate that it was provisioned from Intune. We have for username test user we're gonna see that the, the certificates that, that were issued by.43:00Well, this is the basically the CA from from intune. It was called PKI root.cloud pki issue in CA. Everything was again provisioned by Intune. One thing that I would like you to see is the subject alternative name, right? So, on the circuit.43:19Okay this is a engine device ID, right? The QUID, and this is what ICE is gonna take.43:38It's going to take to query into right for the authenticate for the, to get the MDM status from, from the MDM server. Cool. Now, since.43:44The the device is already enrolled to Intune, we have to not only the certificates but the the configuration in general for the authentication, so we're gonna just do network authentication, we're gonna disable the network interface card and enable it back to trigger the authentication.43:59Okay. We're gonna jump in immediately to the Windows devices and we see that our computer or Windows computer is here.44:19We have, well, we have all the information, but one thing is that we have the internet device ID, which is the same that is imprinted on the software alternative name on the certificate that we just saw. We have also the status of the, well we have the Mac address, we have the IP.44:36Be that it's using the enrolled date, last contact and all the attributes that ICE is gonna use for taking the issues on the authorization policies, right? We have to producer compliance.44:56Right. Now, let's jump into the ISO and it's already here, but let's take a look at the at the configuration. Pretty much simple. There, there are some things that you will have to drop from the.45:12Engine server we have sorry let's go back here. So we have our client ID, we have our talking issue this information will be available on the engine side. We're just gonna grab this and copy and paste it here.45:32We test is successful and this is one thing that it's really important for the MDM in general, ok? So we have the device identifier. This is what we're gonna tell ICE what where the QID is located, ok? So, we have the SAM remember and the.45:50Right, but we also have the legacy Mac address just as a fallback method, ok? So if the, if the ICE cannot find the UAID, it will always be reliant on the MAC address.46:10In this case we're gonna use the SAN to identify the UID, we have four authentication attempt. We have for test user as.46:22We saw on the certificates in, we have our MAC address, we have for authentication policy, authorization policy, or we have for MDM server. We're gonna take a look also more details on the live log.46:37So Cool co cool cool. Now let's take a look on the details. Once again, we have more information here, but.46:57Cool. We have for authentication policy policy authorization policy, what I would like you to see is the MDM attributes, ok? Well, we have our authentication method. We can configure the.47:15Well PKI issue, we saw this from the on the certificate side. Again common user, common name, UUID, and if we go to the contact visibility, right, we will see the MDM attributes, ok? So on the compil.47:31Guess what we're gonna filter by Mac address in this case, I already know which one is it's almost last one.47:51Okay. Now, let's go for MDM, That's here. So we have, this is all the MDM attributes that ICE will work with, ok? But if you remember from the previous.47:58Like.48:19Intune will always share, will all only share four attributes, ok? And if you see we have some default attribute default values so in this case, please don't not do not use it, ok? If you are integrated with Intune, this will all.48:20Usually the same, ok? Even though the eyes will let you choose these attributes as conditions.48:39This will be not flyable because the information will be the same, ok? So use the ones that we know, we have compliant, enrolled, right? So use this to create your policies.48:47Oh Excellent. And now we are gonna take a look at the queries on the NDM reports, ok? Let's scroll down.49:03One thing that I always say when we take a look at the live logs and the reports is that you can use this information to create your conditions, ok? If it's, if it, if it's not working, you can see why it's not working, but if it's it's working, you can see what attributes is.49:19Taking from the session information and then based on that build, a more granular condition on your authorization. But now let's move to the.49:39Reports on the MDM site. So every time the, that the user authenticates ICE is gonna query the MDM server. We see the information that we saw on the, on the live logs, more details here.49:52Once again, the default values, this will always be the same. This encryption being locked, rooted. The ones that we know is registered status and compliance, right? Sometimes if we scroll to the right, we will see some extra details.50:07On the failure reason, ok? Not always but we will see it. Now if you move to the authorization, this is a simple one, right? We're just checking only MDM attributes here on MDM conditions, but you see that the MDM server name is in this case is Intune.50:26That's the name that we put on the, on the MDM configuration. We are checking here if the MDM device registered status is registered and the compliance status is compliance.50:46We're just sending an employee access which is which is a limited access, but depending on your network requirements, you can send different profiles, right? We have a, if the devices is registered but not compliant, then we're gonna give it a.50:58Redirection to the MDM, and but that's pretty much it, right? You can add sorry mentioned more conditions based on protocols, right? And combine it with the mdmiss.51:16Add reconditions. Now moving into JUMPF, let's take a look at the packet flow again and authentication, PLS authentication. Once the device is authenticated against the network.51:34ICE is gonna take the management ID again from the CN or the subject alternative name. It's gonna query Yamf using MDMB three and YAMMF proof reply back with more attributes. We have days since last checking manufacture.51:51This or notified.52:11Device compliance status et cetera etc. So you can build a more granular condition, more granular policy set on the authorization side in ICE. In combination of the, not only with the MDN conditions but again with the.52:13Protocol protocol conditions, right? You and and give different access to your users and devices, yeah? Second how we integrate that in ICE. So I'm gonna add that configuration here. We're gonna use that.52:32This is the authentication, I have my host name port, network name and username and password, ok?52:52I'm gonna enable it, test connection. One thing I want I want you to understand is that, we have seen many cases of that the test connections failed because of the certificate. I'm gonna show you in some slides.53:00In the presentation, how we can solve this, but one thing that you have to understand is that the ICE will communicate and will make that trust connection using certificates, right? So you have to make sure that the certificates, the CA certificates from the MDM server are.53:20Installed on the trust the start on ice, ok? In order to work, ok? Again, we have the device identifier, we're gonna take again the SAN, we can always rely once again from the legacy Mac address.53:37I'm gonna check this, save, and that's it. Okay, so let's move to GMF. On Jamf I already have my Mac mini enrolled, ok?53:55So if we go to the inventory search, computers that it is and so take a look. So we have all the information here from the site we have our management ID, which is the one again that ICE is taking to query the server.54:11We have pretty much all the information as well, we have the IP addresses, platform, right? And all the attributes that we can use on ICE to build the condition. So it's already enrolled. We have our certificate provision. This case is a little bit different. We have our common name.54:32And the command name will be the one that is displayed on the, on the live logs you remember. So we have AD posture.54:52If we scroll down we may, we're gonna see more information of the of the certificate, but one thing is the one thing that I would like you to see again is the is the subject alternative name TMF, which is the same ID as we saw on the.55:01On the site. I show this and I repeat it because again this is pretty much the important stuff here, right? This is what ICE is taking to query the MDM server. I might, it might sound repetitive, but it's really important, ok? So what we're gonna do is just do a Wi-Fi authentication with the TLS, ok?55:19So let me connect here and select the certificate for the application. AD posture, ok, gonna pop up again. Cool.55:39And it's done. So on the details I'm just gonna check that the authentication was APLS, we already know that well, good, good. Let's go here.55:57Let's jump to my next cool. That's good. Now if we go back to ICE, we will see the authentication attempt from or.56:16Mac mini, and we again we will see all the information from the from this session. We have TLS, I see the authentication method, we have our Mac address, the server that was authenticated from ISO 25, and if we jump.56:28To the, let me jump straight head to the MDM report. So if you see we have multiple attempts and again every time that the that the device authenticates to the network, you will ICE will query to the.56:46Server. And if you see here, well in this case we have a different result even though now remember that we had we I show you the default values, but in this case DMF will reply back with more attributes that we can use.57:06The results are different, sorry. In this case we can we can rely on this information, ok? So in this case it's false and this is actually ICE is getting this information from the GMF and we can use it to build work conditions, ok?57:20We have for manufacturer. If you use profiling, for instance, you can use MDM to get more information or to help Eyes to classify the endpoints better, ok? Let me skip this. If we filter here, we will see the address that I was mentioning before.57:37On the eye side, scroll down Cool.57:59Yeah which is username, US compliance status you see this is the same that we saw on the reports, not compliant, registered but not compliant. Now we'll see all.58:15The MTM attributes, right? That that we can work with to create our policies. Again, UUID, false true to work in false.58:35MDM model again for the profile, this will be very useful right to to have more information on the device. So our ice will reclassify it and if you work with profile, you can use this as.58:53High condition cool. Now, for the Cisco's integration with Meraki system manager, we're gonna jump immediately to the Meraki site and I'm gonna show you what.59:09I'm using for Wi Fi profile, ok? To scroll down, this is a Wi Fi both term using, it's called scap. We're gonna do this, we're gonna need need this setup URL, username and.59:25Password so we're gonna do this into ICE.59:45Username password and enable it test connection, all good. So I'm gonna use again well I'm gonna show you something. I'm selecting here send, but we will see some.59:51Something on the on the.01:00:10On the authentication attempt. So we are gonna need to put the MDM server URL. Once this is provided, it's gonna ask us for a network ID, this is because maybe your system manager of.01:00:12Might be on a different network ID, so that's why he's asking us to do that and once this is done, we're gonna need to prove our authentication by logging in and then that device will be enrolled.01:00:32Okay, now let's move to the site and we will see that our device is enrolled successfully, ok? Now we can manage your device from the MDN site. We will have all the information.01:00:48VMware model et cetera etc. Now let's scroll down and we will see.01:01:08And one thing that I would like you to show you it's and it's what certificate was provisioned? So if you see, do you notice something different from the certificate, from the other attempts, right? Let me help you.01:01:15You see? So instead of putting a username, ICE, if you remember, we're taking the sand, right? But in this, in this certificate profile from, from Meraki, we are putting the UID not only on the sand.01:01:31But on the common name, ok?01:01:51And I'm gonna show you why we don't recommend you do this, ok? After the name because I, in this case, this is what he's gonna be presented on the on the live box, right? So we have this.01:01:55Subject. Cool. Now let's see how does this look on the eye side an authentication, it's already provisioned.01:02:12We're gonna enable the Nick, good, and so you see identity change to the UID, so in this case it seems it's only one user, it's easy to identify, right? But.01:02:28If the more you have it will be more difficult to identify which users are accessing that, ok? But yeah, pretty much the same. We have the or or authentication tempts, APLS, Meraki system manager.01:02:47Yeah Virtual machine, it was able to identify there was a virtual machine actually because of the MDM attributes and ICE is taking through the profile again.01:03:07In a filter here, we'll see all the attributes once again is for you to see it. So we have for UID, MDM compliance MDM description.01:03:23Etc etc. So a little bit of troubleshooting I wanted to add on the on the slide and it's that I, we have seen some cases that but.01:03:39Clients to know what certificate they need to stall, right? One thing that you can do is, take a packet capture and and check what is the certificate that the MDM server is sending to you, ok?01:03:54So in order to do this, you will have to run the packet capture while you do the test, ok? So that's possible. If you go to operations rollshoot, this will, the test will be running from the admin, ok?01:04:12Every time you do a test, it will be running from the admin, so start a capture from the admin note and then do the test. Once you get the error message, you will normally get the, that there's a problem with the certificate, right?01:04:27So once this is done, you can stop the capture and then open Wireshark and which is because in the in the 1st step we're making sure that the ICE is actually requesting the the you know the the.01:04:43TLS handshake, right? It's regressing the client, well it's initiating the the connection client hello. This case is with the against Microsoft. We're gonna see if there is a TLS alert. In this case, there is a unknown CA TLS alert. So it's eyes not recognized in the certificate.01:04:59Is it trust in the certificate, sorry?01:05:19We're gonna do a follow TCP stream just to follow the the conversation. Then we're gonna locate the server hello from the MDM server, right? And we're gonna, on the on the attributes we're gonna locate the certificate on the pa under the package.01:05:22Details, ok? And then we're gonna export the packet bytes. With this, we're gonna export the certificate that the, that the MDM service sending to ICE, and then we can install these certificates in the ICE trusted store. Going into administration, system certificate.01:05:41Trusted certificates and important, ok?01:06:02So just we wanted to add this part for you to to have it, ok? You can also check the, the locks. It will be a lot of information a lot of information but you will see all these steps as well of the MDM connection attempt, ok?01:06:07Now we have seen that ICE is capable of integrating multiple MDM at the same time, and you may ask why there will be different use cases. For instance, if your company.01:06:26Is on a migration process from one MDM to another MDM, you will be at some point running two MDM servers at the same time, so that will be one case.01:06:44Another one is that one location is managed by one MDM UEM server, and another location is managed by a different UEM MDM server. And the 3rd one might be that one of the MDM.01:06:57Vendors does not support certain model devices or certain operating systems. So at the end you will have to run different UEM and MDM vendors at the same time. So we have ICE have the capability of integrating multiple at the same time, ok?01:07:16So how does this work?01:07:36So after, again, after the user is authenticated to the network, ICE will take the UID, query the MDM, but in this case, if the endpoint is not registered, there might be two conditions if the endpoint is not registered or if the MDM.01:07:40Again sends an error on a section exception response. What ICE will do is fall back into the next MDM server, ok? Th there will be a timer for the fallback, for fallback and it's 30 s by default.01:08:00And this will happen and you can do this up to five MDM, so we can have five MDM as a fallback method, ok? Until ICE finds a match, ok?01:08:20Now, let's take a look how does this work? We have our different NDM servers integrated, and this is not enabled by default, ok? So we have to go to the general ndm.01:08:38Settings and there it is. So we have to enable this.01:08:56Yeah, and it will checkbox and save it, ok? That should be it. Now, if we go to the policy sets, what you have to do is just make sure that you have your server.01:09:02MDM server equals condition on the MDM servers that you want to check for each authentication, ok? So we have for Meraki, we have for, we have for ivanti, and we have our engine in this case, ok?01:09:20So eyes will check each one of these and if the conditions match meaning that the device is not registered or if there's an exception, it will continue, ok? Querying the different MDM servers until it finds a match.01:09:39If, ICE doesn't find a match, you can also send a redirection. Okay.01:09:59To, to for the device to to complete the the enrollment, ok? There it is, the onboarding process, ok? Now if we go to the.01:10:06Reports, you see I have four devices, this three devices on the bottom, and they are authenticated with different UEM vendors at the same time, ok?01:10:23Cool, so we have learned, we have learned that the difference between when to use posture or MDM, right?01:10:51Whenever you can please adopt MDMB three for the MDM integration, we have seen the capabilities over V two. It's better against Mac randomization use cases, right? I scan, if you you saw that we.01:11:11This can integrate with multiple vendors, but if a new vendor comes.01:11:31What it needs to make sure is to implement the MDM APIs on the documentations. Reach out to us on the chat. You will find more resources if you want to know more about the MDN or any other topic from ICE. There is.01:11:37Day of documentation, you can reach out to us at any time.01:11:57If you have doubts about it, there is a huge team that it's will be happy to help, ok? And that's pretty much it you can take it from here. Thank you.01:12:01Thank you. Thank you Jeffrey and thank you for it, and before we wrap up, we will give you some time back but I would like to as well share some of the available free educational services. I also pasted a few links in a chat along with some documentation about.01:12:18MDM and ICE integration, iceberg, which is really.01:12:37A holygrail office documentation. One of the links is cyber capsules. A cyber capsules is a webpage where you can find a series of videos. They are around one or multiple products, but we have multiple videos per product. Those are really short videos, 1020 minutes.01:12:42Long and they give you an overview about a specific topic. So feel free to visit the webpage, check it out, hopefully you'll find it useful.01:13:02And if we can go to the next slide, we as well have some upcoming security customer success expert inside series. The link is along with the other links in a chat. Here we placed.01:13:13The webinars not related to ICE specifically but to other security products. But I would like to highlight one of those and that's 2nd line, Cisco dual identity security for your Cisco portfolio. A second day of this webinar will be about integration of duo.01:13:32With ICE and secure firewall. So if you are interested in learning more about this, I really encourage you to register and join the session.01:13:52If we can go to the next slide that will have ICE upcoming expert inside series. On the 24 November at 10:00 A.M. we will have a session about.01:14:04ICE best practices. We will talk about how to be secure in this post meters era or what are the best practices when it comes to upgrade, about the hardening of ice. So feel free to register. We'll be sharing a lot of useful information. Sometime between February and April we will run a.01:14:17Segmentation or trust sec webinar and between May and July we still do not have the dates yet. We will talk about next generation ICE or ice 4.0 and what's new.01:14:37And as always, your feedback helps us be better and improve. So we really would like to ask for a favor, once you close the session, the.01:14:51Web oh webpage will pop up with the post webinar survey. Please take a minute or just a couple of seconds to give us your feedback. Tell us what you liked, what we should improve and if you like the session, give us five stars.01:15:06And with that, I would like to thank you for your time, for your attention. I would like to as well thank our presenters, and Jeffrey for sharing the knowledge and all the panelists for answering the questions. And with that, have a nice day.01:15:22