When using Active Directory Federation Services (AD FS) as the authentication solution for Office 365, you need to understat what that means from service impact perspective should AD FS become unavailable for any reason. While Microsoft does provide a SLA for Office 365, the SLA will not cover outages caused by AD FS going offline in your on-premises datacentre.
In the example environments below, you will see the different user experiences when AD FS goes offline. These outages could be caused by a power failure, gopher eating your fibre or an administrator making a change on AD FS that does not go to plan. That certainly happens!
The short story is that in the AD FS scenario, Microsoft does NOT authenticate you. The authentication is performed by your on-premises AD FS and AD DS servers along with any other add-ons that may be integrated into AD FS. An example of this used to be MFA done directly on AD FS if the customer had an existing on-premises MFA solution. Microsoft receives the signed response from AD FS and assuming that it is valid, then authourises you as applicable.
Tailspintoys Example
In the Tailspintoys Canada lab, an Azure load balancer is used to publish and load balance the AD FS and WAP servers.
In the example below, the AD FS service was stopped on all AD FS servers on the farm. This emulates the situation of the user being unable to authenticate with AD FS.
Note that Office recognises that the users is part of a federated domain, and redirects the browser to the AD FS signon page.
We see the California highway, and get directed to the federation endpoint.
We see the federation redirection in the browser. Microsoft does not authenticate the user in the federated scenario. That is the responsibility of the federated solution.
The WAP servers are running, so it is possible to make a TCP connection to WAP. WAP does not perform the authentication, that is done by AD FS servers in conjunction with AD DS. Since the federation service is stopped on all AD FS servers there is no way the authentication request can be completed. We get a screen which looks like a polar bear in a blizzard.....
The net result is that the user is unable to authenticate and get access to Office 365.
What about desktop clients?
Tailspintoys – Outlook 2010
From an Outlook 2010 client persespective, what does a user see on their workstation when AD FS is unavailable?
There will be a difference in behaviour depending if the user has an existing refresh token. That could be used to request a new access token.
We need to emulate the situation where the user is unable to complete a fresh authentication so existing credentials etc. need to be removed.
The previously provided credentials are saved inside of credential manager, so let's remove then to see what a fresh logon looks like with no cached credentials etc. That will mean the client has to go and get new tokens.
Once the credentials were cleared out, let's start Outlook.
Note that it is unable to connect.
Tailspintoys – Outlook 2016 With Modern Authentication
For a more modern Outlook client, the saved entities inside of the credential manager will look different. That is because this client supports modern authentication so we see the ADAL authentication items.
Again, clear out those credentials and fire up Outlook.
Does it work? Are we able to connect?
That's a hard nope. AD FS is unavailable and we can not be authenticated.
Tokens & Sessions
Update: Note that the below information is now dated and Continuous Access Evaluation should be the focus
Session lifetimes are an important part of browser-based authentication for Office 365 and are an important component in balancing security and the number of times users are prompted for their credentials.
Session timeouts for Office 365
When you authenticate to any of the Office 365 web apps, a session is established between your browser and the Office 365 web app you’re using. For the duration of the session, you won’t need to re-authenticate to the web app. Sessions can expire when you're inactive, when you close the browser or tab, or when your authentication token expires for other reasons such as when your password has been reset. Each of the different web apps in Office 365 have different session timeouts. The default timeout value is in line with how you normally use the app.
Azure Active Directory
(Used by Office 2013 Windows clients with modern authentication enabled)
Modern authentication uses access tokens and refresh tokens to grant uses access to Office 365 resources using Azure Active Directory. An access token is a JSON Web Token provided after a successful authentication and is valid for 1 hour. A refresh token with a longer lifetime is also provided. When access tokens expire, Office clients use a valid refresh token to obtain a new access token. This exchange succeeds if the user’s initial authentication is still valid.
Refresh tokens are valid for 14 days, and with continuous use, they can be valid up to 90 days. After 90 days, users will be asked to re-authenticate.
Refresh tokens can be invalidated by several events such as :
- User’s password has changed since the refresh token was issued.
- An administrator can apply conditional access policies which restrict access to the resource the user is trying to access.
The following table lists the session lifetimes for Office 365 services as of 25th April 2017
Cheers,
Rhoderick
