Azure Active Directory

Microsoft really knows how to get me frustrated

by

While I was working on a walkthrough on authentication and authorization I decided to use the Microsoft Graph API as an example. In this example I wanted to use application permissions to list all users. Nothing special. Configured my application, wrote some code but… got an error message telling me that my application does not have the required permissions to read all users. So let’s go back to Azure and verify the permissions.

Azure Active Directory Permission Assignment
Azure Active Directory Permission Assignment

Looks pretty good. I actually do have some experience with authentication and authorization – which is why I’m writing this walkthough – but I do not have a clue about what I did wrong. No warning messages here. OK then, let’s search… and GitHub?! contains the answer. It appears that Microsoft decided that besides the permissions given by the administrator, the service principal also needs to be a “Company Administrator” (which you cannot configure from the UI) as a security measure. So the UI is just complete bogus without that role being assigned first. And another hour of my time is down the drain…

UPDATE:
To be consistent with not being consistent Microsoft does allow you to fetch all users if you use the BETA API (https://graph.microsoft.com/beta/users) as security in a public BETA – that is automatically enabled for everyone – apparently is not that important.

ADAL JS and zones in IE and Edge

by

Active Directory Authentication Library for JavaScript (ADAL JS) is actually a very nice library to take care of your authentication against Azure Active Directory. Unfortunately the library doesn’t work with IE or Edge as soon as the web application that is using the ADAL JS library is in a different security zone than “https://login.microsoftonline.com”. The reason for this is that IE and Edge don’t allow cookie sharing between zones. Since “https://login.microsoftonline.com” should not reside in any security zone this means that your application cannot be in any zone either. Now why is this such a huge problem?

Most of the applications you register in Azure Active Directory will in fact be internal applications. And most of these applications will reside in the “Local intranet” zone or “Trusted sites” zone. And exactly those applications won’t work with the ADAL JS library if the client is using IE or Edge, unless you add “https://login.microsoftonline.com” to that same zone.

Adding “https://login.microsoftonline.com” to a specific zone, might solve you issue for one application, but if you have applications in both the “Local intranet” zone and the “Trusted sites” zone, you are out of luck as sites (including “https://login.microsoftonline.com”) cannot be part of multiple zones.

In each and every other browser you will not encounter any of these issues as the don’t have this cookie sharing limitation.

I wonder if when they will solve this issue, because the advice to just remove “protected mode” for the “Internet zone” on the ADAL JS GitHub site, makes me shiver when I realize that these same people wrote this authentication library.