One of the biggest problems of our times in IT is to pacify the long-lasting war between security and usability. We all know this picture here below that shows precisely human behavior: people will accept security, when its easy enough. Otherwise they will find their own way around security:

Pic1: The easy way

For me, this leads to the conclusion that a security design of a system is only a good security design (yes, also from security perspective, not only from user perspective!) when it allows people to behave naturally.

Some people in charge of IT security, design secure systems for the sake of security – not thinking about the users. They think it is more important to have a secure design in place and users will somehow handle it. They are not yet aware of the fact that people should be an important part within their designs, since they can circumvent whatever they designed.

Users will always ‘win’. At the end, the often mentioned ‘young talents’ (and I think also the older ones) search other employers, when they are annoyed by too many virtual walls around them.

We somehow must marry security & usability in order to improve both.

One of the best examples of such a marriage is Microsoft’s implementation of multifactor authentication (MFA) in conjunction with conditional access:

When you require MFA for users that join a Windows 10 device to Azure AD:

Pic2: Require MFA for AAD join

Then, when you setup a new device, after you authenticate during OOBE …

Pic3: OOBE prompts for company credentials

… you get prompted for MFA:

Pic4: MFA Prompt

In this scenario, I have disabled Windows Hello for Business (WHfB) to proof something, I will come back on later. Here is where you can enable and disable WHfB:

Pic5: Where you disable WHfB for test purposes

So, after OOBE went through (I did not receive a prompt to setup WHfB during Windows installation as expected), I log in to windows and could open Edge and connect to outlook.office365.com without an MFA prompt:

Pic6: Login to OWA without MFA prompt

The question is why? Lets take a look in the AAD sign-ins:

Pic7: Azure AD Sign-Ins

As we can see, the ‘MFA Result’ states that “MFA requirement (is) satisfied by claim in the token”.

Now lets log-in from a different computer that is not AAD joined (or use a private browser session):

Pic8: MFA prompt from not AAD joined pc (in german)

Here we get a MFA prompt, since Conditional Access is configured as follows:

Pic9: MFA enforced through conditional access

As you can see, under all circumstances, we force MFA here for Exchange (you have to believe me the latter ).

Before we answer the question, why didn’t I get prompted in the first place, when I logged in from a AAD joined computer, we will take a look at a second scenario:

Registered Device (Workplace Joined, local Workgroup):

After the installation of a ‘stand alone Windows 10’, I had to do MFA to connect to OWA (as expected):

Pic10: connect to OWA from stand-alone machine

Pic11: MFA prompt on stand-alone machine

Then I registered the device in AAD:

Pic12: register device in AAD

Again, I had to use MFA in order to register the device:

Pic13: MFA prompt when registering device in AAD

After successfully registering the device (incl. MFA), I was able to access outlook.office365.com without any further MFA prompts.

Again, in the sign-ins, you can see that MFA was satisfied through a claim in the token:

Pic14: MFA requirement satisfied from registered device

So, again, why don’t we see MFA prompts from registered and AAD joined devices? The answer can be found on a Microsoft FAQ page:

Q: Why do some of my users do not get MFA prompts on Azure AD joined devices?

A: If user joins or registers a device with Azure AD using multi-factor auth, the device itself will become a trusted second factor for that particular user. Subsequently, whenever the same user signs in to the device and accesses an application, Azure AD considers the device as a second factor and enables that user to seamlessly access their applications without additional MFA prompts. This behavior is not applicable to any other user signing into that device, so all other users accessing that device would still be prompted with an MFA challenge before accessing applications that require MFA.

(https://docs.microsoft.com/en-us/azure/active-directory/devices/faq)

In addition: Microsoft is considering the device also as a second factor, when enrolling the device (AAD Joined) for Windows Hello for Business (without the MFA requirement during setup!). After WHfB enrollment, you are also not prompted again for MFA furthermore.

Conclusion

Imagine a scenario where a user sits in a train and logs in to Windows in order to read her mail. Let’s ignore WHfB for a moment. She types in her username and her password and does not get prompted for MFA, since she works from a trusted (AAD joined or registered) device. A rude woman behind her watches her when she types in username and password. The rude woman than will be very disappointed at home, when she tries to login to Office 365 with the credentials of her victim and then gets prompted for MFA (especially because she hasn’t seen her victim having to do the same).

The beauty of Microsoft’s implementation of multifactor authentication gets visible, when you get NOT prompted for additional authentication methods. Security can show its strength, when usability does not suffer by it.