Office 365 authentication (some theory)

It's always hard to start somewhere. After much deliberation, I decided to devote my first article on Habré to the topic I’m currently engaged in - 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 with ADFS and synchronization with Active Directory , but in addition to practice, it would not hurt a bit of theory. Of course, it’s impossible to tell everything, and it’s not interesting, but important, in my opinion, points worth noting.

From my own experience, I can say that authentication in Office 365 is a rather complicated topic, for the seeming 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. I would like to talk about such nuances today.
')

In Office 365, there are three types of identifiers used to authenticate your users in 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 similar to all of us familiar to Active Directory, but adapted to work 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 through a CSV file.
2. Microsoft Online ID + DirSync - the same "cloud" users, but represent a copy of the accounts from your AD, created using the utility Microsoft Directory Synchronization or abbreviated DirSync. Almost all basic attributes are transferred from the local AD, but user passwords are not transferred. User management is carried out in part through AD, partly in the portal.
3. Federated ID + DirSync - the system is based on the same principle of copying accounts from your AD, with the only difference that Active Directory Federation 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 local Active Directory	Lecture hall Medium organizations with local Active Directory	Lecture hall Large organizations with local Active Directory
"Behind" No local servers required	"Behind" Local user and group management Coexistence scenarios	"Behind" Corporate login topology with corporate details Local Identity Management Password policy is controlled locally Two-factor authentication possible Coexistence scenarios
"Vs" Impossible single sign-on topology Two-factor authentication not possible Two sets of details with different password policies Cloud Identity Management	"Vs" Impossible single sign-on topology Two-factor authentication not possible Two sets of details with different password policies Server deployment required	"Vs" High availability server deployment required

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

If the first two options are rather obvious from the technical point of view, then there are difficulties with the implementation of authentication using ADFS.

Before talking about the authentication mechanism, I’ll give you a real life situation: in a company of 1000+ users, Office 365 was used with ADFS authentication. On a not very beautiful morning, users began to complain that their Outlook could not connect to the mail, but access to Outlook Web Access, SharePoint, or Lync was preserved. The reason for the failure was a change in server policies and, as a result, the fall of the ADFS Proxy service. For localization of this problem several hours were spent, which could be saved, understanding a few simple things about authentication in Office 365.

So, Office 365 uses two basic mechanisms (sometimes called profiles) for 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 a Lync client, requests information from a SharePoint Online service, Exchange OWA, or a Lync server and receives a response asking to authenticate with the Authentication Platform
2. The Authentication Platform, after receiving the request, determines that a federated identifier is used and requires that the User Source Id be submitted (confirming the user's validity in the local Active Directory), for which it forwards the request to the ADFS server URL.
3. The ADFS server authenticates the user in the local AD and gives it a signed User Source ID.
4. Armed with a kind of “passport”, the user once again turns to the Authentication Platform, from which this time receives a “cloud ID” NET ID.
5. This credential is further used to work with services.

Active mechanism - used for authorization in the e-mail service using Outlook or using the 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, with the exception of one important detail - the user sends to the Exchange Online service his credentials explicitly (naturally protected by the HTTPS protocol). Exchange Online, using the impersonalization mechanism, goes through all further steps on behalf of the user, including communicating with the ADFS server and obtaining the User Source ID.

Therefore, you can identify several key points that are worth paying attention to - these are DNS, certificates, publication, and fault tolerance.

DNS
If you have problems, you need to always remember which DNS server the user is currently using when authorizing on a particular service.

Certificates
If all your users are in the corporate network and use only the browser and the Lync client to work with Office 365, then you can forget about this item and safely use your CA's self-signed certificate. But as soon as you have external users, or you want to set up your favorite phone to receive corporate mail, you will need a valid certificate issued by a trusted certificate authority. As a best practice, still at the stage of transition to Office 365, you should immediately plan a purchase if not a wildcard, then at least a regular one with a pair of SANs, not hoping that you have a unique situation and external users will never appear.

fault tolerance
It seems to be the most obvious thing of any IT system, in practice, it turns out to be the most painful. Failover of the ADFS server is the most important and often overlooked step in setting up federated authentication. Improving the reliability of ADFS is quite a simple task, consisting in the use of either a third-party NLB or a regular Windows Load Balancer (WNLNB). I understand that I’m talking about obvious things, but, unfortunately, many administrators don’t devote to the topic of fault tolerance, trying “sometime later” to deliver another server. Without going into details, in practice, the lack of ADFS balancing is the most common cause of problems with Office 365.

Publication
As soon as Outlook or ActiveSync appears in your Office 365 usage scenario, the question arises whether ADFS is properly published outside. There are several possibilities for this:

• Putting the ADFS server out is the worst and insecure option used by administrators not from a good life.
• Deploy ADFS Proxy — you need two additional servers and load balancing between them (again using third-party NLB or WNLB). Among the advantages worth noting the ease of configuration and administration. There is almost nothing to break there.
• Publishing through Forefront TMG / UAG is more difficult to configure and maintain, but much more functional. Allows you to extend the functionality of ADFS for external users and implement more complex Office 365 authorization scenarios. Some administrators manage to use the TMG and ADFS Proxy publication, which, in principle, is possible but fraught with 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. Requirements for reverse proxy can be found here.

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