Author: Marius Solbakken

Microsoft is moving from a “force Multi-Factor Authentication for all users” model to a risk based model where users are requested to do Multi-Factor Authentication when their sign-in has a risk assigned to it. This could happen for example by an impossible travel, the user logging in from an IP address which has been in contact with a botnet or other “signals” as Microsoft calls them.

First of all, with AAD Identity Protection, instead of doing manual or scripted assigning of MFA, this is now done with an MFA registration policy. Here is an example on what this can look like:

This will let organizations start with a group of users and expand to more and more users. What will happen is that the user will be prompted to register for MFA when they log on with a browser (or Office with ADAL etc.), but their next logon will not require MFA.

When we look at StrongAuthenticationRequirements of the user, it will be empty, meaning that MFA is not enforced, but the user is still ready to use MFA whenever Azure AD requires it.

Now let us look at the Sign-in risk policy:

Here I have configured the policy to be invoked when the machine learning system in Azure AD find my sign-in a low or medium risk. If a high risk is detected, it is blocked completely.

When I sign in from my regular computer, nothing happens. No MFA; everything is like it has always been. This is perfect, and exactly how this should work. Azure AD detects that everything is safe, no risk at all, so I am not prompted for MFA.

Now, let us try signing in through a RDP session from a computer about 2 hours away by air.

Suddenly my sign-in requires Multi-Factor Authentication, because I made an impossible travel.

So, i decided to figure out how the new PAM feature in MIM worked as a POC for a customer. I configured two forests (red.goodworkaround.com and blue.goodworkaround.com), where RED was the Privileged Access Management forest.

I tested with the Domain Admins group, and it failed with the error message about limitations in sidHistory not allowing this type of group. I already knew this going in, but I figured I wanted to try.

My customer really want to control their Domain Admins group, so we digged further into the new functionality in Windows Server vNext / Threshold. Here there is a new feature which they sometimes call “Foreign Principal Groups” and sometimes “Shadow Groups”. Searching around the web gave very, very few answers, but I found a few interesting sites:

From these sites I was able to deduce that what the MIM PAM feature is actually doing is creating msDS-ShadowPrincipal objects, which are basically groups with an additional attribute msDS-ShadowPrincipalSID. These are created in the “Shadow Principal Configuration” container (which is actually a msDs-ShadowPrincipalContainer) under the Services node in AD Sites and Services.

The following PowerShell however, yielded an error “New-ADObject : The specified method is not supported”:

That returns the following shadow principals (with member as you can see):

And when logging on as this user and running whoami /groups, you will see these as added groups:

As you can imagine, this will also completely remove the requirement to use ADMT (or the library of ADMT) to migrate SIDs for groups

Now, one heads up that I have asked Microsoft is about: Domain Admins does not work over the trust with this method (the SID is probably filtered away on the other side). I will update the article when I have more info.

Update: So, I talked to Mark Wahl about this and it turns out that it is planned a QFE for older Windows Server versions to allow for built-in groups over trusts, but this will probably not happen until Windows Server vNext is released. This means that the PAM feature will not work for built-in groups until this QFE is released.

In an earlier article (source) i demonstrated how to use the Azure AD Graph REST API to do things in Azure AD such as creating users, getting users and license users. This time, we will use the new Repoting API.

What you must first do, is to follow the first steps in this article to create your application. Follow the same steps all the way to “permissions to other applications”. The Reporting API only requires “read directory data”, not “read and write directory data”. As of writing, it actually seems it does not work with “read and write directory data” at all, only if you check “read directory data” does things start to work (you will see an error message like “Unable to check Directory Read access for appId”).

Here is an example of application that gets an oauth token using ADAL and requests a list of all reports:

Here are some further examples on what you can do. Please note that if the reports are empty, you seem to be getting the error “An error occurred while processing this request” for some of the reports.

I am currently testing out Office 2013 with ADAL which is currently in preview. With ADAL, the Office applications support “Modern Authentication” which means web redirects instead of using the old basic authentication and “proxying credentials” through Office 365. I followed the guidance and enabled ADAL. However, despite of using ADFS and having the adfs website added as an “intranett site” in security settings in IE, all I got was forms based authentication and not single sign-on as I expected. I contacted the Microsoft product group and verified that this was indeed supposed to work and was one of the primary use cases.

If you enable the TCOTrace registry key, the %temp%\outlook.exe.txt logfile is created and here I found the following entry:

Now it should work, with ADAL giving you perfect SSO from your Office applications.

Another bug

I also encountered a bug that Microsoft is fixing (also verified after contacting the product group) in the April update. If you find a log line saying CheckADUser: Not AD user found in the log file, even though you are a domain user, you have encountered this bug. To fix, close all Office apps and delete the following registry key below and try again: HKCU\Software\Microsoft\Office\15.0\Common\Identity\SignedOutADUser

After deleting the registry key, ADAL should not try Integrated Windows Authentication instead of Forms Based Authentication.

I am implementing a custom synchronization solution between a member register and Office 365, as well as using a custom identity provider. I therefore need to create, update and delete users in Azure AD using the Graph API, here is how I did it.

Start by downloading the NuGet.exe tool to a folder. I will be using C:\GraphAPI in these examples. If you are not familiar with NuGet, this is a tool for downloading libraries and their dependencies, used a lot by Microsoft. Open a PowerShell and run the following.

After running the commands, the folder where you run nuget.exe from should contain some new folders and some files. The following file should now exist (the version number might be different): C:\GraphAPI\Microsoft.IdentityModel.Clients.ActiveDirectory.2.14.201151115\lib\net45\Microsoft.IdentityModel.Clients.ActiveDirectory.dll.

Now, in order to access the Graph API we need to create an application in the Azure AD that you are accessing. Let us start by creating a brand new Azure AD for demo purposes.

You should end up with an Azure AD like this:

Go to Applications and click “Add an Application”:

Choose “Add an application my organization is developing”:

Give the application a name of your choice and choose “WEB APPLICATION AND/OR WEB API”:

Input a url for your application. This url is never used and does not need to be working or anything, it is just an identifier for your application.

Your new application should display. Go to the configuration tab of the new application.

Scroll down until you find the Client ID. Copy this, we will use this later.

In the Keys section, create a new key and save the application.

As soon as you save the application, the key will appear.This is the only time you can see the key so make sure you copy it.

A little note here. As you can see the max lifetime of a key is 2 years, meaning that your application will stop working after two years. What you should do then is to create a new key, input this key into your application and let the old key expire.

Last thing to configure on the application is permissions. Go down to the “permissions to other applications” section and change the following to “Read and write directory data”. This operation can take a few minutes to complete (even though it already says completed), so you should wait a few minutes before you try the PowerShell examples below.

As a side note, here you can actually also give permissions to other applications such as Exchange Online to query the API there.

You are now finished configuring the application. Now, here is an example PowerShell for you. You need to make sure the path, the client id (which we copied earlier), the key (which we copied earlier) and the tenant name is changed. The rest should be pretty self explanatory.