Updated best practices guides, Conditional access policy design and more!
Update March 2023: All of the Best Practices Checklists and Guides have seen major updates since this article was originally posted. You can obtain the Best Practices here.
Updates this month include several revisions to the Azure Active Directory Best Practices checklist, and some updates to the Conditional access policy design, which fixed some typos pointed out to me by readers, and I have adjusted a couple of the policies for better usability/security balance.
Next order of business: I have some other resources to share. The Best Practices are meant to be concise and simple. For a more detailed approach that outlines three different security profiles (Baseline, Standard, and Strict), then you should also check out the Microsoft 365 Consultant’s Bundle, which includes three additional guides and supporting resources (such as scripts, templates, etc.). You can also get the guides independently of each other, but it is cheaper to go with the bundle.
- Guide to Zero Trust and Conditional Access
- Guide to Threat Defense and Microsoft Defender
- Guide to Data Protection and Microsoft Purview
Thanks for supporting my work, and as always, cheers!
Comments (22)
Thanks for the updates.
Is there a way to download guides bullet 2-4 from the top?
Not yet, working on that–for now online only.
Awesome post and material.
/me tips hat off to you sir.
Any change you publish the JSON/PS cmdlets to create the policies (so we dont have to click :-) )
Regards,
RK
Unfortunately Conditional access is not yet exposed via the Graph. Sorta sucks. I think we can vote this feature up though.
Great work, thanks very much!
Thank you so much for your work on this. You definitely provide the most valuable data on the topic for sure.
My question to you is with the new ‘require app protection’ (which FINALLY starts providing more confidence in security for mobile) where would you put LOB apps for iOS/Android? I believe that is going to make us start requiring the apps be wrapped via SDK for OAUTH/CA compatibility. Any app that can’t goes into a new CA only targeted to specific users?
thanks again for everything!
That seems right. Now take WIP for instance: you can have an app that is not “enlightened” and force it to participate in the corporate boundary. But, because the app is not “enlightened” it cannot distinguish between corporate and personal data, the way that enlightened apps like Outlook can hold profiles that are work and profiles that are personal, and draw boundaries between them. That means that when you take a Line of Business app that is non-enlightened and protect it using WIP/MAM, then every bit and byte produced by that app gets encrypted. So there can be some consequences to that which you just need to keep in mind. Data saved from a protected app (even Notepad) will just look like garbledy-gook on any other instance of Notepad, that is outside of your boundary. Ideally, yes the app is wrapped in an SDK so it natively understands the distinction. Not all apps will have that capability today so then it’s just a matter of how you want to protect access to those apps–CA policies, etc.
Very nice work!
Thank you very much! I’ve got a small question regarding the ‘GRANT: Corporal Mobile Device (MDM)’ and the ‘GRANT: Personal Mobile Device’ access policies.
To whom should I assign the MDM policy? Against a device group with all MDM devices?
And the MAM policy to a user group?
Thank you!
Generally, the way I see these baseline policies is as follows: Orgs either supply mobile devices or not. If not, MAM is a great choice. If the org owns the devices, MDM is a better option usually. You can also choose to require everyone to use the approved Microsoft apps and maintain control over the app data, as well as maintain maximum control over the devices.
Great document, its helped me a lot. One question, the place I work, the company gives iPhones to users who want them, but also wants to allow personal Android / iOS devices to people who don’t want to have carry 2 devices. What CA policies would you recommend and targeting who?
What if a person with a corporate iPhone decides to install Outlook on a personal iPad…can a user hit different CA policies?
thanks
Easiest way to deal with this is to have a single CA policy that governs mobile devices, and for the access controls select both Require approved client app, and Require device to be marked as compliant. Then, at the bottom, select the option to only require one of the selected controls. Then, for the corporate owned phones, you would configure Apple Business Manager and automated device enrollment (so when they set up the phones they are auto-enrolled into MDM).
One more question Alex….would it be possible to allow Teams (on Windows and MacOS) but block Outlook clients, allowing only OWA but not the Office app/native Win10 app?
Reason is that we don’t want users to be able to save attachments to their local PCs. If they access via a browser we can stop them downloading email attachments (I believe).
You would need to target only Office 365 Exchange online (instead of all Office 365) when you create your rules that will block the client app access and web downloads on unmanaged devices. Do not target SharePoint Online with those policies and then Teams would function normally.
that’s what I have done but Teams still won’t work. From my testing, it seems as soon as I block EXO, Teams also gets blocked even if it’s on the excluded lists of apps.
Ah yes, I see when you select Exchange Online now, it even warns that it will also impact OneDrive and Teams. So there is some EXO components in the Teams client, it seems. Must just be the calendar… I guess it makes sense even though it would be better if you could separate them. Wonder why OneDrive is impacted…
Hi, I need to support BYOD and Corporate Windows 10 devices. I am using MAM do BYOD is covered nicely, just AD register the device and MAM takes care of the copy/paste etc… With Corporate devices, I would like them all to MDM (with MAM on top). So my question is how would I do that in a CA policy? If I set “Require device to be marked as compliant” OR “Accept ToU”, this works for BYOD, but on a Corporate device that is Not Compliant, the user is able to access corporate data by only needing to accept the ToU. I kind of need to target BYOD against one CA, and the Corporate against a different CA, but there doesn’t seems to be a way to do it….any ideas?
I do not recommend the scenario you describe. Windows devices should be managed when using thick apps that store data locally, in my opinion. Browser access you may protect in other ways, but stuff like OneDrive, Word, Outlook, etc. should be protected by enforcing compliance. For example, you would want to require encryption of the endpoint storage. That is my opinion. Mobile device OS are slightly different, and MAM can be okay on its own, but Windows, I do not trust WIP enough to allow unmanaged device.
thanks for reply, that is kind of what I thought but the company are not willing to spend money to buy everyone a laptop just so they can use Teams (the company don’t really want users accessing Outlook, but as we have found we cannot block EXO without impacting Teams). I guess if they really care about data security there is a cost to pay (laptop), otherwise they risk it and they might end up paying in a different way further down the line.
I usually require device management even if the device is personally owned (when we are talking about Windows devices)–you can create a profile that only protects corporate data basically, so it would not need to be as “heavy handed” as the security profile for a corporate owned device, but you would still want to apply encryption, etc.
would these policies work with Windows Home? as most of the end users will likely have only Home edition.
Home doesn’t have BitLocker so how would I enforce encryption?
Do you have any more docs/details about the type of profile you mentioned.
Thanks again for assisting, very helpful indeed.
Home has never been a supported edition for any type of “business” application. You should always use Pro at a minimum. Pro can be joined to a domain, whether legacy or Azure AD. Home cannot.