AI, Protect Me!

Azure AD Identity Protection (IP) recently got a refresh (in preview). We will have a look into some of the enhancements. But first, I will give you a brief overview of what is it all about:

In a nutshell, IP handles two kind of things:

  • Risky Sign-Ins
    • Is the authentication request really coming from the authorized user?
    • Can be triggered by:
      • Atypical travel (10 PM: Sign-in from New York, 10:30 PM Sign-in from Frankfurt)
      • Anonymous IP Address (e.g. Tor Browser)
      • Unfamiliar Sign-In properties (Takes past sign-ins into consideration and checks for regular used devices, locations and networks to compare it with the current sign-in)
      • Malware linked IP address (Microsoft researches IP addresses that are associated with malware)
  • Risky Users
    • Either a former Sign-In was risky (see above)
    • Or Credentials have been leaked and Microsoft found them on any dark web marketplace or so.

The calculation of the Sign-In and User Risks is done by the help of machine learning.

Keep in mind that all machine learning technologies need learning periods. E.g. ‘Atypical travel’ needs like 14 days or 10 logins to learn the users sign-in behavior. ‘Unfamiliar sign-in’ whereas needs 30 days, during which it is passive. (see here for more info)

You then can create policies based on Risky Sign-Ins or Risky Users. In case of Risky Sign-Ins, you can challenge users for MFA, in case of Risky Users, you can prompt users for a password change (hopefully through SSPR) or you can block access in both cases.

That’s pretty much the basic functionality of Azure AD Identity Protection, except for one thing, we didn’t talk about yet:


This is where the freshness comes in. Microsoft is investing a lot of effort into a clean overview to make it easy for the security administrator to see at one glance what is going on. In order to see how well reporting is in IP, we need to setup the risk policies and then produce some Risky Sign-Ins first.

Setup of Risk Policies


Pic1: IP Policies

Both, User and Sign-in risk policies consist of

  • User Scope (who will be effected by this policy)
  • Conditions (Low, Medium or High Risk)
  • Controls

Pic2: Policy Controls

Now that the policies for Sign-in Risk and User Risk have been setup and assigned to the users, let’s play around with it:

We sign-in to Office 365 via a TOR Browser to anonymize our IP address:


Pic3: Tor Browser

Shortly after we get a new risk as you can see in the brand-new risky users report:


Pic4: Risky users

As you can see, we tried to login to Office 365 and didn’t succeed. The location is also interesting, you can see, the sign-in happened somewhere from Italy (while I am living in Germany) – this is since TOR is proxying all requests to other nodes in other countries.

In the ‘Basic Info’ tab, you get user info from Azure AD. ‘Risk events not linked to a sign-in’ is also interesting: Microsoft is continuously screening leaked credentials on dark places in the internet. So, if your credentials are sold anywhere out there, a risk is listed under ‘Risk events not linked to a sign-in’.

Until now, we do not know about the actual reason for the risk. Let’s click on the risky sign-in to get to the risky sign-in report:


Pic5: Risky sign-ins

Here we have it: ‘Anonymous IP address’ was (as expected) the reason for the risk.

Now, your investigation as a security administrator starts. You will have to check with this user if she used a TOR browser by intention or if somebody else tried to logon with her credentials. After you found out, you can click on ‘confirm compromised’ or ‘confirm safe’. This will a) put the user on high risk if she was really compromised and b) help machine learning, well …, to learn.

Microsoft calls this “Smart Feedback” and this is also brand new (in preview).

This was an easy case (user connected by Tor Browser), as mentioned, your work starts after the risk was detected. You must investigate what’s really going on. So, what you need are really good and clean reports that you can filter, sort and customize. With this refresh of Identity Protection, the Risk reports have been enhanced a lot to support you in your daily job.

A word of caution: to test the policies easily, I set the condition to “low risk and above” and the scope to my “all users” group. After hitting OK, I immediately received this one here below and couldn’t work with the portal anymore. I then had to re-authenticate and … was prompted to authenticate and then to change my admin password. As you can see, those risk policies are really working


Pic6: I am out!

So, be sure whom you assign those policies and have a Break-Glass Admin Account (thankfully I had) that you always exclude from all policies (also in conditional access).

But that’s not all

This risk report data is also available via Graph API. Let’s have a look how that is working. We will use Graph Explorer to show which information we can get also programmatically:

You might have to give yourself the appropriate permission, if you see this:


You will need:


Make sure you are logged in to graph explorer and use the new beta API, then try for example “identityRiskEvents”:


Pic7: Graph explorer

When I do that, I see the same sign-in risk we saw earlier in the GUI:


Pic8: Graph response

As you can see, you even get some extra information, like the geographical data of the IP location.

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.

100% Cloud will never happen!

I like the idea of starting a brand-new blog site by the name of “Empty Datacenter – 100% Cloud” and then writing the first article, indicating that this will never happen.

But this is exactly what happens during the ‘cloud familiarization period’. The WHAT? Exactly.

During my journey from an on-premises driven consultant for Exchange & Active Directory Enterprise Infrastructures to a Cloud Architect focusing on Office 365, Azure AD and Enterprise Mobility, I noticed by my own thoughts and behaviors and by those of my colleagues and customers that “being cloud minded” is not of a binary category.

Most people understand a few core principles of what it means to be 100% cloud minded. So, in my experience, the 100% cloud approach gets deeper and deeper into one’s mind over time.

People (we all) need time to get used to new environments, paradigms and so on. This is what I call the ‘cloud familiarization period’ (and to be honest, I think this period never ends).

In the beginning of this period, it can happen, that an IT colleague is totally familiar with the benefits of Office 365, completely convinced to move all company mailboxes to the cloud and believes in the future of Microsoft Teams. But if you dig deeper, this IT guy does not really believe in the near end of ‘the fileserver’. He neither believes in empty datacenter halls because ‘our SAP* servers will never go to the cloud during my career’ (* it does not have to be SAP, but you get the idea).

So, in my opinion, when talking about 100% cloud, you should have an empty datacenter as a vision in mind. That means, after moving all the Microsoft Infrastructure to the cloud, your IT infrastructure could look like this:



The main message of this picture is: move as much to the cloud as possible now and consider the rest (your on-prem DC) also as a cloud. But let’s proceed step by step.

First, to move the “basic” Microsoft environment means to move:

Mail & File



  • Local Mail to Exchange Online
    • Considered as a no-brainer
  • User file servers to ‘SharePoint’
    • With the term “user file servers”, I want to exclude data that is still processed from local apps and so on. To move everything from local fileservers (and SharePoint servers) to OneDrive, Teams, SharePoint Online (and Groups) is technically not hard, but you must work hard regarding change management and user adoption.
  • Comment on Teams
    • As we all know, Teams is the successor of Skype for Business. It is quite easy to use Teams for chat, group-chat, audio calls and conferences. It’s getting a bit harder, if you also move the telephony services to Teams, at least in an enterprise environment. Using which feature by which tool must be well thought through.

The Client

Then, following up with the 100% cloud approach, you should move your clients to the cloud:



So, how does this look like from a user perspective? The user receives a new laptop at his desk in the office or at home or where ever you want. He unpacks and starts it and runs into the Out-of-box-experience (OOBE). He types in Username & Password and joins automatically the AAD. The device gets then enrolled into Intune and policy settings are then applied. Intune also installs all user-specific software on the box and after a while, the user can log on to his new machine without IT even touched it. And the best: no on-premises management service was involved. All client management (AAD & Intune etc.) itself is evergreen.

This client loves the freedom of the internet, calls the cloud his home and hates boundaries like Proxy Servers and Firewalls.

Users, on the other hand, love this new client, since it supports collaboration instead of preventing it.

For this new freedom, we need new security concepts. Security concepts that have the global collaboration needs of the users in mind, that also let the users use the tools they need and give them more self-services possibilities to enable them to act fast. With those new security approaches, we also get the chance to improve the overall security of our systems, because we can leverage intelligent cloud solutions that “know” not only our system, but many Microsoft environments from customers all over the world.

The following picture describes the difference between the old and the new security approach:



So, in the new world, we must go away from the perimeter approach towards an entity security approach. Considering certain networks as trust worthier than others does not work in a mobile world where computers bypass the company borders in the pockets of their employees.

When we start to protect all entities in question (Identity, Device, Services, Documents), than we gain both: more security and more mobility.

Microsoft offers here an “defense-in-depth product catalogue”, all hosted or connected in/to the cloud:

  • Identity Security
    • MFA
    • Identity Protection
    • Privileged Identity Management
    • RBAC
    • Monitoring/Auditing/Reporting
  • Device Security
    • Secure Boot & Integrity
    • Bitlocker Harddisk encryption
    • Evergreen patching
    • Hello for Business & Passwordless Sign-Ins
    • Endpoint Protection with Windows Defender
    • Advanced Threat Protection
    • Credential & Exploit Guard
  • Service Security
    • Conditional Access & Compliance
    • Device Health Attestation
  • Document Security
    • Azure Information Protection
    • DLP

By now, we were talking about the “company managed (Win 10) client”. In a 100% cloud approach, we also have to think about connecting other devices, mobile devices and private computers (Windows, Mac & maybe even Linux).

In the upcoming posts we will hear more about the mentioned security solutions and the possibilities for mobile and private devices and we dig deeper into them.

The last boxes in the basement

Now, let’s talk about the apps and services we avoided to talk about until now. There are hundreds of applications in your server rooms besides “Mail”, ” File” and “Collaboration/Communication” services.

A 100% Cloud approach means to move them to the cloud. It’s as simple as that.

This is where the “never gonna happen” mantra starts. And therefore, you must keep your clear vision of a cloud-only IT AND be as pragmatic as necessary. Start a project that goes through all your applications and checks them against a priority list like this one:

  • Do we still need this? (I have seen companies that saved a lot of money by asking this simple question)
  • Is there a SaaS service available for this application?
  • Can we move it to Azure (IaaS)?
  • Can we easily ‘publish’ it by Web Application Proxy? (since it speaks http)
  • Do we have to App-vpn to it?

Taking this list and going through all the apps in the basement, we sometimes call “app feng-shui”.

This list is a priority list from top to bottom and it is not complete, but you can imagine what to do here. The benchmark here is “user experience”. In a 100% cloud approach, you should provide the best possible user experience, regardless of the location of the device connecting to your services, no matter where servers reside, it runs on.

You may have recognized that the ‘last boxes in the basement’ struggle against the 100% cloud approach. But this is not so important. And it should not lead you to the conclusion not to start with it at all!

In fact, this is the point! You must do here, what you can to get as close to the 100% as you could. In addition to “app feng-shui” you should also plan on how to proceed with those apps in one year and later. Maybe you get new possibilities then, since a SaaS version is already under development.


So, that’s it. Your datacenter is (nearly) empty now. As mentioned before, we will dig deeper into many areas mentioned in this blog post in upcoming posts.

I would like to end this post with a list of things you can achieve for you and your company by going 100% cloud:

  • Mobility: from each device and location
  • Evergreen: always up-to-date, for security and for the latest tools and features
  • Collaboration: enable your users to collaborate easily with whom they want without having to use Shadow IT tools
  • Self-services: freedom and agility to the user
  • State of the art security: prepared for modern threats by leveraging cloud intelligence
  • Knowledge sharing: users will be able to share knowledge with community tools.

Is all this easy to achieve? No. Does your company need to change in every cell of its ‘body’? Yes, but I believe it is worth it.

I am really looking forward providing articles here that help you to empty your datacenters and taking full advantage of the 100% cloud approach.