I’ve worked with a few customers now who have had a few issues when using Office Modern Authentication preview that was announced recently and this post is about a few tips that smoothens out the sign-in experience. Customers who are federated and use ADFS have really looked at Office Modern authentication to provide 2 key benefits.
- Desktop SSO from a domain joined machine accessing office resources from inside their corporate network. This was especially relevant with Outlook because in prior versions, the user would need to enter their username & password even if the were logging in from a domain joined machine inside their company network.
- Customers want to enable MFA for extranet access or only have smartcard login available to their users
Issue #1: Desktop SSO does not work
As soon as you try out the new Azure AD app (e.g. Office native apps) modern auth flows with ADAL, you may notice that you are not getting SSO. Office clients have an optimized path for their first accounts to work against the WS-Trust kerberos authenitcation endpoints of ADFS. If this fails, then the Office clients fall back to an interactive login session through a web browser dialong. Unfortunately, Office and ADAL clients target the WS-Trust 1.3 version of the endpoint for windows integrated authentication which is not enabled by default. This can be fixed easily by enabling it on the ADFS service. The PSH cmdlet to do this is:
Enable-AdfsEndpoint -TargetAddressPath “/adfs/services/trust/13/windowstransport”
The office and ADAL teams are working towards using the standard WS-Trust 2005 endpoint that is enabled by default in ADFS. However, this probably won’t show up until a future CU for the Office 2013 client. It’s better for you to enable the endpoint and there is no difference in behaviors between the 2 versions of the endpoints.
Issue #2: ADFS Error page during authentication
The next issue that you could face is an error page on ADFS when being accessed by iOS or Android Office apps within the company network. This error occurs because Azure AD treats ‘prompt=login’ sent by the application that uses modern authentication (a.k.a. ADAL enabled) as ‘wauth=<pwd-auth>’ (asks ADFS to do password auth) and ‘wrefresh=0’ (asks ADFS to ignore any prior SSO state) in the request to ADFS. With ADFS 2012R2, the default intranet authentication policy does not enable password authentication by default. As a result, ADFS fails the request. The fix for this is simple. Just enabling the password authentication for the intranet will fix this issue. You can access this by editing the primary authentication policy from the AD FS snapin (under Authentication Policies). See image below.
You do not have to worry about any impact to your existing Windows Integrated Authentication. If Windows Authentication is enabled, ADFS will always try this if the user agent string matches the list that is configured in ADFS and fall back to forms authentication otherwise.
In addition, you may find that users are unable to login using their smartcard (cert authentication) in certain cases. If you do discover this (not very common), please call Microsoft support to enable a flag on your tenant to not enable the ‘wauth’ behavior conversion performed by AAD in the issue #2 above to be disabled.
// Thanks //
Hope you find these tips useful. Some of this information is captured in KB3052203