At the time of writing, Microsoft Office 365 has the ability to work with three identity models:

• Cloud identity (stored in Microsoft Azure Active Directory).
• Synchronised identity (a copy of the objects from an on-premises Active Directory is made in Microsoft Azure AD), optionally with synchronised password hashes.  This is also known as same sign on (not single sign on as there are still two separate objects, albeit two objects that are kept synchronised).
• Federated identity, using a federation service (such as Active Directory Federation Services, but others are supported) to authenticate users in an on-premises directory following which authorisation can be granted to Office 365 resources. This is also known as single sign on.  In this instance, directory synchronisation is still used to populate the Azure AD with user objects, although authentication happens on-premises.

Whilst the majority of small businesses will be fine with cloud identities, many of my conversations with enterprise customers start off in the directory synchronisation space. Generally, synchronisation is performed using the Office 365 DirSync appliance (a customised version of Forefront Identity Manager) although, more recently a new tool (Azure AD Sync) has been released that will eventually replace DirSync.  At the time of writing the main difference is that Azure AD Sync supports multiple forests (DirSync is a single forest solution) but it doesn’t support password synchronisation (still a major advantage for DirSync).

In general, the approach I recommend is to choose the simplest model for the organisation’s needs. The cloud identity model can work well when there is no on-premises directory service or there is no requirement to integrate; synchronised identity is the most commonly used (assuming there is an existing Active Directory) but sometimes federation is required:

1. If there is an existing ADFS infrastructure.
2. If a third party federated ID provider is in use.
3. If Forefront Identity Manager 2010 is in use (which does not support password synchronisation).
4. If there are multiple on-premises Active Directory forests (although Azure AD sync may negate this requirement).
5. If smart cards or other third-party multi-factor authentication solutions are in use (Azure AD does have an MFA capability, although there are some restrictions on its use).
6. If custom hybrid apps or hybrid search are in use (SharePoint).
7. If a hybrid Lync solution is in use (i.e. placing users with enterprise voice capabilities on premises and those that don’t need voice in Lync Online, sharing the same SIP namespace).
8. For self-service password reset via a web service (only administrators have self-service password reset in Office 365).
9. If there is a requirement to audit logins and/or immediately disable accounts.
10. If there is a requirement for single sign-on (i.e. accessing Office 365 workloads with the same user credentials as on-premises).
11. If there is a requirement to restrict client logins by time or location.
12. If the organisational security policy prevents the synchronisation of password hashes to Azure AD.

On a related topic, the Microsoft Online Services Sign-in Assistant (MOSA) for IT Professionals only exists to simplify the user experience (handling tokens, etc.) and is generally not required with modern versions of Office. Administrators using PowerShell may still need it though.

Finally, if ADFS is down, there is no way for users to authenticate. For that reason, federated infrastructure needs to be highly available (e.g. multiple ADFS proxies and multiple ADFS servers).  One method that’s starting to be commonly recommended is an “ADFS safety net”, using DirSync as a fall back (it’s possible to move between identity models on demand) but obviously that’s only an option if your organisation’s security policy allows the synchronisation of identities (including password hashes to minimise the impact on end users).

RT @mderooij: Fallback options for when ADFS is unavailable #devconnections pic.twitter.com/T8iPywpNUu ^MW Great advice…

— Mark Wilson (@markwilsonit) September 18, 2014

For reference, the PowerShell commands are:

• If ADFS is available:

Convert-Msol-DomainToStandard -DomainName domainname.tld -SkipUserConversion $true
Convert-Msol-DomainToFederated -DomainName domainname.tld

• If ADFS is unavailable:

Set-Msol-DomainAuthentication -Authentication Managed -DomainName domainname.tld
Convert-Msol-DomainToFederated -DomainName domainname.tld

Credit is due to Michel de Rooij (@mderooij) for the ADFS safety net tip.