Authentication in Office 365 (a bit of theory)

It’s always difficult to start somewhere. After much thought, I decided to devote my first article on Habré to the topic that I am currently working on - Office 365 in all its manifestations.

The site has already had several articles describing certain components of this service. They also wrote about setting up authorization using ADFS and synchronization with Active Directory , but in addition to practice, a little theory does not hurt. Of course, it is impossible to tell everything, and it’s not interesting, but it’s worth noting important moments, in my opinion.

From my own experience, I can say that authentication in Office 365 is a rather complicated topic, the apparent simplicity and obviousness of which often hides subtle nuances, the knowledge of which allows you to better deploy the system and reduce the time required to localize the problem. These are the nuances I would like to talk about today.


Office 365 has three types of identifiers used to authenticate your users with Exchange Online, Sharepoint Online, Lync Online, and even Office Pro Plus.

1. Microsoft Online ID is a regular Windows Azure Active Directory account. This is an analogue of the familiar Active Directory, but adapted for working with Microsoft cloud products (for example, in addition to Office 365, it is also used for MS Dynamics CRM Online). Users are created manually using the administration portal or in bulk via a CSV file.
2. Microsoft Online ID + DirSync are the same “cloud” users, but they are a copy of the accounts from your AD created using the Microsoft Directory Synchronization utility or DirSync for short. Almost all the main attributes are transferred from local AD, but user passwords are not transferred. User management is partly through AD, partly on the portal.
3. Federated ID + DirSync - at the heart of the system is the same principle of copying accounts from your AD, with the only difference being that Active Directory Federation Service 2.0 is used for authorization. User management is done through local AD.

Identifier Type Comparison

Microsoft Online ID	Microsoft Online ID + DirSync	Federated ID + DirSync
Lecture hall Small organizations without on-premises Active Directory	Lecture hall Medium-sized organizations with on-premises Active Directory	Lecture hall Large organizations with on-premises Active Directory
"Behind" No local servers required	"Behind" Local user and group management Coexistence Scenarios	"Behind" Single sign-on topology with corporate details Local Identity Management Password policy is controlled locally Two-factor authentication possible Coexistence Scenarios
"Against" Unable to use single sign-on topology Two-factor authentication not possible Two sets of details with different password policies Cloud Identity Management	"Against" Unable to use single sign-on topology Two-factor authentication not possible Two sets of details with different password policies Server Deployment Required	"Against" High Availability Server Deployment Required

In practice, the third option is most often chosen because this allows for uniformity of accounts and simplify user management as much as possible, while retaining full control over access rights and password policies.

If the first two options are technically pretty obvious, then when implementing authentication using ADFS there are difficulties.

Before I talk about the authentication mechanism, I’ll give a real life situation: in the company of 1000+ users, Office 365 was used with authentication through ADFS. One not-so-beautiful morning, users began to complain that their Outlook could not connect to mail, but still had access to Outlook Web Access, SharePoint, or Lync. The reason for the failure was a change in server policies and, as a result, the ADFS Proxy service crashed. To localize this problem, several hours were spent that could be saved by understanding a few simple things about authentication in Office 365.

So, Office 365 uses two main mechanisms (sometimes called profiles) of authentication:

Passive mechanism- Used for authorization in Office 365 services using a browser or single sign-on service.
The principle of operation of this mechanism can be illustrated by the scheme:

1. A user, using a browser or Lync client, requests information from the SharePoint Online service, Exchange OWA or Lync server and receives a response requesting authorization on the Authentication Platform
2. After receiving the request, the Authentication Platform determines that a federated identifier is used and requires a User Source Id that confirms the validity of the user in the local Active Directory), which redirects the request to the ADFS server URL.
3. The ADFS server authenticates the user in local AD and issues a signed User Source ID to it.
4. Armed with a kind of "passport", the user once again turns to the Authentication Platform, from which this time receives a "cloud-based identity" NET ID.
5. This certificate is further used to work with services

Active mechanism - used for authorization in the email service using Outlook or when using ActiveSync, IMAP, POP3 protocols.
The scheme is very similar to the previous version:

The principle of operation of this authorization mechanism repeats all the steps, except for one important detail - the user sends his credentials to the Exchange Online service in an explicit form (naturally protected by the HTTPS protocol). Exchange Online, using the impersonalization mechanism, goes through all further steps on behalf of the user, including communication with the ADFS server and obtaining the User Source ID.

Therefore, you can identify several key points that you should pay attention to: DNS, certificates, publication, and fault tolerance.

DNS
If problems arise, you must always remember which DNS server the user is currently using when authorizing for a particular service.

Certificates
If all your users are on a corporate network and use only a browser and Lync client to work with Office 365, then you can forget about this item and feel free to use the self-signed certificate of your CA. But as soon as you have external users or you want to configure your favorite phone to receive corporate mail, you will need a valid certificate issued by a trusted certification authority. As a best practice, even at the stage of transition to Office 365, it’s worth immediately planning a purchase if not a wildcard, then at least an ordinary one with a pair of SANs, not hoping that you have a unique situation and external users will never appear.

Fault tolerance
It seems that the most obvious thing of any IT system, in practice, is the most painful. Ensuring ADFS server fault tolerance is a critical and often overlooked step when setting up federated authentication. Improving the reliability of ADFS is quite an easy task, which consists in using either a third-party NLB or a standard Windows Load Balancer (WNLNB). I understand that I’m talking about obvious things, but, unfortunately, many administrators do not pay attention to the topic of fault tolerance, trying to “one day later” deliver another server. Without going into details, in practice, lack of ADFS balancing is the most common cause of problems with Office 365.

Publishing
As soon as Outlook or ActiveSync appears in your Office 365 use case, the question arises of properly publishing ADFS out. There are several possibilities for this:

• Exposing an ADFS server is the worst and most unsafe option used by administrators not from a good life.
• Deploy ADFS Proxy - you will need two additional servers and load balancing between them (again using a third-party NLB or WNLB). Among the advantages, it is worth noting the ease of setup and administration. There is almost nothing to break there.
• Publishing through Forefront TMG / UAG is harder to configure and support, but much more functional. It allows you to expand the ADFS functionality for external users and implement more complex Office 365 authorization scenarios. Some administrators manage to use the TMG and ADFS Proxy publications, which, in principle, is possible, but carries many difficulties and instabilities that are difficult to localize.
• External Reverse Proxy - can be any solution / device that does not modify SAML requests / responses, for example Citrix NetScaler or even a simple stunnel. Reverse proxy requirements can be found here.

Authentication in Office 365 is a topic that you can write about for a very long time. Today I tried to tell, in my opinion, important points that often cause misunderstanding and mistakes. For some, this article will be obvious, but I hope there are those to whom it will save several unpleasant hours of localizing the problem and a kilogram of nerve cells.