Cleaning up the #AzureAD and Microsoft account overlap

[Alex Simons (AZURE)]

First published on CloudBlogs on Sep, 15 2016
Howdy folks, We receive pretty regular feedback about how the split between our cloud identity systems — work/school accounts in Azure Active Directory and personally owned Microsoft accounts (formerly known as "Live ID" accounts) - can make for some pretty confusing user experiences. In particular, we know many of you have pretty strong feelings about this one particular screen:

Some of the recurring feedback we're hearing:

1. Developers want to know how to build apps that support both account types.
2. IT Pro want to know if it's ok to ask employees to create Microsoft accounts using their work email addresses or to bulk provision accounts for them.
3. Users and employees want to know why they have two accounts with the same email address?

All of these issues are the result of Microsoft having two giant cloud scale identity systems built by different parts of the company. Luckily we've combined those teams and together we are hard at work address these issues. Releasing our new combined Microsoft Authenticator apps for iOS and Android back in August was the first major deliverable from those efforts. This post shares the details of the next set of work we've done to address this confusion. It's written by Ariel Gordon, the PM in my team who's driving the work to converge sign-in/sign-up experiences between our two identity systems. As always, we would love to receive any feedback or suggestions you have! Best regards, Alex Simons (Twitter: @Alex_A_Simons ) Director of Program Management Microsoft Identity Division ----------- Hi everyone, If you follow this blog you know we're doing a lot of work behind the scenes to build a converged identity service that will bring together Azure AD and Microsoft account. It's a complex area and lots of work remains to be done. Today I'd like to tell you about some of the steps we've taken this week to address the overlap between our consumer and enterprise identity systems.

What do we mean by overlap?

Many users have two or more accounts with Microsoft. A personally-owned Microsoft account (formerly known as Live ID) used to access Skype, Office or OneDrive; and an organizational account (in Azure AD) used to access business services such as Office 365 or Power BI. We know from our telemetry data that just over 4M people have a personal Microsoft account with a work/school email address as a username. Why? Our research shows four main drivers:

1. Some users prefer to use their work email to sign up for everything, out of convenience. This could be Microsoft apps or services, Amazon, eBay, etc.
2. A handful of Microsoft business services, like MSDN, don't support Azure AD yet and require the use of personal Microsoft accounts
3. IT departments are asking employees to create personal Microsoft accounts with their work email addresses, or in some rare cases bulk-create these accounts for the employees.
4. Some students were given a personal Microsoft account when their school switched from the old live@edu program to Office 365.

And when these users' organization has an Azure AD tenant, they may have two Microsoft identities with the same email address.

Why this is bad

Whatever the cause, having a personal Microsoft account with a work address as a username is fraught with issues for end-users and IT departments alike. For example:

• Users might think that their personal Microsoft account is business-compliant and that they're in compliance when they save business document to their OneDrive
• Users who leave an organization generally lose access to their work email address. When they do, they may not be able to back into their personal Microsoft account if they forget their password. The flip side is that their IT department could reset their password and get into the personal account of former employees.
• IT departments have a false sense of account ownership and security. But users only need to roundtrip a code to their work email address once, and can rename their account at any time in the future.

The situation is particularly confusing for users who have two accounts with the same email address (one in Azure AD & one Microsoft account). For example, they are often confronted with this message:

Based on these learnings we've decided to make an important change to how Microsoft account are created.

Blocking Microsoft account sign-up with work email address

Starting today, we're blocking the ability to create a new personal Microsoft account using a work/school email address, when the email domain is configured in Azure AD. What does this mean? If your organization uses Office 365 or other business services from Microsoft that rely on Azure AD, and if you've added a domain name to your Azure AD tenant, users will no longer be able to create a new personal Microsoft account using an email address in your domain. This sign-up block has been running in limited Preview for a hand full of organizations and is now active for all domains names that are configured (DNS-verified) in Azure AD. No action is necessary to enable the block.

What does experience look like?

If you try to sign up for a Microsoft consumer app with a work or school email address, you'll see the message below.

However, if you try to sign up for a Microsoft app that supports personal and work/school accounts , you should see the message below:

To reiterate, this logic will only trigger for an email address in a domain that's registered in an Azure AD tenant. If you don't get one of the error messages above, it means that the app you're signing up for or the domain name of your email are part of an exception list.

Short term exceptions

Unfortunately, there's still a small number of Microsoft business services that don't support Azure AD. The good news is that we're making good progress. For example, Windows Dev Center finished their integration last winter and now supports both personal Microsoft accounts and Azure AD accounts. We're working with other teams such as MSDN and Brand Central to help them add support for Azure AD. Based on feedback we received during the preview, we will not block the ability to use a work email address to sign up for these business services. This is a short-term compromise that's consistent with our main goal of preventing accidental use of work/school email address to sign up for personal Microsoft account.

What about existing accounts?

The sign-up block described here only prevents the creation of new accounts. It has no impact on users who already have a Microsoft account with a work email address. If you are already in this situation, we've made making it easier to rename a personal Microsoft account. This support article provides simple step-by-step guidance. Renaming your personal Microsoft account means changing the username, and does not impact your work email or how you sign in to business services such as Office 365. It also doesn't impact your personal stuff—it just changes the way you sign in to it. You can use another (personal) email address, get a new @outlook.com email address from Microsoft, or use your phone number as a new username. Note: if your IT department asked you to create a personal Microsoft account with your work/school email, for example to access Microsoft business services like Premier Support, then talk to your admin team before renaming your account.

Conclusion and recommendations

These changes are part of bigger investments we're making to converge our identity systems. We'll share more details later this year. If you're an IT pro , do not bulk create personal Microsoft accounts for your employees. We've helped many customers through hard usability and security problems because they had done this. If you're configuring Windows devices for your employees, you should take advantage of the self-service set up and automatic MDM enrollment we've built into Windows 10 using Azure AD. If you're an IT pro , don't ask your employees to create personal Microsoft accounts with their work email address. It creates confusion about who owns the associated content and resources. We understand that there are still a few Microsoft services that require creating personal accounts with a work email address, and as mentioned above we're working hard to address this and have short-term exceptions in place. If you're an end user who has created a personal Microsoft account using your work email at of convenience, please consider renaming your account . If you're an app developer , you should probably support both personal and work accounts from Microsoft. Check out this post to learn more about the work we're going to converge our identity stack s. As always, keep the feedback coming and let us know about other issues and scenarios you'd like us to address. Thanks Ariel Gordon (Twitter: @askariel ) Principal Program Manager Microsoft Identity Division