Windows Azure Active Directory: Using the Graph API with an Office 365 Tenant

In a previous post I wrote about querying the Graph API for the group memberships of a WAAD user. In yet another post, I detailed setting up a WAAD tenant, but I also noted that you don’t have to do that if you’ve already got an Office 365 subscription, and would prefer to use that instead.

While that statement is technically true, the story is far from complete. As commenter Nick Locke points out, my instructions for using the Graph API don’t work for Office 365 tenants: the code throws an exception while trying to get the authorization token for the request.

After a bit of trial and error, I managed to figure out a fix.

Once again, open up the Microsoft Online Services Module for Windows PowerShell. Run Import-Module MSOnlineExtended -Force to load the module, use Connect-MsolService with admin credentials to establish the connection, and type in:

$adPrincipal = Get-MsolServicePrincipal -AppPrincipalId 00000002-0000-0000-c000-000000000000
$adPrincipal.ServicePrincipalNames

If your Office 365 setup is like ours, the result will look a lot like this:

00000002-0000-0000-c000-000000000000
AzureActiveDirectory/graph.windows.net
AzureActiveDirectory/directory_s5.windows.net
AzureActiveDirectory/directory_s4.windows.net
AzureActiveDirectory/directory_s3.windows.net
AzureActiveDirectory/directory_s2.windows.net
AzureActiveDirectory/directory_s1.windows.net
AzureActiveDirectory/directory.windows.net
AzureActiveDirectory/Directoryapi.microsoftonline.com

Looking at this list, it occurred to me that the problem might be related to the fact that we construct Realm Names for our application using the GUID 00000002-0000-0000-c000-000000000000 and the domain name graph.windows.net — the result looking like: 00000002-0000-0000-c000-000000000000/graph.windows.net@your-app-principal-id. So I figured I’d change my app to use the string AzureActiveDirectory instead of the GUID, and wouldn’t you know it, I got past the authorization token error. Only now I ended up with another error: validating the token didn’t work.

After a bit of head-scratching and web-searching, I thought I had it backwards: it wasn’t my app that was misconfigured, it was the Office 365 tenant. Suppose that the Graph API service actually identifies itself as 00000002-0000-0000-c000-000000000000/graph.windows.net and not AzureActiveDirectory/graph.windows.net, and that’s why things are failing.

I repeated the commands above in a MSOL PowerShell session that was connected to the WAAD domain I created before, and noted that indeed, the Service Principal Names for Microsoft.Azure.ActiveDirectory were otherwise identical, but AzureActiveDirectory was replaced by 00000002-0000-0000-c000-000000000000. So I cooked up this PowerShell bit:

I then ran it against the Office 365 MSOL PowerShell session and tried again. And wouldn’t you know, it worked!

Apparently, we’re not the only ones with this problem, so let’s hope this helps save someone else the trouble!

3 comments

  • Lauri, Just to repeat – many thanks for your help with this earlier, it was much appreciated.Cheers,Nick

  • Hi,

    Excellent blog posts, thank you very much.

    I am in the process of setting up a WAAD principle name registration on an existing O365.
    What I don’t understand is which of the ‘$adPrincipal.ServicePrincipalNames.Add’ instructions are part of the sample app and which you need to get it working? One might think that the ‘graph.windows.net’ registration is needed to be able to work with the graph API?

    Could you elaborate on that?

    Also, would it be a good idea to register each application in the different environments (develop, test, acceptance and production) separately?

    Thanx,
    Marc Jacobi

  • Marc,

    Every one of the Add calls adds a real principal name of a Graph API server. None of that was meant as example data; in my understanding at least Nick was able to run that code verbatim and make things work.

    However, before you do any of this, I suggest you first try the query example at http://blog.rytmis.net/2012/12/windows-azure-active-directory-querying.html and see if it works as is. This here is a fix to a problem that in my opinion shouldn’t occur in the first place.

Leave a Reply to Lauri Kotilainen Cancel reply

Your email address will not be published. Required fields are marked *