In this blog post I'm going to talk about how Microsoft cloud accounts work, and how you can customise your login to fit your organisation. The purpose of this post is to explain the concepts in a way that is easily understandable to you. Like all our blog posts, I will keep this at a fairly high level and not go into the technical details.
Please note that the following information relates to Microsoft organisational accounts (Microsoft often refer to these as work or school accounts). It does not relate to personal Microsoft accounts.
Non-Cloud Networks
If you have experience of a computer network within an organisation, you will probably be familiar with the concept of domain accounts. In essence these are accounts or login IDs that give an individual access to resources across an organisation, that are centrally managed (often by a dedicated IT team or department).
In this scenario, all the accounts/IDs for your organisation (and only the accounts/IDs for your organisation) are stored by servers attached to your organisation's network that have the role of making sure that anyone who attempts to login and access resources on the network is authorised to do so.
Different types or vendors of the networking infrastructure will implement different approaches to how this is done, but the end result is very similar (for example, Microsoft networks will use Active Directory to store, manage and distribute security accounts).
For smaller networks, all accounts may exist in the same place and the may be grouped together logically.
For larger networks, there may be multiple logical groupings and these may be distributed geographically within the organisation for performance and administration reasons.
For example, a larger organisation may divide their security accounts into groups based on different geographies and/or functions.
Microsoft Cloud
Authentication within the Microsoft cloud takes this even further. When you login to Microsoft cloud services you are accessing a central authentication system that authenticates every Microsoft cloud account.
However, each account belongs to a distinct and separate logical unit within the Microsoft network. This separation ensures that when you login you are only able to access the resources and services that your organisation has access to (and within that, only those resources and services that the administrator of your organisation has permitted you access to).
Microsoft refers to each of these logical units as a 'Tenant'. Smaller organisations may have a single tenant, whilst larger ones may utilise more than one.
Microsoft login IDs look like email addresses (and in many cases, are also an email address), and the tenant is identified by the part of the login ID after the '@' symbol.
Initially, an organisation will be provided with a xxx.onmicrosoft.com domain (where 'xxx' is a unique company identifier provided by the organisation - usually the company name in some form).
Once the tenant has been created, it is then possible to associate any existing domain that you own so that the xxx.onmicrosoft.com identified is replaced with something more useful (in most cases this is likely to be the same domain an organisation uses for email or their website).
A tenant, and it's associated accounts, is used across the Microsoft cloud estate. Once setup it can access any of the cloud services that Microsoft offers. It can also often be used for accessing other services on the Internet (see the Single Sign-On section below).
Example
So lets look at an example, for a fictitious company called Fred's Wacky Widgets Ltd.
Please note that Fred's Wacky Widgets Ltd. is a totally fictitious company I've made up for the purposes of this blog post.
I apologise if it has any similarity with an existing company, and can assure you that no relationship between the two is intended!
This company already has email with another vendor and they own the internet domain fredswackywidgets.com, with two members of staff:
Fred (Fred@fredswackywidgets.com)
Freda (Freda@fredswackywidgets.com)
The company has decided to migrate to the cloud, and they decide that their first step is to subscribe to Microsoft 365, for office applications and email.
When the company purchases it's initial MS365 licenses, they use the abbreviated name of fwwidgets for the initial tenant identification.
So, Fred and Freda now have the following login IDs to login to Microsoft cloud services:
fred@fwwidgets.onmicrosoft.com
freda@fwwidgets.onmicrosoft.com
Obviously, this is no use when setting up the MS365 email, so they then link their existing domain (fredswackywidgets.com) with their Microsoft tenant. This allows them to login to their new Microsoft accounts with Ids that match their existing email addresses:
fred@fredswackywidgets.com
freda@fredswackywidgets.com
It is possible to associate multiple domains with the same Microsoft tenant, which allows a great deal of flexibility when setting up email.
The company can now assign the Microsoft 365 licenses they've purchased, migrate their email and also use the new accounts for accessing Azure services.
Single Sign-On
Single Sign-On (or SSO) is a feature that allows you to use an existing account from a known vendor to login to, and authenticate yourself with, other cloud services.
This ability is based on a global standard called OAuth and is increasingly being used by websites to allow you to login using your ID from a known and trusted company.
You may have noticed that when you register with some websites, you are given the option of creating an account, or logging in with an exiting account from Microsoft, Google, Facebook etc...
The screenshot above is of the Epic Games sign in screen, this site is a good example of multiple potential SSO sources (it is rare to see this many options).
In this situation, if you have an existing account with Microsoft, you can use it to access some non-Microsoft services.
One of the main benefits of SSO is that you get the security that has been developed and implemented by Microsoft (or Google, Facebook etc...). These are giant, multinational organisations that have immense budgets and resources for security. Smaller organisations can't even hope to match this level spending and so it makes a lot of sense for them to use the protection provided by the larger organisations by implementing their authentication services.
However, this is also a potential pitfall. If anyone gains access to your user ID and password, they can then have access to multiple other services. You should always combine SSO with multi-factor authentication methods.
Another benefit is that it reduces the number of accounts and passwords that you have to remember.
I was going to talk about Multi-Factor Authentication in this post. However, I've decided that it's such an important element of protecting your cloud accounts, that I'll dedicate the next post to this topic.