I'm diving into some Azure issues and trying to get a solid grasp on how Conditional Access policies work, especially concerning Microsoft Teams. I've got a couple of questions:
1) In Azure, I see various target resources for applying policies, but I'm unclear on which one is specifically for Teams. There's a resource named "Office 365 Exchange Online" that seems exclusive to Outlook mail and calendar. Then there's another one referred to simply as "Office 365". Does that encompass Teams too?
2) How do these policies behave in ambiguous situations? For instance, if I've set a Conditional Access policy for client devices (both computers and mobile) that allows access for a specific user group, what happens if someone tries to access Teams but isn't part of that group? Logic suggests that the policy wouldn't apply to them, but what is the default action in such cases? If access isn't explicitly blocked, is it simply assumed to be granted?
If my assumption is wrong, would I need a separate policy that blocks access for all users except the specific group I want?
And do these Conditional Access policies follow a specific order, similar to firewall rules? Can they be prioritized, or do they all just run cumulatively? I've looked for any way to arrange them but haven't found anything clear yet. I'd appreciate any insights to clarify this for me!
1 Answer
When it comes to Conditional Access, there’s actually no implicit deny. If users aren't covered by a specific policy, they'll generally still be allowed to sign in. So for your question about Microsoft Teams, if a policy isn't targeting a user, they won't be denied access inherently, which means they can still use the app.
Here's something important: Conditional Access policies don't have a hierarchy like firewall rules. They work cumulatively. If multiple policies exist, and any of them denies access, it will prevent the user from signing in, even if another policy would allow it. So if you want to ensure users not in your specific group are blocked, you'd need a separate ‘deny’ policy excluding your allow group.
Thanks for clarifying that! But I’m still a bit puzzled. If there’s no implicit deny, wouldn’t it make sense to just skip creating a policy that allows access? It seems redundant, right? Wouldn’t creating a blanket policy that blocks access for everyone and only excluding certain users offer better security?