Software Engineering

Create conditional access base policies for a Microsoft Entra ID tenant

April 2, 2024 06:37

This article shows some of the base conditional access policies which can be implemented for all Microsoft Entra ID tenants. Phishing resistant authentication should be required for all administration flows and some other user policies like sign-in risk MFA or terms of conditions. I recommend these base policies when implementing an Microsoft Entra ID tenant using a P2 license.

Disable security defaults

The security defaults are a good basic setup, but when a P2 license is used, conditional access policies can be applied and the tenant can be setup to force things like phishing resistant authentication.

Disable on the tenant in the “your-tenant” | Overview | Properties

All the security defaults are disabled and good conditional access policies are now required.

Activate conditional access policies

There are many conditional access policies. These are applied and different depending on the tenant requirements. The following base policies make sense in all tenants:

Force MFA conditional access policy (All users)
Require Terms of Use policy
Block legacy authentication (All users)
Enable Sign-in risk policy (All users)
Require phishing resistant authentication for admins
Enable User risk policy (All users)

A single break glass account is excluded from these policies and this account should never be used except in an emergency. Alerts are required on this account.

1. Force MFA conditional access policy

Multi-factor authentication can be forced for all users except the break glass account. This uses the “Require authentication strength” policy and the tenant can set the default strength as required.

Add the following policy ( Force MFA All users except break glass account )

2. Require Terms of Use policy

Add a Require Terms of Use for app ( App Require Terms of Use ) policy. You can use Microsoft Entra ID to force the users of the tenant and all the client apps to except the terms of conditions required by the tenant and the hosted applications.

The terms of use needs to be added to the Azure tenant:

https://learn.microsoft.com/en-us/entra/identity/conditional-access/terms-of-use

The policy can be created for the terms of use. See the Microsoft docs for details.

https://learn.microsoft.com/en-us/entra/identity/conditional-access/require-tou

3. Block legacy authentication

Block the legacy authentication in the tenant. The Client apps should select only the Exchange ActiveSync clients and Other clients and the access must be blocked.

https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-conditional-access-policy-block-legacy

4. Enable Sign-in risk policy

You can activate the sign-in risk and choose how strict. If a risky sign-in is detected, the user is required to do a multi-factor authentication. This requires a P2 license for user accounts. See the Microsoft docs for details:

https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-configure-risk-policies

5. Require phishing resistant authentication for admins

Phishing resistant MFA should be applied to app administrator workloads. This can be created from the Azure provided template.

https://learn.microsoft.com/en-us/entra/identity/conditional-access/how-to-policy-phish-resistant-admin-mfa

The policy is applied to the Azure roles:

Global Administrator
Application Administrator
Authentication Administrator
Billing Administrator
Cloud Application Administrator
Conditional Access Administrator
Exchange Administrator
Helpdesk Administrator
Password Administrator
Privileged Authentication Administrator
Privileged Role Administrator
Security Administrator
SharePoint Administrator
User Administrator

When a user account has one of the Azure admin roles, phishing resistant authentication is required for access to the tenant.

6. Enable User risk policy (All users)

If a user account has a high or medium level possibility that it has been compromised, the user is required to do a multi-factor authentication. Why not Self-service password reset (SSPR)? I don’t really see the point of this if you are using passwordless sign-ins. Without a SSPR for a user with a password, the user-risk is not reset and the user will be forced to MFA again. I am not sure how this policy works with passwordless or phishing resistant authentication flows. This policy only makes sense with the high threat category and the block user. This requires a P2 license for users accounts.

Summary

These are the base policies and further policies can be added depending on the tenant requirements. Some session based controls would normally make sense as well.

Notes

The examples of the continuous access policies are shown and set up using the Azure portal. This would be way better as a terraform script and a fully automated set up using something like Azure DevOps or Github actions.

Software Engineering

Create conditional access base policies for a Microsoft Entra ID tenant

Disable security defaults