Setting Up an ASP.NET Project with Organizational Authentication Requires an Organizational Account

I am hearing very positive feedback about the new organizational capabilities in the ASP.NET tools in VS2013 – which makes me very happy But that does not mean that we already achieved perfection, of course. Besides the new features request (do you have any? Write to us!) there are a couple of issues that are being consistently reported. There is one in particular many of you guys are stumbling on, hence I wanted to write about it give you a headsup and to provide something that would turn up in search engines in case you experience the issue and investigate it on the ‘net.

The Issue

When you choose to configure your new ASP.NET project (be it Web Forms, MVC UX or Web API) with organizational identities, the tools/templates can create for you the entry in your Windows Azure AD tenant describing your new project.
In order to do so, the tools invoke the Graph API and use it to write the necessary entities in the directory. That requires the tool to access the Graph as a Global Administrator in the tenant, which in turns mean that the tool need to acquire an access token via an admin user. This is why once you hit “OK” the tool prompts you to authenticate (via ADAL dialog). The authentication phase is what creates the opportunity for the issue to emerge.

The prompt dialog expects you to authenticate with the user of the form <username>@<domain>, where <domain> can be of the form <tenant>.onmicrosoft.com (if you use the default 3-levels domain you get OOB with Windows Azure AD) or <yourcustomdomain> (if you registered a custom domain and you added users under it). As mentioned, that user must be an administrator in the target.

However, the prompt dialog does not enforce the use of an organizational account. In fact, when used to authenticate with the Server Explorer components of the new Windows Azure tools for Visual Studio, the very same dialog can be successfully used with the Microsoft Account (MSA for short) associated with your Windows Azure subscription.
And here, finally, there’s the issue. If you use an MSA when configuring a new ASP.NET project to be secured via Windows Azure AD the operation will fail.
Important: it does not matter if the MSA you are using is listed as an administrator in the directory tenant you are targeting – the sheer fact that an MSA is not an organizational account (in the format described above) will make the operation fail.

This is unfortunately a pretty easy pitfall to encounter, given that many of you got the first Windows Azure AD tenant via automated filling and the MSA associated to your Windows Azure subscription is the default administrator. Furthermore: if you have persistent cookies remembering the MSA you use most often, that user will show up automatically in the dialog (as in the screenshot at the beginning of the post) hence in those cases the issue is just one click away.

The Solution

As of today, the only workaround to this is to use an organizational account when configuring new ASP.NET projects to be secured via AAD.
If you don’t already have an organizational account with the right privileges, you can easily create one. Go to https://manage.windowsazure.com/, click on the the directory icon on the left column, select the tenant you want to use from the tenants list (if you have more than one), click on the Users header and click Add User from the command bar on the bottom of the screen.

Choose “new user in your organization” under Type of User, fill the user name and move to the next screen.

Here it’s important to ensure that the new user is a global administrator, as of today that’s the only role allowed to perform the write operations the tool needs. Be extra careful with that user, as it has complete control over your tenant!

Everything else is pretty much as usual. Once you have the new user up and running (remember that the first time you authenticate as a new user you’ll be forced to change password, I usually prefer to do it in a full size browser rather than in the small ADAL dialog ) you can simply use its credentials when prompted by the tool.

 

There you have it. This is one of those posts that I hope to be able to amend soon, once the underlying limitations will be solved – but for the time being, I hope this will help you to avoid stumbling on the issue or at least offer you a remediation path if you do.