I recently spent some time untangling my logins for a variety of apps that I use and thought I'd share what I learned. I know that it can be very confusing from an end-user's perspective and personally, I've come to hate this screen. I was never 100% sure how to log in. In every case, I log in with my work email address, but sometimes I need to pick a “Work or school account” and other times a “Personal account,” and after I get that right, there are at least three different passwords that I have to choose from. Maybe what I found out will make things clearer for you. This is not a how-to for Azure Active Directory (AAD) developers; it's a how-to-use for AAD users.
First, what's an AAD? Like an on-premises Active Directory for a domain, an AAD is a list of logins that an app can validate against to see if someone is authorized to access the site or app. For the remainder of this article, just consider the term AAD as being synonymous with “a list of logins.”
Where do AADs come from? Every Azure account that's created contains at least one AAD and perhaps more. That's a lot of AADs.
If AAD only offered “Work or school” accounts, things would be simple. Each user account would follow the pattern username@unique-add-name.xxx and each account would have its own password. The user name and password would be created and exist in that AAD. For example, if I have an Azure account where I work at Awesome Company, that Azure account would have a default AAD and that AAD might be configured with the unique-add-name of awesomeco.onmicrosoft.com. I could then create a user name in the AAD like this: myeager@awesomeco.onmicrosoft.com and the password might be Secr3t. Now Awesome Co can write and publish Web, mobile, desktop, and other applications and configure those apps to look at that AAD for authentication. I could then log into one of those apps as myeager@awesomeco.onmicrosoft.com / Secr3t. It would be simple.
So let's throw the first monkey wrench in the works. The unique-add-name.xxx gets created when an Azure account is set up. However… If I own a domain name such as AwesomeCo.com, I can “associate” that domain name with my AAD. Now, instead of myeager@awesomeco.onmicrosoft.com, I can create the user name myeager@awesomeco.com in the AAD. When I log in to one of the apps, everything works just as it did before except that I now use myeager@awesomeco.com / Secr3t to log in. What can make this confusing is that this may also happen to be my email address. That's just a coincidence and one has nothing to do with the other.
Let's throw in monkey wrench number two. I might have a second Azure account, a personal Azure account. Its default AAD might have the unique-add-name mikeyeager.onmicrosoft.com. So there, I can create user accounts like myeager@mikeyeager.onmicrosoft.com with a password of C0vert. Now, suppose I associate my company's domain with this AAD as well. I can create a user named myeager@awesomeco.com in this AAD! This is a completely different user account, with a different password in a completely different AAD than the one I use to log into the apps I created at work, even though the user name is the same. Now assume that I create a personal Web page in my personal Azure account. I can set the website up to authenticate against my personal AAD. Now myeager@awesomeco.com / Secr3t is an account in my work AAD that I use to log into my work apps. And myeager@awesomeco.com / C0vert is a different account in my personal AAD that I use to log into my personal Web page. The myeager@awesomeco.com address also happens to be my company email address and my company email server needs a different password to get my email. OK, I can live with that, but it's getting complicated.
Monkey wrench number three. Let's assume that my company wants to get rid of our email server and switch to a hosted Office 365 system. Microsoft has set up their own AAD for Office 365. Office 365 authenticates against this AAD, owned by Microsoft. Microsoft recommends that we sync our on-premises Windows domain Active Directory with this AAD in order to make the accounts easy to maintain. My email address myeager@awesomeco.com is now going to get pushed into Microsoft's AAD for O365 and I'm going to have to set up a password in that AAD. I set the password to P@ssw0rd. Now I log into Office 365 to get my email as myeager@awesomeco.com / P@ssw0rd.
Monkey wrench number four. I have a Microsoft ID that I set up years ago when it was still called Passport, way before it was called Live ID. It's my personal Microsoft ID, not set up through my company's IT department, but guess what my user name is? It's myeager@awesomeco.com and my password is Ncript. When I created both my work and personal Azure accounts (and signed up for a few third party apps), I used my Microsoft ID. When I log into my work Azure account, my login is checked against one of Microsoft's AADs. When I log into my personal Azure account, my login is checked against one of Microsoft's AADs. When I log into the third-party apps, my login is checked against their AADs. So myeager@awesomeco.com exists in all of those AADs. But because I'm using my Microsoft ID, those AADs don't store any passwords; they pass the authentication through to a set of Microsoft ID authentication servers. Each AAD holds a record of my user name, but some of them store and verify passwords (these are “Work and school” accounts) and some pass authentication through to Microsoft ID authentication servers (these are “Personal” accounts).
If you've been following along, you'll know that I log into all of these places as myeager@awesomeco.com, but this is how I must log into each one:
- Work apps published by Awesome Co: Work or school account / Secr3t
- My personal website: Work or school account / C0vert
- Office 365: Work or school account / P@ssw0rd
- Work Azure account: Personal account / Ncript
- Personal Azure account: Personal account / Ncript
- Third-party apps: Personal account / Ncript
The most important thing I learned when logging into an app and finding myself faced with the dreaded AAD login screen is to look at things from the app's perspective, not my own perspective as a user.
The most important thing I learned when logging into an app and finding myself faced with the dreaded AAD login screen is to look at things from the app's perspective, not my own perspective as a user. The app needs to authenticate each user against a known list of logins. Looking at the log in screen, the list is obviously an Azure Active Directory login, but which AAD? That's not always easy to know. It's up to the app, but you can get a clue by looking at who owns the app. Here are a few commonly used apps and the AADs they use:
- Office 365: An AAD owned by Microsoft, specifically for the Office 365 app.
- Visual Studio Team Services: AAD that's part of the Azure subscription associated with the VSTS subscription. Let's say that I'm doing contract work. The company I'm working for might own the VSTS account and it's most likely using an AAD on that company's Azure subscription.
- Visual Studio (the IDE): AAD set up by Microsoft for the Azure subscription that you've associated Visual Studio with. For instance, my Visual Studio is associated with the MSDN subscription in my company's Azure account.
- My personal website: AAD that I set up under my personal Azure account.
These are four different AADs - four different lists of logins.
Each of these AADs can be set up to handle each login name in one of two ways:
- A Work or school account: A login created within the AAD. This login could be a default assigned by Azure (usually ending in “.onmicrosoft.com”) or could end with a domain name that the AAD admin happens to own (like awesomeco.com) and that the domain owner agreed to associate with that AAD. In either case, the login and password is created within the AAD.
- A Personal account: A Microsoft ID. Note that you can use whatever email address you like for a Microsoft ID. The AAD simply adds your existing Microsoft ID to its own list and passes authentication requests through.
(Note: there are actually more than two ways that AAD logins can be created, but we can dig into that another day. These are the big two, and can be more than enough to make your head hurt).
Login names for AAD look like email addresses. They could be something like myeager@awesomeco.onmicrosoft.com or myeager@awesome.com, but they're not email addresses, they're login names. Real confusion can result when you associate a domain name that you own (like awesomeco.com) with an AAD. As a result, you COULD make your login names the same as your email addresses and you COULD use those same email addresses for your personal Microsoft ID.
In my case, that's what happened. Many of us created our Microsoft IDs way back when and because we only needed it to access stuff for work, we used our work email address to set it up. Microsoft IDs are really supposed to be used for consumer-type stuff, not business stuff. Unfortunately, Microsoft considers all of their own products to be “consumer stuff,” so they set them up so that their customers (us) could access those products with our Microsoft IDs. This isn't really a problem for most non-technical people. If you have a Hotmail account or some other consumer product, that's a personal product and you use a personal account. For us tech people, however, the line gets blurry. My access to MSDN, to Azure, and to a whole bunch of other stuff is all based on my Microsoft ID (what Microsoft refers to as a Personal account). In hindsight, this isn't the best set up, but long before Azure, Microsoft was trying to have people use their Microsoft IDs for everything, so that's how I set mine up. If I were starting over today, I'd link my personal stuff to my Microsoft ID and use my personal email address for it and I'd link my work stuff to my work email.
The Microsoft ID is an odd duck. Apps can use it directly for authentication. For example, I could log into a Web page using my Microsoft ID and password and it might have nothing to do with AAD. This type of authentication against a Microsoft ID has been around a long time; way before Azure even existed. But remember that AAD accounts can also use your Microsoft ID and just pass the authentication through to the Microsoft ID authentication servers. That makes this monkey wrench number five.
The bottom line is that what looks like an email address could be your login name for your Microsoft ID and it could be a login name for any number of AADs. Some of those AADs might even use your Microsoft ID and pass the authentication through. It all depends on how your email address (ahem, login name) is set up in each AAD. The easiest way to troubleshoot is:
I hope this helps. Unfortunately, I think Microsoft got a little caught up in the Re-Use mentality and tried to smash a few very different things together into one big thing that handled every situation. Email accounts got conflated with log in accounts. Microsoft IDs can be used in Azure Active Directories. Azure's authentication mechanism was named Azure Active Directory, even though Windows Active Directory is a very different thing.
In contrast, think about when you log into something using Facebook. How hard is that to understand? Use your Facebook log in name and Facebook password. Simple. That's what Azure AD would have been like if it didn't also support Microsoft IDs and domain name associations.
There's a lot more to the story and every new thing introduces new twists that muddy the waters even further. AADs can pass through authentication to more things than just the Microsoft ID authentication server; they can pass authentication through to other AADs as well as other systems run by Microsoft partners. In addition, similar to Windows AD, Azure AD has capabilities to not only authenticate a user (verify who the user is), but authorize a user (say what they can do). Yeah, let's not even get into that yet.
