 All right, welcome to improving the security posture of macOS and Linux with Azure AD, Mark Morzinski. And I'm here with Michael Epping and something we've been trying to do to try to be more inclusive of those with a visual impairment as quickly just described what we look like. So I am a late 30s white male with medium length brown hair. I have glasses that are blue and black outlined and today I'm wearing a black shirt. Michael. And I'm a mid 30s white male with short to medium brown hair and I'm wearing a blue striped shirt. All right, so thanks so much. So Michael and I are both product managers in the identity division at Microsoft. So we work on Active Directory, Active Directory Federation Services and Azure Active Directory. And we spend most of our time working with customers on their deployments of Azure Active Directory. And we take the learnings and feedback from those deployments and we work it back into the product to make it easier and better for everybody else. So in the last year or so, Michael and I have been working with some of our customers that have a larger Mac footprint as well as some Linux footprint. And we wanted to share some of the learnings we have from those deployments here with the DEF CON community here. Also, we will both be live right now on your video, but also in the chat. So if you have questions about anything we're talking about, feel free to post them in the chat and we will go through and answer those. So all right, so let's go ahead and get started. So the first thing is we're gonna talk about just to give everybody a quick high level overview is what is Azure AD and conditional access? So let's go ahead and start with that. So if you're not familiar, if you have Office 365 and you have Azure, you have Azure AD. So Azure AD is the identity provider for those two things, but it's not just an identity provider for those two services. It is a full blown identity access as a service. So we can do things like provision users or deep provision users to applications. We can build things with dynamic groups. There's a whole bunch of stuff we could do here. We can do a full several hour session on Azure AD if we need to. So if you have any specific questions about Azure AD, feel free to reach out to Michael and I either on Twitter or in the chat. But from now just as a high level, it is the IDP for Office 365 Azure and Azure and a bunch of other things as well. Now, something that we saw with a lot of our customers that definitely got accelerated with COVID was that users were looking to work more outside of the office. So they did most of their work in the office, but they wanted to be able to work from home, work from the coffee shop. And the resources that they were accessing are no longer just gonna be on that prime network. They're probably using things like cloud services, SaaS apps, things of that nature. And the devices that they're using are most of their work is probably done from their corporate device, but they wanna be able to do things from their personal phone. They wanna be able to do things from like your iPad, things of that nature. So this is really starting to spread. And it started to kind of move into this method where no longer is it we're only accessing these resources that are on the corporate network and that boundary of the network is the boundary. Everything inside is safe, everything outside is bad has really started to kind of go away. And if you've been to any Azure AD talks before, you may have heard us talk about how identity has become that control point now because that's the consistent thing across all of these different areas. So that's kind of where Azure AD can come in. So let's talk about a very specific thing around Azure AD that I think is really important. Like I said, that we can do a whole bunch of topics on Azure AD, but something I wanted this community to get across here is that Azure AD is built on open standards. This means things like OAuth, OpenID Connect and SAML. And if you actually crack open any of the Microsoft applications themselves, you will see that they are built on OpenID Connect. Now we're continuing to invest in new standards, things like FIDO, as well as the decentralized identity framework. We actually have a whole team of people that work on this. They're led by Pam Dingle. If you know her from any of the identity stuff, she's great. And her team works with these different standard bodies and foundations to help define new and emerging standards. And a good example of this is if you saw the Pass Keys announcement by the FIDO Foundation, you can read more at aka.ms slash passkey announcement. This is going to be supported by Microsoft, Apple and Google. Tim on her team actually helped work with the FIDO Alliance and those groups to agree on that standard. So not only are they helping define new standards, they also make sure that Azure AD will support those standards. So if you have any applications that support OAuth, OpenID Connect or SAML, you can quickly integrate those into Azure AD, which allows us to use things like conditional access. So if you aren't familiar with conditional access, this is our zero trust authentication and authorization engine. As an admin, you can define different sense of conditions. And if those conditions apply, the user device will have to pass certain controls. And if they do, they are then granted access to that resource. So it's all there in the name conditional access. And it's common question we've seen with some of these other communities that maybe aren't so familiar with Azure ADs, like the Mac admin community, is that when is conditional access being applied? Like I logged in first thing in the morning, I got prompted for MFA and then I went to access that same application later. I didn't get prompted. Is conditional access even working? And the answer is yes, conditional access as you dial it, every time a user or device is requesting access to a resource and they're getting that access token. I'll talk a little bit about that a little bit later. This kind of goes into modern authentication. Now, what are some of the things you can do from a conditional access perspective? So you can configure things based on where the user is coming from. Is there any risk on that user? Is there anything suspicious? What type of device that they're coming from? Is it a Windows device, Linux or Mac device? Is it in a good, healthy state? Are there any application requirements that you want to enforce? You can configure a conditional access policy that says, if you're coming from a mobile phone and you're trying to get your email in exchange online, that you have to come from the Outlook mobile app because that prevents people from accidentally saving attachments to their personal OneDrive or their personal Dropbox. It has to be saved to the corporate OneDrive or the corporate Dropbox. And some of the resources that we're trying to get to here may include Linux servers. And Michael's going to talk about things we can do with that here in a little bit. But let's take a look at how conditional access actually applies. So we've seen this question come up and people want to have a conditional access. Like they want the first policy to apply and if that doesn't apply, they want the second and third policy to apply and things of that nature. Unfortunately, conditional access does not work that way. There is no precedence. So if you're familiar with how group policies work in Active Directory where you have that local site domain OU precedence, it does not work that way. All conditional access policies are entered together. And then the first question that's asked really is, is there a policy that applies in this scope of this request? If the answer is yes, it then goes to these following controls. So the first is if you have a block control, the default and I will always win there first. There's no block controls. Then we have a grant control that goes in this order of risk, MFA, device, and then again that approved client app. Now a key thing to remember here is that conditional access will try to satisfy the policy without having the user have to do any interaction. So if you have a conditional access policy that says we either have to do MFA or come from a compliant device. If the user is not coming from a compliant device, they would then get prompted to do MFA. So you can see here on the right, Michael tried to log into the Azure portal. He was coming from a non-compliant device. You can see that as the attribute here is set to is compliant is false. That's what the arrow is pointing to. So this is actually controlled by Intune. We'll talk a little bit about how this works here in a little bit. But it's really important that as defenders and maybe people that have max in our environment, living clients in our environment that we understand what those conditional access policies are because those can greatly impact how the behavior is for that end user. So let's take a look at what are some of those common policies that we see. So again, talk to your IM team. If that's not you understand the policies but things like requiring MFA for all users. This is really, really good. Blocking legacy authentication. You've probably done that already. I know we've had talks about this here in the past. Things like pop three, I'm at four. Blocking access by a country location. So saying we have no users in this region or we have no business interests in this region, we're going to block access all together. Requiring compliant or a hybrid joined device. So we're starting to see customers moving this way that it's no longer okay just to do MFA that you also need to come from a device that's known and managed by the environment. So this is that device identity aspect. We're also starting to see the inverse to this which is where we're going to put stricter controls for non-corporate managed devices. So this is always that like grandma's PC, grandma's workstations to know that the security teams love to talk about that they're at their grandma's house for a holiday. And that's when someone decides that they're going to get a couple hours of good work done and instead of using their own PC, they're going to use grandma's PC or grandma's Mac. And we don't want that session to persist for hours, days, or weeks. So the security team sets a policy that says if you're coming from a non-corporate device, you're going to have to reauthenticate every two hours. And if you haven't done the work, especially on your Mac side to do an integration with Azure AD, Azure AD is going to see all of your corporate Macs as unmanaged devices and these stricter controls are going to apply to them. And this is going to be a very, very horrible experience. And if you talk to your security teams about that, hopefully that's you because you're at the DefCon Blue Team Village here. Some people on your team may say that this is good from a security perspective. They'll say, we practice zero trust. We don't trust anyone. We don't trust any devices. We don't trust anything. We want people to be reauthenticating because that is proving who they say they are. This is good from a security perspective. And in theory, that sounds like that would be right, that we would want people to continue to be reauthenticated. That sounds like it would be a good security practice. But in reality, what we found with customers that probably isn't having the same security benefit that you think it is. So let's talk about why over-prompting our users is bad. So we had a customer case study here. One of our large financial customers in Europe, they had their red team doing a cyber attack. So they're running through the playbooks and they're doing that password spray and they found some users with easily guesstable passwords. So maybe something like summer 2022 exclamation points or something like that. So they found a couple of accounts and they asked their leadership team, can they just hammer these people with MFA prompts? And they said, sure, not a problem. We'll tell our help desk. So when they call and complain, we can tell them what's going on. Here's what we found. First of all, no users reported that there was any extra prompts. So that's off to a bad start. And then many of those users actually just blindly approved those MFA requests themselves. So that's having the opposite effect we want from MFA. And one user was so fed up with the amount of prompts that they were getting, they just uninstalled the authenticator app entirely. Like I can't even be dealing with this thing. They just deleted the app from their phone entirely. So this is obviously what we don't want from a security perspective. So we found really when you over-prompt your users, this is really bad from a security perspective. It's going to lead to compromise. You're teaching your users, bad behaviors, you're teaching them to give up their credentials all the time. And when you have lots of MFA prompts during the day, so they get four, five or six, when an attacker gets a hold of their account, they go to logging with those credentials and they get that seventh or eighth MFA prompt, they're just going to approve it because they don't know better and they've already approved the previous five or six. So we don't want to blindly have people getting all these MFA prompts. Now, now is it bad from a security perspective? It's bad from a productivity perspective, especially on platforms where we don't have single sign out of the box. This includes things like Mac OS and Linux. And we'll talk a little bit about that later today, how you can improve upon that. But really, as defenders here, we should be striving to improve our end user experience and improving security. And we're going to do that by only prompting our users when it truly is needed. So things like when they're coming from a new device or they're coming from a location, we've never seen them come before. There's something else has changed in their risk profile. That's when we want to prompt those users. And the credential type we want to use when we are prompting our users is a passwordless credential. It makes for a better experience. It's a stronger credential. And we'll talk a little bit about that at the very end. But the thing I want to make sure I stress here is that many times in our environments, the Mac OS and Linux clients and servers are a more of a smaller subset and they don't get the type of attention that they probably deserve. And they are probably falling into this bucket with these conditional access policies where they are having a really poor experience. And we probably are over prompting these users more than we should be. So let's go ahead and move on where Michael's going to talk about... Oh, sorry, I forgot one part here. Yes, so the first thing we're going to need to do is we are going to need to determine if we have a prompting problem in our environment. And unless you've been spending time on this, you probably have some room for improvement. So you want to be able to show this with data. We actually have somebody on our team here that used to work in Power BI. And he has a shirt that says, in God we trust, all others bring data. And all of the data you need for this is in the Azure AD sign-in logs. So we have a workbook here for you. If you go to ak.ms slash MFA prompts workbook, this is a free workbook that uses Azure Monitor and Log Analytics. If you're not sending your Azure AD sign-in logs to Azure Monitor and Log Analytics, that's okay. Go take a look at this because you can see what all of the queries are. And then you can then write your own query and wherever you are sending your Azure AD sign-in logs to something like Splunk or QLogic or SumoLogic, QRadar just combined two seams together there, Cousteau doesn't really matter, but you can take that from there. Now in this workbook, we will show you lots of different things. The first thing you can see is which of your users are being prompted the most. And this can be a very eye-opening experience for some customers. We'll also show you what is the average amounts of prompts that you're getting in your environment, as well as what are the applications that have a very high prompt count. We've had customers that find that their applications are actually misconfigured and it's actually causing more prompts than really, really needed. So you'll see all this type of stuff in there. The other thing that we're gonna find in here is what is the device state of those prompts? So here you can see on the graph on the right-hand side, 95% of the prompts are coming from unmanaged devices. And this is really, really critical to understand because we may be having those more stricter conditional access policies being applied to them. So we're gonna wanna look to move those types of devices, those Mac OS and Linux devices from an unmanaged state to a managed state. And we'll talk about that here in a little bit. But now Michael, it's actually gonna talk about how we can do some things on the Linux server side. All right, so let's talk about how we can turn Linux servers into a resource that can be protected by conditional access. So we said earlier that Linux servers may be a resource, but I would contend that they should definitely be considered one of these resources that we need to apply zero trust type policies to. So in Azure AD, we have a capability to protect access via SSH to Linux servers with conditional access and other Azure AD tools. So this would include conditional access where we can do things like require compliant devices, require MFA, use passwordless sign in methods. There's other tooling that we can use like privilege identity management so that users don't have standing access to things and they have to check out their access. So there's a lot of different tools that we can use to start protecting these servers with the same types of conditional access policies that we're using for other applications in our environment. And we also have the capability to do this type of protection for more than just your own users. If you need to have machines accessing those Linux servers using SSH, we can protect workload identities or what may also be known as service principles as well. So there's a lot of different features available here. So I wanna step back and talk about why do we need a tool like Azure AD to protect SSH access to VMs? So we're gonna kind of lay out how our customers are accessing Linux today or what the common access patterns are. So it's really, really common for out of the box Linux installations to use password authentication. So in this case, the user sends the username and password over the wire to the device. It may be validated locally. It may be validated by another system like a Radius server and LDAP server, but the username and password are passing over the wire. There could be an LDAP service in the mix that we have customers who use Active Directory to validate user credentials or other LDAP stores. Kerberos is an option. Some customers use public key, private key pairs. This is another very common option out of the box on Linux distributions. This could, again, just be credentials that are local to that specific Linux server where the user has a private key on their local workstation. And instead of sending their credential over the wire, they basically sign a random piece of data with the private key and then the public key on the server is used to validate it. In some environments, customers are a little more mature and they manage these keys with some sort of tooling. So there could be a process to go revoke keys when a user is terminated or to distribute new keys when a user is onboarded. But it's fundamental to understand that this is still a very on-premise-oriented technology in many cases. It's typical that this is not using web-based protocols like WebAuthn or Fido or some of these newer protocols that we've talked about previously. There's also options like user certificates, but in the end, most of our customers end up using what the defaults are in their distributions. And so really commonly, that's public key, private key, and in some case, passwords. So not very cloud-oriented credentials, not very zero-trust-oriented credentials. So most Linux distros, like I said out of the box, assume either password or key. And you can see here in the upper right, we have password authentication where I'm just sending my credentials over the wire to the Linux server. And in the lower right, you can see I have a private key that's stored on my workstation, and I use that private key to access the server instead. So it's a little bit more secure, but it still has a lot of management overhead. So what we found is that customers really struggle with some of that management. If you're using LDAP, you have to manage the LDAP system like Active Directory Forest, Radius Infrastructure, whatever tooling you're using to distribute public keys to machines, PKI if you're using user certificates. And for a lot of organizations, key revocation and being confident that your keys were revoked properly is very, very difficult. So if I have to do an emergency termination on a user, how confident am I that they can't access some Linux server in my environment using a private key that's still on the workstation in their possession? In a lot of organizations, the confidence level there is not super high. Again, Linux doesn't support web authentication or FITO out of the box. So there's really a lack of modern authentication options. So this leads customers into those other defaults in the OS. So the weak passwords or the hard to manage keys. And there's little to no device-based control available. So unlike with conditional access where we can validate every time the user is accessing something that the device is known and in a healthy state, for most customers, they protect their Linux server workloads with network-centric security. So they might put a firewall around the network where all their Linux servers exist. And then if a user is through the firewall, they could theoretically reach any of the Linux servers. So this is a little bit of an old-school approach like Mark mentioned. So we're gonna try to solve some of this with Azure AD and here's how we're going to do it. So just like accessing any other application, a user might authenticate to Azure AD and we check their authorization. So we might check to see if they have the appropriate role on the virtual machine, the role that they possess might be PIM enabled so that we can force them to do a checkout on the virtual machine. But if everything works out and they successfully pass all the conditional access policies and all the RBAC checks go correctly, what they're going to get back in return is an open SSH certificate. So just like in a different type of application, like say exchange online where I might open an Outlook client and Outlook needs to go acquire an access token, if I'm accessing a Linux server, I'm going to go acquire an open SSH certificate that is short-lived like an access token. So sometimes we call this an ephemeral open SSH certificate. So it's an open SSH certificate from Azure AD that's only good for an hour. And that way, if I need to do an emergency termination on the user and an hour passes, they won't be able to access any of their Linux servers anymore. So it's bringing that short-lived token model that we have for web applications to Linux server access via SSH. And then once they are in possession of that open SSH certificate, they can access VMs that are running in Azure. This is a generally available feature. And they can also access virtual machines that are running in AWS, GCP, on-prem data centers, basically anywhere else using an integration we have with a tool called Azure Arc, which is a multi-cloud management tool. That functionality is in public preview today. And I'll talk in a little bit about how this actually works under the covers. So before I get into the specifics, let's talk about some of the prerequisites to make this work. On the client side, so my workstation where I'm initiating the SSH connection, I need to have an open SSH client installed. So by default on Linux or Mac OS, this is likely going to be there, might need to install it on Windows, but basically any operating system that has an open SSH client on it can use this functionality. So under the covers, we're not doing anything different with SSH. We are just using open SSH like any other client might. Then we have a wrapper that sits on top of open SSH that's provided by a tool called AZ-CLI. This is the Azure command line interface tool that comes along with Microsoft's auth libraries. It's highly recommended to use this tool. It makes the user experience much, much easier. There are options for exporting certificates from AZ-CLI and then doing open SSH commands yourself, but there's a lot of extra work involved and extra steps there. So I recommend using AZ-CLI and I'll show you the commands for that in a little bit. There's also an extension for AZ-CLI that you have to install one time. You can run this on basically any client OS. So Windows, Mac, Linux, Docker containers, Azure Cloud Shell, basically anything again that supports open SSH and AZ-CLI is going to work here. And then the client has to be able to reach the VM. So this is specific to VMs that are in Azure. I will talk about some slightly different requirements for the Azure Arc VMs in a little bit. But basically you have to be able to reach the VM on port 22. So this might be over the internet, although that's not really recommended. It could be over a site to site VPN to your Azure instance. It could be through Azure Bastion, which is a Bastion host solution, or you could just do it in a browser using Azure Cloud Shell. On the server side, there's a couple of prerequisites as well. You have to have a Linux server running in Azure for the Azure specific feature. The Linux server has to be running a supported distro. So on our docs page, we maintain a list of the distributions that we support on the server side. Again, we're using open SSH under the cover. So open SSH server has to be present. And then the Linux server has to be able to reach a few specific endpoints. So one is packages.microsoft.com, which is where you install the Linux installer from, or some server side components from. So that's just a standard package repo for us. This 169 IP address, which is the Azure instance metadata service. This is a service running on the host machine in Azure that facilitates some functionality that has to be able to reach Azure AD as well as Azure RBAC. Finally, the Linux server needs to have a, what's called a system assigned managed identity. This gives the server a representation in the Azure AD directory. So this is basically the resource that the user is going to be asking to access when they request their open SSH certificate. So this is tied to the VM itself. And then there's also an extension that has to be installed on the VM when you add the system assigned managed identity. So let's walk through how this actually works visually. So again, first component that we need to install is the extension software on the virtual machine itself. So that there's things in here, like a PAM module, cert handler. Then we go and install our client side components. So we have AZ CLI, along with the SSH extension for it. And that comes bundled with the Microsoft authentication library. Then when I, the end user want to initiate my connection to the VM, I issue a command in AZ CLI. And that triggers the AZ CLI to use MSL, the authentication library to go ask Azure AD for one of these short lived ephemeral one hour SSH certificates. At this point, conditional access applies. Any controls need to be satisfied like am I on a compliant device? Have I done an MFA, et cetera, et cetera. So conditional access is in the mix here and we can apply those zero trust policies. And if I pass all those checks, then I get my ephemeral SSH returned. So this is basically a one hour access token. Then what happens next is my open SSH client is used by AZ CLI to try to initiate a connection to the server that I specified. And so the cert is passed as part of that authentication to the open SSH server. At that point, the open SSH server module passes the cert to the components that we installed on the server. And we check with Azure AD to make sure that server is valid. So we want to make sure it's not a forged certificate. We want to make sure it's issued by the correct tenant. It has the right information in it. We just basically want to make sure that this is a legitimate certificate and that's something forged. We would do this with an access token for any other application. And the Azure instance metadata service running on the Azure host is used to facilitate this. In addition, we also check the RBAC roles. So there's two RBAC roles that we support today in Azure RBAC. One is the virtual machine administrator login role which gives you pseudo rights on the VM. And the other is the virtual machine user login role which does not give you pseudo rights on the VM. And these are the only two that we have today. If I have the appropriate RBAC role and my certificate is legitimate, then I get my SSH tunnel and finally I am connected. So at this point, I have signed into my VM with Azure AD and I've protected that SSH access using conditional access and my zero trust policies. So now I want to talk about servers that are running outside of Azure. So those Azure Arc VMs. So I'm gonna just focus on the bolded items here. So the first requirement that's different for the Azure Arc machines is that the Linux server must be onboarded to Azure Arc and have the Azure Arc service in a running and connected state. So basically if I have my VM in AWS or on-prem, it needs to have the Azure Arc service on it and it needs to be connected to your Azure tenant and in a connected state. So all the underlying infrastructure needs to be healthy. And then from a networking perspective, there's a slight difference. So we have to configure the Linux server to allow inbound connections on the SSH port in the Arc configuration. This is an Arc specific config. So in the Arc config, you say here are the ports that I want to publish through Arc and then this is different than your firewall configuration on the device. And I will show you what this means in a second visually. So let's step through this again for a machine running somewhere else outside of Azure. So this could be on-prem, AWS, GCP, it doesn't matter. So we installed the Azure Arc service first and this gets into a connected state with the Azure Arc cloud service. So at this point, our machine that's running outside of Azure is connected to the Azure management control plan. We install our server extension just like before, we install our client extension just like before and then my user tries to initiate a connection. And just like before they run the exact same command and M cell tries to go get a certificate. Conditional access policies apply, we can check for all of the things that we want like compliant device, MFA, et cetera. Next, we get our ephemeral SSH certificate back. And this time the SSH cert is actually passed to the Azure Arc cloud service, which can relay that traffic to the server that's running outside of your date or outside of your Azure tenant. So this is the fundamental difference from a networking perspective with the Azure Arc implementation, which is that the user does not actually need direct line of sight to that machine. So if I'm working remotely and I wanna access something that's in my on-prem data center, that traffic can be relayed to the Azure Arc service if we want. So just like before, we need to check and make sure that it's a legitimate certificate. So we validate with our Azure AD tenant that it's good. Then we check the RBAC roles, no difference here, same RBAC roles. And then finally, when I want, when everything is in alignment and I get my connection, that SSH connection is relayed to the Azure Arc service. So again, no line of sight required if we don't want it in order to use this functionality. So in order to instantiate one of these connections, we have to do a couple of things. So if we're using AZ CLI, the first thing we're gonna do is run AZ login. At this point, we're just connecting to the Azure tenant. We're not doing anything specific to SSH into the VM. Any conditional access policies that apply to the Azure management cloud app will apply at this stage. If you have multiple subscriptions, you may also set the context of which subscription you wanna be operating in. So you could run the AZ account set and specify the subscription. Then you're going to run the AZ SSH VM command and you can either specify the IP address or the name of the VM in the resource group if you don't care about the IP address and we'll just automatically resolve it for you. At this point, any conditional access policies that apply to the Azure Linux VM sign-in cloud app will trigger. So if you haven't satisfied any of the policies already when you ran AZ login, we will make you satisfy any of those additional controls at this point. However, if the controls are the same, if the AZ login controls already apply things like device compliance and MFA, you'll already have a session with those controls satisfied and therefore we won't need to trigger an interactive authentication for the end user at that point. This works the same for both VMs that are running in Azure as well as outside of Azure. From an end user perspective who's connecting to my VMs, I do not care about the underlying infrastructure. The commands are exactly the same for me, regardless of which type of VM I'm actually connecting to. And with that, I'm gonna turn it back to Mark to talk a little bit about what we can do for Max on the client side. That's super cool. That's really nice for the admin. So okay, let's talk about the client aspect of this. So before we get into the Max specific stuff, there are two critical capabilities that we're gonna want from any client OS. The first is ability to do device health at a station. So on Windows, we have two choices here. We have MDM compliance. And if we squint a little bit, we have hybrid Azure AD join, which basically tells us that device is joined to an active directory. There's group policies being applied to it. So it's got some light management there, but we really should be moving more to a device compliance, which actually tells us the health of the device. Now everything else only has one option, which is MDM compliance. There is no other good way for Azure AD to be able to tell that the state of the device is in a good state or not. And this is becoming more and more critical as customers adopt those zero trust policies and principles. And we're starting to see customers move those conditional access policies from saying, you either have to do MFA or come from a compliant device to saying that you have to do MFA from identity perspective and you have to come from a compliant device. And we're starting to include that device identity in that requirement. That's really good from a zero trust perspective. So if you haven't started moving your devices to MDM manage and that type of thing, you really need to start. The next thing here is we wanna get single sign-on as much as we can. I talked about earlier, pumping our users too much is bad from a security perspective. It's bad from a usability perspective. So the user experience and security go hand in hand here. We wanna try to get as much single sign-on for our client devices as we can. All right, so let's talk about now, what are some of the max specific things that we wanna do? So first we're going to wanna enroll our max in an MDM so we can start to get that device compliance. Now a key thing to know here is that some of the single sign-on settings you're going to want to also configure are going to require you to come from an MDM. Now I wanna be clear, there's two separate aspects of this. There's the conditional access when the device compliance piece from MDM and there's the single sign-on aspect which reduces your problems, gets a better end user experience. These are different features, but they are related. So we recommend you deploy both, but you can as an MDM, you can only deploy the device compliance aspect and you build past those conditional access policies and not do single sign-on. You can also just deploy the single sign-on features from ECOS and not do the device compliance if you don't want to, but we really recommend that you do both. Okay, so what are the MDMs we can use to start enrolling in device compliance? So first you can use Intune or if you are not using Intune, you can use an MDM that integrates with Intune so we're able to get that device compliance to Azure AD. They published this list here. The most common ones we see with customers if you're not using Intune is something like Jam Pro or VMware Workspace One. And this is really, really important because this will allow us to pass those device-based conditional access policies. And if we don't do this, remember Azure AD is going to see all of these devices as unmanaged. So if we have stricter conditional access policies being applied, all of our corporate Macs are going to fall into those policies. So we wanna start moving our corporate Macs from unmanaged to managed and managed to compliant. So let's take a look at what that means to get to a compliant device. So if Intune is your MDM, this is pretty straightforward. Intune knows about Azure AD. Azure AD knows about Intune. In Intune, you will configure those device compliance policies that device reported status back up to Intune. And the Intune service will write the is compliant true or false attribute on the device object and Azure AD. Recall earlier, we showed you that sign-in event where Michael was trying to log into the Azure portal and the is compliant flag was set to false that is being controlled via Intune. If Intune is not your MDM provider, so let's say you're using something like Jam Pro or that AirWatch, it's going to follow a very, very similar pattern. You're gonna have your compliance setting set in that MDM provider like Jam Pro and you're gonna have to do a little bit of work to hook it up to that Intune service. It will message over that device compliance to Intune. And then once again, the Intune service will then write to that attribute on the device object is compliant or not. So it's a little bit of extra work, but we feel like this is really, really worth it because it really allows you to pass those conditional access policies. We know that the device is in a healthy state. So we really recommend that you do this. If you're not using Intune, you do the extra work and you connect it up to the Intune service. Okay, so let's now talk about single sign-on. So on the Mac, there are a few different ways you can do single sign-on. If you've been using Macs for a while, you may be familiar with the bind method. So this is where we bind it to an LDAP directory. So commonly this is going to be active directory. And this allows us to get Kerberos tickets and do single sign-on to those Kerberos resources. If this is what you're doing today, beware that Apple's actively killing customers to move away from this. They're telling you to move to the next one, which is the Apple Kerberos SSO extension. It works in a very similar way, but you have to deploy this VNMDM. And again, just a reminder here, this is for Kerberos-based authentication. So this is mostly for those on-prem resources. It's not really designed for those cloud apps. We'll talk about that here in a little bit why that is. But if you do have cloud apps, you're going to want to move to Apple's extensible enterprise SSO framework. I have to say that multiple times during this presentation, I guarantee you I'm going to mess that up in like a words out. So just know if I start stumbling, I'm probably talking about this. But this framework allows IDPs to create a plugin so they can get single sign-in to those modern authentication applications using tokens. And I'll kind of cover that here in a little bit. So what do you need to do this? Well, first of all, you need an IDP vendor. That's us, that's Azure AD. And you need to be able to deploy that via MDM. Okay, so let's talk about here how Kerberos will actually work. So if you have applications that your users on Macs need to access that can do Kerberos, you're going to want to deploy the modern Kerberos SSO extension through your MDM. So we're going to walk through how this works. This is basically just Kerberos. I'm going to play it a little fast and loose because this is not a deep dive into Kerberos, but you guys will kind of know what I'm getting at. So first our user is going to enter their username and password. They have a very strong password. You can see there summer 2022 exclamation point. That is going to get sent over to Active Directory. And if the credentials are valid, we're going to get the Kerberos ticket granting ticket and that's going to get sent back to that device. Now we're going to try to access some sort of Kerberos application. This could be a web application that does integrated windows off. It could be a file share, doesn't really matter. We don't have the right ticket now to get access to that resource. So we're going to need to take that TGT and exchange it for a TGS. So let's walk through what happens there. So the client's going to take that TGT. Everything's valid. It's going to generate that TGS that we need to talk to the application. It gets sent back to the client. The client now sends it to the application and you get single sign on there. So again, this happens all under the covers. This is nothing newer special here. This is just Kerberos, but if you have resources that are still on-prem using Kerberos, you want to deploy the SSO extension and you can validate this is working. If you open your terminal window and use type K list, you can see here we have a Kerb TGT ticket. We can see here we also have a TGS for a file share on a domain controller here. So that's it. This is basic stuff, but let's talk about where this starts to kind of maybe come apart. So Kerberos works really, really well when the resource that we're trying to access, the user that's trying to access it and the Kerberos distribution center, which in our case here is going to be Active Directory, is all on the same corporate network. This doesn't work so well when we're trying to get things over the internet because Kerberos really wasn't designed for this. So let's kind of walk through what would happen instead of having a Kerberos application. We had a SAS app that used Kerberos authentication. So the first thing is we're going to need a way to have the clients talk to that domain controller to get that Kerb TGT and that Kerb TGS. And your domain controllers should not be on the internet. So this is actually not going to work. Now, if you're sitting there thinking to yourself, what are you talking about, Mark? My DCs are on the internet. Stop watching this video. Go start your incident response process because you have much bigger problems in your environment than trying to get these Macs to get single sign-on to some Kerberos applications. For everyone that was nodding along, you kind of see where this is going right. We can't get that TGT, we can't get that TGS. The only way that this would actually work is that the client has a VPN set up and is able to see that line of sight to a domain controller. You would then be able to get the TGT and TGS. The SaaS app would also have to be bound to the domain and things like that. So this is not really going to work for SaaS app. So we need to move to something different. So we're going to start moving our applications here to modern authentication. So things like SAML or even better like OpenID Connect. And the big difference we get here is this is browser based. So we have those website inflows. You may have seen it in your browser here or maybe like the mini browser and something like Outlook. And this gives us a huge advantage of defenders. So we have much more things now we can require to get access to resources. Now we can say things like, in order to get access to this resource, you have to do MFA. So authenticator app, SMS code, we can start to do things like require password list credentials, things like FIDO. We can challenge for smart cards. We can also start proxying that traffic through something like a CASB solution. So when the user starts to download their entire customer list at one in the morning, we can stop that. So it gives us many more things from a protective control, but it also gives us many more things from a detective control because now we have more information. So to give you an example of this, let's say in your environment, you're mostly Windows 10, maybe you have some Windows 11, Mac, some Linux, and now you have somebody that logs in from a Windows 8 client. So that means one or two things is happening. Either that is deep, deep in a drawer somewhere that they pulled out and we have a lot of work to do to get that up to date or that's somebody trying to masquerade as something else to avoid security control. So that is super, super helpful. So as defenders, we wanna start moving our applications to modern authentication as much as we can. Okay, so let's talk about modern authentication. I'm gonna go a little quick through this, but that's okay because actually last year at DefCon Blue Team Village, we did an entire 15 minute talk on modern auth for the security admin. If you go to ak.ms slash BTV, modern auth, we cover how does SAML work, how does OAuth and OpenID connect work, how those flows, why your users probably don't wanna do RLPC flows, why you want OSHA developers to be using, rolling their own libraries, a whole bunch of stuff like that. So that's all covered here, but from a modern auth perspective, we really wanna have one goal, which is to prompt our user one time per device really and really per password change unless something changes. And we're going to do that by using a few different types of tokens. The first type of token that we're going to use is called the primary refresh token. This acts as a token broker on Windows, Mac OS, iOS or Android. It's good for a rolling 14-day window. So as long as your user is continuing to use their device like your other Mac, once every 14 days, the token will continue to get refreshed and extended. And if they go on a long vacation, greater than 14 days, something I think that all us blue teamers deserve, then when they come back, you would probably see that they need to re-authenticate. Now this PRT is going to work with two other types of tokens here, the refresh token and the access token. The refresh token ties a user to an application. So you're gonna have a refresh token for Outlook, you're gonna have a refresh token for OneDrive, and that refresh token is used to get access tokens. So if you attended our talk last year, this is that bearer token which is kind of only referred to. And that means because whoever bears that token has the access to that resource. So these tokens are short-lived, they're usually only good for an hour. This is kind of what Michael talked about from those certificates that we get on the SSH side. Same thing. And when those access tokens expire, the refresh token is used to get another access token. This is where conditional access is evaluated. If they're able to pass those conditional access policies, then we get an additional access token. And that primary refresh token acts as a token broker. So you'll get less prompts if we have a primary refresh token on the device. Okay, so let's talk about now, what do we need to do from a single sign-on perspective to get that enterprise SSO framework? So I messed it up there. You know I'm talking about that last one, the very long one. So what do we need here? So the first thing we're going to need is we're going to need an IDP that supports SAML or OpenID Connect. Azure AD is Microsoft's cloud IDP. We support both of those, but there's lots of other vendors and they should support those protocols too. We're going to need to have our apps that are integrated with that IDP. And we're also going to need to have the IDP vendor create that SSO extension plugin. So that's us, we've actually done that and we'll walk through how that works here in a second. And the other thing is you're going to need to have this deployed via an MDM. And you're going to see why here in a minute, this is very, very powerful capability. So you're going to have to deploy this under an MDM. Okay, so let's talk about here how this actually works under the cover. So we're going to have a few things. We have our app that does modern authentication. So we'll just say exchange online. We're going to have an IDP that is going to issue tokens. This is going to be Azure AD. And then we're going to need to get these tokens from the IDP to that application. So we're going to do this using SSO extension. This comes in the Microsoft company portal. You will have to have the company portal on the device, but your users will not have to interact with it or sign in with it or anything like that if you do not want them to. We know this can be sometimes very sensitive in the Mac admins community about making them use this. You don't have to, but the company portal will need to be on the device. Okay, so once that's on the device, we can figure that via the RMDM. We'll cover that here in a second. We now need to sign in and start getting some of these tokens. So we're going to sign in. We're either going to open an application that knows how to work with this, something like Outlook, maybe we'll open a browser or you can have your users go to the company portal. It doesn't really matter. And now we're going to prompt them for credentials. Because we're doing modern authentication, we can do many rich things like requiring a password authentication using the Authenticare app. We can do MFA with OTP. We can really do whatever we want because we have that browser-based flow. Those credentials are going to get sent over to Azure AD. If everything looks good, we passed conditional access policies. Now we're going to get back that primary refresh token which is going to stay on that device. And this is protected by the Mac key chain. This is how if you're not familiar with Macs, this is how they protect a lot of their sensitive information. Nothing special there. And remember that this PRT is good for a 14-day rolling window, as long as the person is consistently using the Mac once every 14 days, they should not get forced to reauthenticate. They'll continue to be able to use that primary refresh token as the kits extended. All right, now we got to go get an access token. So there's going to be two different ways that we can do this. First, if you have an application that's built using the MSA authentication libraries, this is the Microsoft authentication library. You heard Michael talk about this a little bit before with Azure command line interface. This is an open source library. We make it for things like .NET, Python, Java, Objective-Z, Swift, whatever you want. But most of the Microsoft apps are going to use this, and this knows how to talk to the token broker directly. So let's say here, we have Outlook. It's going to reach out to the SSO extension to ask to get that access token. The refresh token is going to be used to Azure AD to ask for that access token for that resource. Conditional access here is going to be validated. Assuming we pass everything we need to do here, that access token is going to be sent back to the company portal. And the company portal is then going to pass that back to the Authenticator app, and it's going to be used to get access to the resource. So now we'll get our mail and our Outlook profile, all without having to do any additional sign-in prompts because we're able to use that PRT with the SSO extension, which is bundled with the company portal. So that's how it works if you have an application that does MSAL. So again, this is going to be most of the Microsoft apps. You can also do a line of business app with those libraries works just the same. All right, so now let's look at what happens if we don't have that. We have an application that's not built in MSAL. This is where we're going to use the thing called a redirect flow. So the user is going to maybe use Safari. They're going to go to OWA in this case to access that. And that's going to say, hey, you need to get an access token from Azure AD. It's going to tell you, go back to Azure AD, get me that access token. So we're going to redirect over to that. And this part here, the Mac OS network stack is going to intercept that request and redirect it to the SSO extension. So this is built into the OS. This is part of that platform that they made, gets redirected there. And now we're going to use that primary refresh token. It's going to go to Azure AD. We're going to request that access token. We have to pass our conditional access policies. That's going to get returned to the SSO extension, which then gets returned back up the network stack, back to the browser and off to the application here. So now we get access to OWA. So this was able to work. You didn't have to use the MSAL libraries, but beware here, this is a very, very powerful thing because the OS is intercepting that network traffic and sending it off somewhere. So if we misconfigure this, we can break SSO. But if something is malicious here, that's going to send those requests off to that. So we have to be very, very careful. So this is why this has to be deployed via an MDM. It's very, very powerful. So if Intune is your MDM, this is very straightforward. You can select from the SSO app extension type, Microsoft Azure AD. There's a few other things you configure if you want to. If you go to aka.ms slash apple SSO dash Intune, it walks you through the process. But let's say you're not using Intune. Let's say you're using Jamf Pro as your MDM. There's a little more work we need to do. We actually have this documented for you as well. If you go to aka.ms slash apple SSO dash Jamf Pro, there's a sample P list file. We recommend you use that because we've seen customers, sometimes that finger this and it breaks through SSO. So just be careful, it's okay. Follow the recommendation here, follow the configurations and you'll push those P list files to the client and then you'll able to get single sign-on if Jamf Pro is your MDM. So now the last thing here to remember with this is that the company portal is going to be required on the device, but if you follow our recommendations and our configuration, the users will not have to open the company portal at all. I know this seems a little weird, but if you talk to some of your Mac admins, they sometimes can be very, very sensitive about this. So the Mac, the company portal needs to be there, but they actually don't need to log in or interact with it. And remember here that the single sign-on aspect of this and the device compliance are two separate things in the MDM. You do not have to do both. You can do one or the other, but we highly, highly recommend that you do both. And just a tip from us when working with customers, if you need to troubleshoot this, using Safari in private mode works really, really well. So go ahead and use that. You can see we're signing in with Safari, Safari in private mode, you can test whatever you need to test there. All right. So what is some things that we need to be aware of before we deploy this? So first of all, the ASSO extension is still in public preview, but it is fully supported. It's supported just like any other feature in Azure AD that's in public preview. But I know that we have some customers that only will use functionalities if it's in general availability, but this is still in public preview. We have a little things we're trying to button up to get this to GA. Hopefully that comes here soon. As I say in this recording, it's still in public preview. For order for this to work, the applications either need to be built using MSAL or they need to use Apple system frameworks. If you do not, you will not get single sign-on for your applications because the ASSO extension is unaware of them and the applications are unaware of it. So you're not going to get single sign-on for this. The two primary examples we see with customers are Chrome and Firefox because they implement their own network stack. They're not using the system network stack in Mac OS. So as the vendors, we should be asking our app vendors to support these ASSO extensions. And we see this come up in the Mac admin stack a few times where some application doesn't work with this. You should go talk to your vendors, ask them to support this. They should want to support this. It gives it a better end user experience and Apple is only making ASSO extension more important as time goes on. So we really want to ask them to support this. All right, another thing I want to touch on really quickly from a Mac admin perspective is, and as well as iOS perspective, is we want users to use the Authenticator app wherever possible. As I just talked about how the company portal works, acts as that primary refresh token on the device, that token broker, the Authenticator app works the exact same way for iOS and iPad OS devices as well as Android devices. So you want to make sure we get this installed, you will get less prompts just by having the Authenticator app on the device. If you roll out MFA in your environment, maybe many years ago, and we weren't so adamant about what type of MFA factor they could use. So we let people use phone call or text message, that's fine, but we wanted them to use the Authenticator app. If you go to aka.ms slash nudge, after the user complete sign into Azure AD, they will have to go through the Authenticator app registration process. Another thing I want to make sure all its defenders know about is we want to move from the push notification aspect of Authenticator app. So that's what you see there in the upper left. So we get the MFA request, you get the approved deny to move to the number match experience. So there you see in the lower right, the number pops up and you actually have to type the number in to be able to approve that MFA request. This helps tremendously with the MFA hammering technique I talked about a little bit earlier. Also, number matches what's going to be needed to use passwordless. So let's talk about passwordless really, really quick. Passwordless gives you the best user experience combined with the best security. And every time we talk to customers about using passwordless authentication, someone of you will always say, look, we can't use it because I have a main frame still, I have these LDAP applications still, blah, blah, blah, blah. We totally understand you're not expecting you to get rid of your passwords overnight. That's too big of a mountain to climb. But we want you to start looking to use passwords less. So any of the applications that you have integrated with Azure AD, you can use passwordless credentials with. And actually, Michael and I have been completely passwordless on the corporate Mac that we have from MSIT. And we're accessing all those corporate resources completely passwordless since November 2020. Right around Thanksgiving, MSIT admins went in, they scrambled our passwords and we've been passwordless ever since. Because most of the resources that we access can either use Kerberos or they're mostly going to be modern authentication applications so we can do passwordless there. So you may have some applications that are on mainframes and things like that that you can't use passwordless for but you may have a substantial part of your environment that can use passwordless today. So don't discount this, start to move your users to passwordless. So what are the methods you can use? The authentic key app with number match is great. You can also use FIDO2 keys when you see there, we click sign in with Windows Hello or security keys, you'll get prompted to insert that FIDO key. Today this works with Edge and Chrome. You have to do that proof of presence or maybe there's like a biometric there to kind of pen to the key. But this works like said for Edge and Chrome, Safari will be coming in the future. And then finally, another thing I talked about a little bit at the beginning is pass keys. This is a really a cool thing. It's an emerging standard supported by Apple, Microsoft and Google. The pass keys are going to be synced across the same device. So keep an eye on this. This is a really cool thing that is starting to emerge. And with that, I think Michael is going to take over here for the last part around the Linux client. Okay, so we've talked about Mac clients but we should also talk about what capabilities exist for Linux clients. So I want to go back and talk about how we do device OS identification in those conditional access policies. So there's really two ways. If the device is under in-tune management, we have a pretty strong way of determining the device OS because it's had to provide us with a certificate and the MDM has made us aware that this is a Windows device or this is a Mac device. But in other cases, we have to fall back to things like user agent strings to determine what OS we're on. So if I'm using a BSD device, for example, it's going to show up as BSD or if I'm an attacker who wants to spoof my user agent string, I can provide something like I'm not an attacker, I promise. So we can really send anything in the user agent string that we want. This is a modifiable field, obviously. So we need to treat it like it's unverified. So if I'm using device types that Azure AD doesn't explicitly support, I need to make sure that I account for that in a way I configure my conditional access policies. So we don't have support for BSD, for example. So I may want to catch those devices and stop them from being used to access my environment or stop attackers who are doing things like forging their user agent strings, like Mark's example of someone looking like a Windows 8.1 device earlier in the presentation. So if you're using device platform in your conditional access policies, if you followed our best practices in the past, your policies would probably look something like this. You would have at least one policy that's set to include any device platform, which is basically a wildcard. And then on that same policy, you would exclude the device platforms that you explicitly support. And this would typically be Android, iOS, Windows and Mac OS. And then you would block that access. The end result of this policy is that I can have other policies that apply to Android, iOS, Windows or Mac because I have other policies that may do things like require device compliance for those. But if a user shows up with some other user agent string like that BSD device, that Windows 8.1 device, that attacker with the attacker device, I can block that because they'll get caught by the wildcard. So this has always been a best practice. And historically, this is also applied to Linux. It meant that Linux devices got blocked in our environments. So a few months ago, we actually released support for Linux as a device platform in conditional access as well. So this is still using user agent string typically. So we can start to filter out those Linux devices. It's not as high of a security bar as saying requiring device compliance on Linux, but it does give us some flexibility to provide slightly better end user experiences and some level of security for our Linux users. You can see here in the screenshot, it's got a preview tag on it. Since we made this deck, it's actually gone to GA. So anybody who wants to use this feature is fully supported to do so. So some common things that we've seen customers implement using this functionality is requiring MFA on Linux devices, sometimes requiring MFA and specific locations for the Linux devices. So I might say my Windows or Macs can get to resources from anywhere, but if my users on Linux, I want them to have to do an MFA and I want them to have to come from a corporate network. I might also apply risk-based policies to my users on Linux devices and it might apply things like sign-in frequency controls to require users to re-authenticate periodically. As we discussed, prompting is not our favorite, but in some cases, customers have chosen to do this. However, naturally customers ask me, this all sounds good, but when am I gonna get device compliance supported for Linux? So give me a couple of slides and we'll talk about that one as well. So just to reiterate, this is a really common policy set and something that we might recommend for those environments where you do need to support Linux today. So you might have a policy that explicitly includes, excuse me, Windows, Mac OS, iOS and Android and then requires MFA and device compliance. This is a very strong zero trust-oriented policy for your supported platforms. Then you might have another policy that specifically targets Linux that requires MFA and a trusted location. So we can still provide some access for our developers who might be on Linux devices, but we have some compensating security controls since we don't have device compliance. And then finally, you need to have that catch-all policy that grabs everything else. So the condition would be any device other than our supported OSs and then the control would be to block access. But like I said, we really wanna start moving towards device compliance for everything. And so this is something that we're adding. As Mark mentioned earlier, there's really two critical capabilities that we want on any OS. It's not just the device compliance piece. We want SSO and device compliance. So we're working on building this for both, for Linux in addition to all the other platforms. So for the SSO piece, just like we talked about earlier, we wanna have PRTs on Linux that can be used by a broker. So just like on Mac, where Intune Company Portal is the broker, we're building an Intune Company Portal app for Linux that will be able to have a PRT and act as a broker for other applications that wanna get access tokens. This will also make it so that we can support device-based conditional access controls on Linux. So you can start to move eventually from those location-based or risk-based controls for Linux to the device-centric zero-trust policies that we're using on other OSs. So this functionality is in preview today. So we're running a private preview. We'll have more to announce about public preview and GA dates in the future. But just to give you an idea about what the scope of the preview is currently, we're working on securing access to web applications primarily. And this is gonna be done via Microsoft Edge and I'll talk about why that is in a second. So basically this will give you access in your Edge browser to M365 applications, SAS apps, LOB apps, other applications that you integrate with your Azure AD environment. As of today, we're supporting Ubuntu 2004. We are working on support for the next LTS release. We're supporting compliance policies. So from an Intune perspective, we're gonna support applying compliance policies to the Linux devices. There's other types of policy objects in Intune that we're not going to support out of the gate. And then once those devices are enrolled into Intune, we will have things like the compliance state of the device, some very lightweight device inventory and then information about the enrollment success. In the future, we are looking to add additional capabilities like securing access to Azure resources and tools like AZ CLI to get CLI for Azure DevOps. And we're gonna look at adding support for additional distributions. So let's talk about how this is gonna work. This is gonna be very similar to the Mac example. So just like before, we have the Intune company portal app that's installed on the device. This comes along with the Microsoft authentication library. So if you haven't figured it out yet, M-style is really, really important for a lot of these flows. And then we also built a broker. So similar to our Android broker, it's based on Java. So this is a dependency for the Intune company portal. When you install the company portal from our package repo as a dev or in the future, maybe an RPM, it's going to come bundled along with the Java broker. Technically separate components, but their dependencies for each other. Then when I want to initiate enrollment, my user opens the company portal app or is directed to the company portal app by a conditional access policy blocking their access. And the M-cell module is used to present the user with a sign-in screen. So they initiate their sign-in and just like before, they can do a passwordless sign-in or username and password plus MFA. And then M-cell takes those credentials and passes them through the Java broker to Azure AD, where we do a device registration. So we get a device object in Azure AD, and then we can also get a PRT. So we get a PRT and a device certificate in return. At this point, our broker is in a provision state. So now we can start to plug applications into it. The Intune company portal will use tokens acquired by the Java broker to go enroll into Intune at this point. Intune will return the compliance policy. And remember compliance policy is where we're starting. So we're not doing configuration or anything yet. The compliance policy can be for things like requiring password complexity for the account sign-in on the device. We can also require disk encryption. There's some nuances around disk encryption on Linux. It's a little bit trickier than some other OSes. We are looking at future capabilities like maybe requiring TPMs or other compliance controls and some customization. But today, most customers are using password complexity and disk encryption requirements. The Intune company portal returns compliance information about whether or not the device is in a compliance or non-compliance state. And then Intune provides that to Azure AD and that's what we use in conditional access policy evaluation. Next, we might want to actually sign into something. So we open our edge browser and again, M cell is present. And this is why edge is the first application that's able to plug into the Java broker is because M cell is a hard requirement to interface with the Java broker. Anything that's going to interface with the Java broker must use the M cell library. So on macOS or Apple gave us an OS level redirection capability, we don't have something similar on Linux. So on Linux, any app that we want to participate in SSO and use that PRT and pass those conditional access policies needs to have M cell built into it. So we've worked with the edge team to do this on the edge for Linux build. So just like before we have compliance information flowing through to Azure AD. My user might go to an application, request a token and we go to evaluate conditional access. Just like before we need to make sure that the user is in a compliant state, that they've done their MFA, whatever controls are in place. If everything's good, the token is returned to the Java broker. The Java broker returns the token to the application and the application uses the token to access the app. So I can open edge on my device. I can use the PRT to get single sign on into resources and I can satisfy device-based conditional access policies. So this is a new capability that's coming in the future. So something to look forward to. And just remember, like we said earlier, the two things we want on any device are SSO and device compliance and we're looking to deliver that here. So let's recap and talk about what you can go do in your own environment. So the first thing is understand issues with prompting, talk to your identity and access management team if you're not on that team. Understand what your conditional access policies look like. Use those workbooks that we built so that you can evaluate, do I have a prompting problem? Who's it occurring with? What type of devices is it occurring with and what applications is it occurring with? Next, modernize your Linux server access so that they can be treated like any other resource subject to these conditional access zero trust policies. So start playing around and deploying the Linux server sign-in via SSH capability protected by CA. Integrate your client OSs with the cloud to improve user experience and security. On Mac OS, this means get your devices into MDM management that can be via Intune or another third party MDM so that you can use the device state in conditional access and then deploy SSO. So we definitely want customers to be deploying the Azure AD SSO extension. And if you still have those on-prem perverse apps, think about modernizing with Apple's perverse SSO extension as well, move away from that held that bind. And then finally, for your Linux clients, you can start formulating your conditional access policies now to give yourself some support for Linux. So today, like I laid out, you can use Linux as a device platform to provide some compensating controls for your Linux users. And in the future, start preparing for us to have MDM and SSO on Linux just like we have on Mac OS. And with that, thank you. The slides will be available at aka.ms slash AADDTB2022 and please let us know if you have any questions. Thank you.