Practical Conditional Access: The Secure Endpoint

today is the final video series of practical conditional access where I give you tangible recommendations on how to use conditional access to secure your environment today's goal is all about device-based access filtering access to appropriate situations when devices are in place because MFA is great and is a fantastic Baseline to help secure your environment but it's just a baseline we need to be doing more than that to help protect our environment from inappropriate access that our users are doing so today I'm going to look at how you can ensure that corporate devices are being used and only access from corporate issued devices because nothing's more terrifying than when you realize that that end user has hit that OneDrive sync button and downloaded everything out of that corporate SharePoint or corporate OneDrive to their personal laptop they mf8 in but now all of your day data that you thought was protected in the cloud is on a unmanaged laptop with who knows what security control is in place so today I'm going to show you a set of CA policies that I call the secure endpoint which is all about filtering access down to corporate issued devices and putting appropriate controls when not accessing those devices so that being said let's get into it and let's look at the secure endpoint so as always I always like to start with a plan when creating our conditional access policies and today's is no different this is the goal of this secure endpoint set of policies the first thing we want to do is we want to take some large swaths and separate out corporate devices versus personal devices there may be some scenarios where you want end users to use some personal devices but we want to put some controls in place on them and this is how we're going to do it we're going to set up a series of policies that are going to help limit those controls and give you some flexibility for some allowances so we're going to separate out some controls that you could combined just to help it make it a little easier for you in the long run to do it this is the set of policies that we're going to do we're going to do one that's called the Baseline for everything and that's your traditional MFA type policy locking it in we're going to do one that blocks Legacy authentication because you know what in reality we shouldn't be using that anymore in most of our environments or it should be very filtered down such as hey there's that one printer in our Network that needs it and only that one printer can do Legacy auth from there we're going to look at building out those device-based policies I like to separate this into three sets of policies one for Windows 10 devices one for Mac OS devices and then one for mobile devices and to help support end users that are working and need to work from a non-corporate issue device we're going to make some allowances for that we're going to give them the ability to access on a non-corporate device but we're going to put some controls in place to limit what they can do on That non-corporation device so we're going to use Defender for cloud apps and we're going to proxy their connection on an unmanaged device and make sure that they are properly controlled in this case what I'm going to do is I'm going to stop them from downloading from that non-corporate issue device so they can't download Excel files they can't download emails if they go to Salesforce they can't download you know a bunch of wrecks from Salesforce or something like that so that's the control that we're going to put in place and then to top it all off we're going to add in and some risk-based MFA just for good measure to make sure that we're not missing anything okay so that's the kind of high level of the policy and of course just like any of our other policies that we've done we also have an Excel spreadsheet to go along with today's uh design and so if you want if you want to look at this more in depth before implementing it you can use this Excel spreadsheet which granny Lily shows all of those options that we're going to configure okay so that's kind of the design idea and we'll get into each of the details of this as we go but I just want to give you the high level of what you're getting yourself into when we start implementing this set of policies so now that we have a decent enough plan let's get into creating our set of policies I do want to say terms and conditions do apply in this video we have some stuff that we're going to be using that's pre-set up I'm not going to go through all of the setup process for everything I'm using in this technology stack but here are the things that we are taking advantage of we have modern authentication enabled we have the combined registration experience enabled we're also going to be looking at for Windows 10 devices hybrid Azure ad join and InTune management devices so you do want your devices in those states to be able to take advantage of this sets of policies for Mac devices we're going to use InTune management as the control mechanism of that so you do want to practice enrolling your devices in tune or just have an understanding that that will be the requirement for Mac devices for mobile devices we're going to take advantage of both MDM and application management policies so we're going to either do a full lockdown of the device or just application controls and I'll show you the difference there of that when we get to that section finally I am going to be using some E5 Technologies the last three set of policies in this uh work set this design use E5 technology so you can take advantage of this still even if you don't have E5 you'll just want to make some tweaks like uh blocking in those scenarios instead of using like a session policy that I'm going to show you and so that is it so let's get started and let's make this set of policies so in my environment I have some existing CA policies so what we're going to do is we want to leave those intact I'm not going to start fresh and clear out everything but to make sure we get a good solid test of this we're going to use a security group to exclude these uh you know to make sure we're getting a clean results when we're doing our testing so let's go ahead and set up a group for this and here we go we're going to make a cloud Security Group um because that way it's a little faster if we need to move people in and out of it uh we can and for the members I'm just going to pre-fulfill in uh one test user in my environment and so I recommend testing on your account but a separate user account and we're set now as part of this I'm going to go ahead and back to all my conditional access policies and I'll exclude that group from being in this set of policies just again so how do I get a clean result I'm only going to do it for one of these policies because this is the one that's really affecting this user but you should do it on any of the other policies exclude this testing group so that we get it nice and clean okay so let's go ahead and then start with policy one so in this case our Baseline for this deployment so let me show you what that's going to look like in here so group selected of course we're going to use that new group that we just did and all Cloud apps is what we're going to Target the design of this policy is a very broad one this is the again Baseline so this ensures that we are affecting all of the accounts that are in use here so I am going to do this set of policies this kind of like my catch-all policy uh you know to to make sure that I am securing this in some way here and so we're going to go ahead and turn this on and the control here is I'm just requiring some control to be put in place on our devices so to access our environment we are going to allow access only if there's multi-factor or one of these device-based access policies so to require a device to be marked as compliant hybrid join approved client or approved app protection policies so to access our environment you're gonna need one of those scenarios in place with this Baseline to continue to access your our environment pretty good there again it's designed to be very broad just to catch a lot of errors I'm not trying to be overly filtered here just because there's things that we don't know there might be a new Gap that comes out with the ca policies so the Baseline is there to just kind of Gap fill everything possibly out there okay so uh that's policy number one policy number two again you know just uh in general always a good idea to do block Legacy auth and so we're going to do the same thing with this one plug that in Target the groups and just like our previous videos where we targeted um you know Legacy auth we're gonna do the same uh control mechanism here so client apps only target these Legacy ones here obviously you do need to test that to make sure that you're not using it um but you know for the most part hopefully you are and we're good to go so that's policy two um if you watched the video I did previously you know it covers uh Legacy off you'll also notice here in my uh design I have a couple of things that I do that I think are helpful you might want to consider it so for any type of group set of policies where it's uh targeted to our group I usually use a squiggly bracket to say hey this is the group that's in targeted and then I use standard brackets for the control mechanism of what it is and then after I do a little bit of a descriptor for it so that helps me high level when I'm looking at your my policies to realize oh this one's blocking this one's requiring MFA or doing something else so you'll notice that as I go through these policies I have it kind of written down that way all right so moving on to the second or the third policy in our group and this is where we get into some of the more interesting controls here so um in this case I am going to be requiring MDM or hybrid join for Windows 10 devices in this case I in changing how I do my access on this I'm going to come in and show you that let's just build it instead of talking about it in this the script here so there we go 10 uh Windows 10 access I guess it could be Windows 11 access now uh probably should update that in this case I come in and select filters on these apps so these are going to be your high risk apps that are needed to support so I'm going to Target office 365. and then usually I'll do things like my VPN all right if I have a Fortinet I'll add that in or a Palo Alto or something like that any of the apps that you are more concerned about I usually put them in here as that targeted set of controls because I want that control in place you might not like that policy that's fine you can switch to all Cloud apps and that can work perfectly fine for you just if you do switch to all apps you need to be concerned about or take care in the other things that can't support the controls that we're going to put in place specifically one common one that you need to do is look at excluding InTune enrollment in your environment right you you can't have a policy in place or it's really easy to design a policy in place that says everything needs to be intuned joined if it's accessing our environment and you have a policy in place that blocks it into an enrollment so if you're going to do all Cloud apps make sure you're testing things like into an enrollment or if you're using jamf make sure you're testing jamp enrollment uh to to make sure you're not blocking that enrollment process otherwise you won't be able to get your devices into the state so that the control can actually work so just a word to the wise there um you know something to think about there in my case again I'm going to Target Office 365 as a good test okay all right so that being said let's go down and look at the rest of our controls we're going to Target windows and we're going to Target the desktop app clients of this so again the idea with this one is I really want to be focused on locking down the devices in my environment to only be accessing from thick client if it's managed by us and so in this case we're going to do that using this control mechanism here so again you'll see this one multiple times I'm going to Target mobile app and desktop clients so that's the Outlook client that's the teams client that's the um you know all the thick clients that Microsoft offers should be in this scope here and that's kind of the goal with this one the Grant in this case we're going to switch it from multi-factor to hybrid Azure ID joined or compliant as in InTune right and so I'm going to do one of these controls if you only have hybrid Azure ID join you might only want to do that one if you do only have you know Azure 80 join and are doing InTune you might only want to do that one and you do need a compliance policy to make this work for your environment whether that be a you know a very scope policy or uh like you know no risk on the device or and a firewalls on or you can just do the check box that says if it's managed by us it's compliant up to you Matt sosman has a great set of videos on this all about designing those ca policies and I'll put a link in the video on that as well okay so that's this that's the third set of policies there fourth one we're going to do is almost identical but in this case we're going to Target the Mac OS a little differently this gives us a little bit more flexibility when we're doing our policy design so if you ever run into a situation where an executive needs to be excluded from this because they have a Mac device you can get a little bit more granular and say oh for that executive you know it's it's this Mac device again same idea I'm going to just Target The Office 365 apps but again make a note of that in your environment you might want to Target more okay same idea device platform is the first thing we're going to look for and I'm going to Target Mac OS client apps and again desktop client and in this case Mac Can't Be hybrid Azure ID joined so we're only going to allow them to access those thick client apps if the device is marked as compliant as an InTune manage I guess it doesn't have to be always InTune managed but it does have to be a MDM connected environment so if you are using jamf AirWatch they have a connector to InTune that can pass device compliance to your endpoints so make sure you're taking advantage of that if you are using some of those third-party mdms they have some really slip connectors that allow you to connect them up and still do device compliance this same way even if you are using AirWatch or whatever solution out there for your Macs okay all right fourth policy down and now let's get into the mobile device policies mobile device is probably the number one area that you're going to want control over when it comes to devices and in my case I'm going to do MDM or ma'am in this policies so here we go let's go and configure that same idea again I'm going to Target these select apps I think you can actually I don't think it will break anything if you did all Cloud apps in this scenario because I think the um authenticator and onboarding app are automatically excluded on mobile devices so that's gonna be helpful a device platform we're going to select all three of the device uh platforms just for full coverage I don't know if anybody's actually using Windows phone out there but it's an option so let's target it with these policies and again oh clicked off and again client apps just going to be doing these three here and in this case for this I'm going to be doing marked as compliant approved client require app protection and I'm going to be doing one of these set of policies um so the reason why I do this is I don't want anyone accessing my environment on a non-controlled device so for me that means it could be InTune compliant and I could have full management of it and that's the MDM part of it or I'm okay with them accessing on a personal device if I don't have full control but I'm only going to allow them to access the using the Outlook thick client on their phone that way I can have an app protection policy that comes in and says no it's only this so if your end users argue with you on hey I want to use the full out Apple Mail app well you have some area of of doing that you can do it but you're going to get full management of the device as in if the end user's phone gets stolen you have the power to wipe out your corporate data same idea with the mam apps built into the mam app is the ability to wipe out just the corporate amount of data that you are that's on their corporate device and so that's a really nice set of controls to put in place a good way to put that in and have management over it and so that's how I have this one designed because I like people using their mobile device if they want to but I want my data controlled by me okay all right so that's the device set of policies so that's the three device policies now we get into the advanced stuff right because all of these policies were targeting essentially the thick client apps what about when people are accessing the web browser people can do a lot through the web browser there's a lot of actions that they can do for there and so we're going to put that in place to manage that web interaction and put some controls in place um and this gives a little bit of flexibility to your end users if they need to work on a mobile device or work from a non-corporate issued device they have some at options but in this case they're going to have some corporate controls on them so some compensating controls to make sure that that access is legitimate again uh so we'll show you what this does as we target this so uh let me put this up make sure I configure it correctly perfect so in this case client apps we're not going to do any device filters or any of those platform filters up there we're going to Simply Target the browser so all browsers and then we're going to come into filters for a device so the advanced filtering option and we're going to exclude specific device properties here so uh is compliant equals true that's the first one I want to do uh device ah trust up all right so um this policy is designed to uh actually you joined uh come in and look at three options for these devices to make sure they're in this trusted device so it basically includes at you know all browser sessions and excludes the following three types of device if the device is compliant that's simply that MDM type control if the device is hybrid Azure idjoined again same idea but it's that hyper join or if the device's Azure adjoined again same controls here and you can put that in place you might want to not do this one if you have full device compliances but for a lot of my environments I'm not fully ready to do device compliance so this is about the same thing um and you know adjust as you go to make it work how you want so that's the filter and how we're going to Target it but the control in this place or what we're going to use is this Advanced option here conditional access app control and we're going to use the built-in block download option for my end users and this does require a little bit of setup which again I'm not going to get into in this policy but this is going to say hey you're accessing from a non-corporate issue device well you can access our environment but we're going to have a compensating control you can't download from our environment you can do everything that you want in the portal you can update Salesforce you can update uh you know email SharePoint lists all those things but if you try to download it's going to be blocked and that's the heart and soul of these set of policies in here and uh what we're going to take advantage of this now that being said because I have introduced some additional you know filters on this I like to augment these policies with some risk-based add-ons to these better policies and these last three policies again I will mention use E5 technology and so if you came into this scenario and said hey I don't have E5 but I I want to still use this all you would do in this policies is switch this from block download to just block access entirely in that scenario and that might be appropriate for you or you know test it out with a few extra licenses of E5 technology see if that really helps your deployment it's really slick and I'll show it to you in the end when this policy is all said and done all right so last one to make add in some wrist-based access policies we're going to use the last two set of policies uh so in this case in a high risk scenario for an end user um holistic health we're going to reset their password and then the the final one is if the end user is risky we're also going to re-up their MFA in this scenario so let's go ahead and add those in real fast and then we'll get into some testing again same idea Target our users and groups all Cloud apps and this is where we're going to do in this case it's a user risk so we're going to Target the user recession section and we're going to only target if the end user is high risk usually this is a almost always uh end user is compromised if I see a user that is in the high-risk State it's like 99 true positive they have been compromised and so let's just tell the system to solve that problem don't wait for a human we're going to require a password change if they're in that state and then to make this happen we are going to make sure that this sign-in frequency with this happens every time this forces the lockout of that token so the end user doesn't you know somehow still get a risk State and then bypass so you need to make sure if you're doing a risk-based policy always set that sign in frequency to every time if you use the policy templates up here it actually does it by default for you so let's now show the sign-in risk policy and again this is my recommendations for this you might need to adjust this to your own risk tolerance for these type of policies but this one's uh worked pretty well for me and all the other deployments I've done uh and so try it out let me know if it works for you so again I'm going to Target all Cloud apps conditions we're not doing user risk we're doing sign-in risk this time so we're going to come into this and I like targeting high and medium sign in Risk and the control in this case is going to be require multi-factor authentication and again same idea we want to Target sign-in frequency and set it to every time and the idea with this one is if something gets weird about their sign-in you know something gets odd well we're going to re-require them to MFA in that scenario maybe there's something that's un trustworthy about their device well we're going to come in and say well I don't care that maybe it's trusted this is an over-the-top policy last two are over the top policies of everything else that we did to help ensure that the trust is there and we're not just you know blindly going into those policies and saying ah it's managed totally fine if they're doing something malicious this is going to come in over the top of that and make sure that we're being secure so there we go folks that is the total design of this policies uh and now we just need to test so let me get my environment pre-set up to do this uh testing uh and let me enroll some devices and show you what the user experience is you can expect in this uh design all right so we switched environments and now we're in an environment that has devices joined to it and so here we can see the end user experience on a corporate issued device that's being managed by us end user can access outlook.offs365.com and can do everything that they normally would be expected to do I can read my emails I can go into it and I can hit you know download I can share things I can do whatever I want in my environment and I'm I'm good to go right I can also come in and hit that wonderful OneDrive sync button and download and connect this up if I'm in teams I get the full Rich experience that I would want to do and it's it is pretty much underwhelming it's exactly what you expect end users to do no controls put in place to block them the nice thing is the end user does get automatically signed in in this case I'm using Windows hello for business in this environment so it's a really clean end-user experience they're on their corporate issue device they're signed in no friction involved here um one note I will mention if you allow Chrome in your environment and you want this to also work for Chrome you need to also come in and enable the Windows 10 extension in your Chrome Library otherwise chrome doesn't understand everything that the device can do so it uses this Windows 10 extension to pass those device-based credentials and those certificates to that device so if you're testing with chrome make sure you do that for the most part pretty easy pretty great now let's look at what happens on a unmanaged device such as this so let's go ahead and sign in with Jeff's credentials and away we go so here I am trying to sign into the thick client of for this user account and in this case right we're going to go ahead and sign in oh I forgot I was testing uh you know passwordless sign in for this user so we're going to go sign in with passwordless authentication uh and away we go so once I get that authenticator app accessed you'll see I'm on the client can't do it can't get here from here and it's going to give the end user options to help remediate you know such as enrolling this device if you want people to self remediate you know you can cut them in and put in controls like you know allowing them to onboard their devices themselves if that's something you want to do if you don't want to do please make sure you put in some MDM controls that control who's allowed to enroll your devices uh and you're good to go from there so that's going to be the same experience for all of the thick clients so Outlook teams uh OneDrive sync SharePoint sync anything that's a thick client that desktop app this is about what should the end user should get in that scenario and then they can't keep accessing it but what about um you know Incognito browsers right what what about not the browser-based session so in this case I'm going to use my uh normal computer and I'll show you what happens in this scenario so if Jeff in this case is trying to access outlook.microsoft.com um what is his experience going to be on that non-managed device and again passwordless authentication really cool capability here to you know quickly allow you to sign in with the authenticator app and number match foreign in this case Jeff is allowed to continue access in that web-based session you saw previously we had that allowance for browser based but we did the session control policy in here and this is what the end user gets instead of just being allowed to access out exchange online or SharePoint or you know whatever app that you want third party is supported you're going to get a redirect here into this you know captured portal so you have that option you can disable that capability for the end user to have that pop-up appear you don't have to have them show that and hit OK every time but if you like that you can keep it and then what's happening is that instead of accessing outlook.office365.com you'll see here in the URL they're accessing outlook.office.com.mcast.ms and that's the defender for Cloud app name it's the formal URLs for it MCAS Microsoft Cloud app security previous name of the product but end user for the most part can do what they need to if I need to respond to this email I can I can open up teams I can open up SharePoint I can do my day-to-day jobs in the cloud version but if I come in here and try to download this file well I'm going to get a block signal as I try to download it it's not allowed right and that is a really nice set of controls that you can put in place for this to make sure that we're limiting that options for those end users or putting in some compensating controls for it and again you know this is all about mitigating those risk scenarios and having that be put in place notes that I did want to give you on this set of policies is that this is a good set of policies but maybe even a great set of policies but it's not a perfect set of policies that you know are going to solve all problems in the world I would love it if you give it a try and see how you feel about it let me know I would love to see you know some results or examples of other orgs using the set of policies I'd use this quite a few times and had great success with it I hope you do too but it has some inherent gaps to it and there's come some that you know I can definitely see in this environment right one of the ones I've been testing and experimenting with is well that's great for all those other device types that we targeted but what about unknown device types so one Gap that you may want to consider in putting in place is something like if it's not a device type we support maybe consider block access to it right so my scenario is you know I am testing on my end you know hey if it's like a Linux device or if it's not one of these managed devices or just an unknown device type maybe I want to consider blocking it and so as you go in and test you might find some gaps like that if you find something that doesn't work with the policy let me know I would love to learn from your scenarios and your gaps that you find in your environment and I hope this helps you get your ca policies into a tighter state of deployment if you have questions I would love to help I hope this video helps you out there please let me know how I can assist and have a great day and stay safe out there

Channel: Doug Does Tech

Views: 785

Keywords: Conditional Access, CA Policy, MFA, Device Based Access, Simple CA Design

Id: r3XVm0OTjR0

Length: 33min 4sec (1984 seconds)

Published: Sun Feb 26 2023