I will be doing a post on some of the other Azure AD Conditional Access policies i have , however i think deployment of MFA using CA was deserving of a post all of its own, simply due to how important implementing MFA is, and ultimately how simple it can be.
Microsoft internal statistics say that by activating Multi-Factor Authentication (MFA) on user accounts, you eliminate 99.9% of attacks on user identities.
Although such implementation should not be done lightly and will require a lot of planning and testing before just turning on, Azure has the flexibility to do some very rigorous testing before turning on for the whole business or every account on your tenancy including guests.
MFA Policy
Scenario: Create and enable a new MFA policy covering all applications and web content, for a pilot group of users.Security group already exists called MFA Enabled, and has been populated with the test user accounts. The policy should cover the globe unless your on the corporate network.
Planning:
Who will the policy be effect: Security group called MFA Enabled
What applications will be covered by the policy: All applications
Where will the policy take effect: All worldwide locations, Excluding office network
Creating Policy
Under Conditional Access click “New policy”.
Give your new policy a name that makes seance, Staff MFA works for me.
As you can see there are a set of options on the left under two headings, Assignment an Access controls. Basically, Who or what will be effected, and then what action to take.
Lets start with the users and groups, from here you can select, “None”, good option of your building a test policy and to stop any accidental deployment to user(s), other then that its pointless. “All users” will cover all members of staff on your tenancy but also all guests, so be careful when selecting that option as it will effect EVERYONE. The select user and groups is a lot more flexible and where i would start when rolling out to a pilot group and all staff as a whole.
Select the security group or user your deploying this policy to. In this case, i selected my pre-existing security group, MFA Enabled.
Working our way down the list of options, next is what applications are covered. In this scenario its All cloud apps, however you can select specific applications or think in reverse and have all applications covered and then select an exclusion, say you don’t want users having to input MFA when using Adobe Sign.
So we have added the users who will be part of this policy, we have identifies what applications are going to have the policy applied to. Next is the Conditions, such as what device types, locations…
For the first two options User and Sign-in risk i would leave and configure them separately, and in fact, i will create a post just for configuring a Risk Conditional Access policy.
Device state, i would go with the default and cover all devices, you may wish to cherry pick and create slightly different policies based on what OS the user is logging onto.
So per the senario, i have selected Any location, and then under Excluded, i have input our MFA Trusted IP’s.
For thous looking how to create an IP group to use, you will find it under Enterprise applications page and on the left, click Named locations.
From here you can create groups of IP’s for verious policies based on if you want to allow them or deny them.
There is also along the top Configure MFA trusted IPs, from there you have extra options when using the MFA Trusted IP in your policy
As you can see you have several more options if you use the MFA Trusted IP option, such as MFA for federated users… Personaly, i dont like using this option and there is some overlapping that occures with the options, like Method avalable to users. I would personally stick to creating a simply IP range and setting it as a “Trusted location”.
Next is Client apps, for this i have chosen the default of all four options, however depending on other polocies you have setup, or if you wish to create a separate policy covering legacy clients for example, so you can micro manage them separately. You just need to be careful, with any option that your not overlapping and creating a contradiction. Just remember that BLOCKING will always take presidency if you have multiple policies that may apply for a logon.
The next option you might consider, although not in this scenario might be if you have configured and are planning or have rolled out Azure MDM across some, or all of your user devices. If so then based on there Azure profile if they are marked as “Compliant” they could bypass the need for MFA, or even if you just Azure AD joined a device, although doesn’t have all the possible security profiles and compliance settings if your confidant you have a solid computer build in place and maybe using 3rd party controls you could also bypass MFA for any device fully Azure AD joined.
Ok, so the policy conditions have been set up, next is what will happen once the policy it triggered. for the most part when creating a policy certanly an MFA one, you would select Grant access, the only two I have setup for Block access are my; Blocking access from specific locations and User and Sign-in risks.
So for this scenario we want a user to be challenged by a request for multi-factor authentication.
Lastly is sessions, and how often and if the user is asked for MFA. For this i have set it for 14 days before next MFA challenge and always persistent browser session. Meaning, if you have logged into say, Outlook online it will keep that authentication “approved” for the 14 days even if you was to close your browser, meaning a slightly smoother login for the user in between the 14 days. AKA, no MAF challenge.
That’s it.
