Christmas Special: Peace between Security and Usability (by the example of Multifactor Authentication in Azure AD)

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 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 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.


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.


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.

Garage: Azure AD Terms of Use for B2B and AIP

As already mentioned, this blog will have detailed (long) posts and also shorter ones that have a “garage-character” that documents features and solutions I evaluate. This is the first post of this ‘garage’ category.

To be honest, I believe this whole “terms of use” thing was triggered by this guy here. Oliver and myself were in a project at a customer that wanted this functionality that users would have to accept some sort of terms of use before proceeding with a service. (of course we were not the only one requesting this feature, but he was the first chatting about this with the Intune product group). You can like this feature or not and you can also doubt it’s value in a modern IT world, but sometimes it makes things easier (especially in bureaucratic Germany) and you don’t want to fight each fight.

Anyway: Microsoft has started to expand this functionality. You can now set to have users to accept terms of use (TOU) on each device and you can even expire this setting so that they have to re-accept it after a certain period of time.

Then it also gets expanded to other services (currently in public preview):

  • Intune Enrollment
  • B2B Users
  • AIP Documents

Let’s take a closer look on these use cases:

In all cases, you would create a conditional access policy that requests from the given users to accept the terms of use of your company. In this policy, we will combine the requirements for B2B users, Intune enrollment and for AIP users. So we need to select “all guest users” for the B2B scenario and then specific users (Hedi) for the AIP and Intune demo (in real world, you would probably select ‘all users’ here):


Next, you select the AIP cloud app and the Intune enrollment cloud app to indicate that those apps should bring up the terms of use when accessed:


Here you go: on the access controls you then have the control “all users terms of use” (which is the name of the terms of use I created). Select it and enable the policy:


If you now share a document with a guest user via email …


… this guest user gets a prompt to accept the terms of use, when opening the document you shared (as you can see it is adopting to your language :-)):


If you send someone a AIP protected document (you don’t have to send it by mail, the ‘terms of use’ is triggerd when you authenticate against AAD, since the conditional access policy fires then) …


… the recipient then also has to accept the terms of conditions, when opening the document:



The more granular it gets the better. So you prompt your users only to accept the terms of use if it is absolutly necessary without annoying them.