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:
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!
On joulu 19 2012 11:10 By Lauri KotilainenWith 31 Comments