The chart below shows the availability of Modern Authentication across Office apps: This enables sign-in features such as Multi-Factor Authentication (MFA), SAML-based third-party Identity Providers with Office client applications, smart card and certificate-based authentication, and it removes the need for Outlook to use the basic authentication protocol. Modern Authentication brings Active Directory Authentication Library (ADAL)-based sign-in to Office client apps across platforms.
Instead, Outlook uses the Outlook Anywhere function, and unfortunately, requires the use of Basic Authentication, meaning you must enter in a username and password every time, unless you of course, cache the credentials.įor a long time, most of my clients would ask me “is Microsoft ever going to change this?”, and would state “well this defeats the purpose of utilizing ADFS for true SSO.” And I agree, but now, it seems like Microsoft’s ears were ringing, because the wish of using Outlook with Office 365 and not having to cache credentials has been granted!īut how does this work, and what limitations are there? I’ll explain in this article. To catch you up to speed, when users connect to Office365 via Outlook, they cannot utilize ADFS to do a true Single Sign On (SSO) experience. Now for those who may be curious about moving to Office 365, you are probably wondering what I’m talking about. And if your company is one of those who has migrated to Office 365, then you are probably aware of the one struggle that everyone who’s ever moved to 365 has had to deal with – saving credentials for Outlook. We’ve heard the name and you probably know someone that has migrated from their on-premises Exchange organization to it. If you have kiosks on which the user who starts the Skype for Business client differs (that is, has a different account) from the user who is logged on to the computer, you may want to test the method of turning on the Prompt for user name and password option for these computers in Group Policy.Office 365. In this situation, you may see the failures that are described in the "Symptoms" section. The account that is logged on to the operating system may be different from the user account that is used to sign in to the Skype for Business client. For example, a kiosk is configured in this manner. To avoid this issue, the browser must be explicitly configured to prompt users for their credentials in a given browser Security Zone.
When the ADAL STS URL resolves to an internal ADFS server, and Integrated Windows Authentication is enabled in browsers, computers on which many users sign in to client applications may not authenticate the logon attempts. The value 0x10000 represents the “Prompt for user name and password” setting. Location: HKEY_LOCAL\MACHINE\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\1 Push the following registry key to the affected client computers by using the following Group Policy Object: In the User Authentication section, select the Prompt for user name and password option. Typically, this is the Local Intranet zone.Ĭlick the Custom level button, and then scroll to the end of the Settings list. Select the security zone that includes the STS URL.
In Internet Explorer, click Tools, click Internet Options, and then click the Security tab. To do this, use one of the following methods.
To resolve this issue, change the Internet Explorer “User Authentication” settings on the affected client computers to “prompt for user name and password” in the security zone. Therefore, users are signing in to Skype for Business by using different user credentials than those for the account that is logged on to the Operating System. This issue occurs because Integrated Windows Authentication is enabled for the ADAL Security Token Service (STS) URL.
If that doesn’t work, contact your support team. It might be your sign-in address or logon credentials, so try those again.