Microsoft provides aset of tools called CA—however, these require configuration and ongoing management, plus you must upgrade to the Azure AD Premium P1 tier to use it.

For some organizations, this may either involve too much effort (perhaps you are a small team) or possibly cost too much.

Because security is so important, Microsoft offers Security Defaults—these are a set of built-in policies than protect your organization against common threats. Essentially, enabling this feature preconfigures your AD tenant with the following:

  • Requires all users to register and use MFA
  • Requires administrators to perform MFA
  • Blocks legacy authentication protocols
  • Protects privileged activities such as accessing the Azure portal

An important note to consider is that Security Defaults is completely free and does NOT require a premium AD license.

It’s also important to understand that because this is a free tier, it’s an all-or-nothing package. It’s also worth noting that the MFA mechanism only works using security codes through a mobile app authenticator (such as Microsoft Authenticator) or a hardware token. In other words, you cannot use the text message or calling features.

Security Defaults is enabled by default on new subscriptions, and therefore you don’t need to do anything. However, for organizations that require more control, you should consider CA.

Understanding and setting up CA

For organizations that want more control over security or that already have an Azure AD Premium P1 or P2 license, CA can provide a much more granular control over security, with better reporting capabilities.

Azure uses several security-based services that can be applied depending on various attributes, known as signals, which are then used to make decisions around which security policies need to be applied.

This process and set of tools are called CA, and this can be accessed in the Azure portal via the AD Security blade.

Tip

For the exam, Azure CA requires an Azure AD Premium P1 license.

Standard signals you can use when making decisions include the following:

  • User or group membership: For example, if users are in a group that will give them access to particularly sensitive systems or high levels of access—that is, an admin group.
  • IP location: For example, when users are signing in from a controlled IP range such as a corporate network, or if users are signing in from a particular geography that has specific local requirements.
  • Device-specific platforms, such as mobile devices, may need different security measures.
  • Application: Similar to groups, specific applications, regardless of role, may need additional protective measures—for example, a payroll application.
  • Real-time risk detection: Azure Identity Protection monitors user activity for “risky” behavior. If triggered, this can force particular policies to be activated, such as a forced password reset.
  • Microsoft Cloud App Security: Enables application sessions to be monitored, which again can trigger policies to be applied.
  • Terms of use: Before accessing your systems, you might need to get consent from users by requesting a terms-of-use policy to be signed. A specific Azure AD policy can be defined, requiring users to sign this before they can sign in.

Once a signal has been matched, various decisions can then be made regarding a user’s access. These include the following:

  • Block Access

–Block the user from proceeding entirely.

  • Grant Access, which is further broken down into the following:

–Require MFA

–Require device compliancy (via device policies)

–Require device to be Hybrid Azure AD-joined

–Requirement an approved client app

–Requirement of an app protection policy—that is, a review