One of the least used and understood features of SharePoint Online is the Partner Access License or PAL. This license allows you to invite external users to sites within your SharePoint Online tenant without you needing to issue them with an Office 365 license. The only requirement to achieve this is that the user must possess or create a Microsoft account (formerly Live ID) which includes outlook.com, live.com, hotmail.com and msn.com addresses (amongst many other regional derivatives such as live.co.uk).
You are limited in the number of users you can invite using this scheme and the number changes depending on your Office 365 license level – you can find details on this post under “Maximum number of external user invites”.
Having used these license types quite extensively over the last 12 months I thought I would share some key learnings around setting them up.
A few key concepts
The following really need to be understood or explained to understand the rest of the post.
Microsoft account: the new name from Microsoft for any publicly available login account Microsoft provides. It’s had many names and formats over the years as mentioned above.
Federation: in the context of this blog this is the process of synchronisation of an on-premise Active Directory with Azure Active Directory for the purpose of sharing on-premise user information with cloud services such as Office 365.
Cloud account: when you set up an Office 365 subscription you automatically get a chunk of the ‘onmicrosoft.com’ domain snapped off for your own use. These accounts can be used to login and typically take the form user@subscriptionname.onmicrososft.com (i.e. billy.bob@siliconvalve.onmicrosoft.com). This format is also known as a User Principal Name or UPN.
Federated account: an on-premise account that is synchronised with the cloud to allow a user to be granted access to various cloud services. These use custom domains and take the form user@customdomain (i.e. billy.bob@siliconvalve.com). In Office 365 these are an alias of a matching @subscriptionname.onmicrosoft.com account.
Active Directory Federation Services (ADFS): a solution from Microsoft to enable sign-on using passwords that remain on-premise.
Now we have those out of the way, let’s get onto the core of this post.
Recommendation: Use a basic Microsoft account
Have external users register an account with one of the public forms of @outlook.com, @live.com, etc. rather than them use a custom domain. If they have an existing Microsoft account using one of the public domains that could be good to use also. Ask them to enable a second factor of authentication.
Here’s why I recommend using a basic account:
Blocked Custom Domains
Some custom domains are blocked from being used as Microsoft accounts – you can request to have it unblocked by Microsoft but it’s probably not a bad restriction to keep to ensure you keep control over your domain.
Example of a reserved domain.
Limited ability to create lots of accounts
By default you are limited in the number of new Microsoft accounts that can be created in any one day (three accounts to be precise) from an single IP address. Not exactly scalable if you have to create even a moderate number of new accounts in one go. If you try to exceed this limit you’ll get a nice error screen that reads “Sign Up Error 450: You’ve reached the daily limit for creating Microsoft accounts. Please wait a day and try to sign up again.”
Domain is already in use
The domain may already be in use on Office 365 either via Cloud or Federated accounts which leads to problems at login. The user may be able to create a Microsoft account with their custom domain but as soon as they are prompted to login to Office 365 the problems will start.
First let’s look at the three login experiences each account type can have.
When a Cloud account is entered into the login box on the Office 365 login page they must enter their password into the form as well.
Cloud account login example.
A Federated user’s experience may be similar to the above or they may be redirected to their organisation’s ADFS login page to enter their password before being redirected back to Office 365 after a successful login.
A PAL user has two ways to log into Office 365: entering their Microsoft account into the username box on the Office 365 login page or by clicking on the “Sign in with a Microsoft account” link. In both cases the user is redirected to a Microsoft account login page (shown below) for authentication. This experience is very similar to ADFS and gives you a pretty clear idea of how Microsoft accounts work with Office 365 (hint: federation).
Microsoft account login example.
The upshot of the above login experiences is this: if you create a Microsoft account that matches one that is already a Cloud or Federated account then you can only log in using the Microsoft account by clicking on the “Sign in with a Microsoft account” link.
Allowing the Office 365 login page logic to run could either prompt for a local login (Cloud) or automatically redirect the user to their organisation’s ADFS login page (Federated). In both cases the user may authenticate OK but will not have access to your SharePoint tenant as in both cases they have signed into their own organisation’s tenant. The result is they will see a page similar to the one below (click to enlarge).
Failed login due to Federated Identity not in directory example.
That’s all folks!
So, there we have it – the old KISS principle really holds here – don’t try and get fancy with custom domains and you should find you can turn PALs into your friends.
HTH.
