Happy new year everyone! I hope you all had a wonderful time with friends and family. I’m kicking off the new year by continuing my series of do’s and don’ts.

DO:

Structure your Conditional Access rules

Entra ID Conditional Access (CA) is one of the primary tools of identity security where all signals from every login is gathered and evaluated before access is given. CA rules can evaluate a large number of signals in the evaluation (user, groups, location, device, status, etc, etc) so the CA rule set can quickly become very large and complex. In addition CA rules doesn’t have any hierarchy or description field beyond the name. Therefore troubleshooting CA rules is often a complex task involving reading sign-in logs, and which CA rules a login is affected by can be very difficult to predict.

What goes a long way, is to create a naming standard for your CA rules to remove some of its complexity. Here each CA rule has a dedicated purpose described in the name, and every rule have a unique number which makes it much easier to identify. Keep in mind that you should always have catch-all rules to ensure basic MFA requirements.

This is the structure I like to use:

The basic idea is “CAxx” rules are the main catch-all rules and the sub rules (ie “CAxx-yy”) are either exceptions or additions to the main rule in that category. By category I mean  CA01 = admin accounts, CA02 = authentication/protocols, CA03 = user accounts, etc etc.

So a quick example to get my point across: For example “CA03”. Here we have:

• A main rule to ensure everyone is hit with a rule that requires MFA (CA03 – Users – Req MFA All). – This is the catch-all rule for all users accounts.
• An additional rule (also applies to user accounts as it belongs to the same category) to block logins from outside Norway (CA03-01 – Users – Block outside Norway).
  • If I want to create an exception from this rule and allow a subset of users to log on from Denmark for example, it would be named “CA03-01-01 – Users – Allow login from Denmark“. The “CA03-01-01” indicates it’s an exception from the “CA03-01” rule.
• An additional rule where specific apps are determined to be critical, and users of those apps need stronger MFA methods like FIDO2 keys or similar in order to be granted access (CA03-02 – Users – FIDO2 for critical apps).

This is of course my suggestion and feel free to adopt it with your own customization if you want. Microsoft also has their own recommended framework for naming conventions in CA rules, though those might be overkill unless you have a very large environment. As always in IT, one size does not fit all, so I suggest you always evaluate your own need for complexity in your naming convention. Link.

DON’T:

Combine admin accounts in cloud and on-premises

This list is shorter and quite simple, but this is also something I see way too often.

1. Admin accounts in on-premises AD (aka Windows AD) should never be synchronized to Entra ID – if your on-premises admin is compromised you don’t want to automatically compromise the tenant as well.
2. Admin accounts in Entra ID should always be a cloud-only account – removes dependencies on sync and compromised on-prem accounts.
3. Admin accounts in Entra ID should always use the initial domain (XXXX.onmicrosoft.com) in its UPN – remove dependency on domain name.