More information about SSO experience when authenticating via ADFS
Common understanding about SSO:
Which may mean user enters username/password once, and does not need to reenter again during the same session.
It may also mean that when accessing different application/resources, we need not enter different credentials, but enter the same ones.
AD FS 2.0 enables identity federation, extending the notion of above centralized authentication, authorization, and single sign-on to Web applications and services located virtually anywhere.
As previously introduced, identity federation relies on standards-based protocols to establish federation trusts between claims providers and relying parties, facilitating secure access to Web applications and services across security boundaries.
For an organization, AD FS 2.0 provides corporate users with a rich federated experience and seamless access to resources located:
- Inside the corporate intranet;
- Outside the corporate network in a corporate perimeter network, extranet and/or in the Cloud, for example in the Microsoft Windows Azure platform, the Microsoft’s Platform as a Service (PaaS) offering;
- At the perimeter networks of partner organizations that have made resources available to the considered organization’s users;
- In the Cloud with Software as a Service (SaaS) vendors that support federated identity, for example, Microsoft with its Microsoft Office 365 offerings in the context of this paper.
While ADFS service provides Single Sign On (SSO) experience, below are a few points we need to be aware of to make the experience seamless. It should also help avoid confusion around Single Sign On when working with ADFS.
Common pre-requisites
- Although any current Web browser with JScript enabled can work as an ADFS client, only Internet Explorer, Mozilla Firefox, and Safari on Apple Macintosh have been tested by Microsoft. For performance reasons, we highly recommend that JScript be enabled.
- Cookies must be enabled, or at least trusted, for the federation servers and Web applications that are being accessed. It’s using Cookies that we prevent repeated logons to a service, within the same session. Cookies can also prevent repeated home realm discovery prompts with that are more claim providers on the STS. The authentication cookie is signed but not encrypted, which is one reason why use of TLS/SSL is mandatory in ADFS.
SSO when on the intranet from a domain joined machine, logged in with a domain credential:
To ensure the user is not prompted for his logged in credentials again, when accessing ADFS from intranet, the following configuration needs to be in place.
- In Internal DNS should resolve the ADFS service name to the backend ADFS servers or Load balanced IP for ADFS service. Domain Name System (DNS) resolution of the AD FS 2.0 service endpoint should not be performed through CNAME record lookup, instead we should add a A record for the ADFS service name.
- The Web-proxy configured on the client should be configured to bypass proxy, for request to ADFS URL
- The ADFS URL should be added to the IE > Security >Intranet zones > sites. This is done because IE > security > Local Intranet > Security Settings > user authentication – logon is configured to use the logged in credentials for Intranet sites.
- Ensure that IE > advanced > 'Enable Integrated Windows Authentication' is checked.
- Ensure that an SPN ‘HOST/ADFSservicename’ is registered for the ADFS service under the ADFS farm service account, to allow Kerberos authentication.
- The default authentication configuration for the ADFS service (in C:\inetpub\adfs\ls\web.config) is Integrated Windows Authentication, ensure that it has not been changed to Form-based Authentication.
- The credentials prompt can only be avoided when you are accessing the cloud service using the same account used to logon to the workstation.
- If a user chooses to save his credentials in the 'credentials manager' (By selecting save password checkbox in the credential prompt) for use with ADFS, that saved credentials will only provide an SSO experience till the user changes his password. If the credential manager is not updated with the new password of the user, it will continue to use old user credentials and prompt the user for good credentials, after a number of failed attempts with the stale saved credentials.
- If user A wants to access User B’s mailbox, user B’s credentials has to be provided and ADFS will prompt you for user B credentials because it has no ways of guessing it by itself. But once User B’s credentials has been provided and the user is authenticated, the Browser may cache the
user B’s credentials and would reuse it when the same instance of IE is used to access the same application or authenticate via the same ADFS service.
- ADFS and most of the web applications do write cookies on the client machine after being authenticated/authorized, these cookies may be session specific or may be valid across sessions. If these cookies are valid, and presented again to the application /ADFS, by the browser, the user is allowed in without repeated authentication. For example, after being logged into Sharepoint or O365, we write a few AUTH related session cookies on the client. These cookies are presented again, if you access a link in the web application that opens up another page in the same windows or another tab, sharing the same session cookies. These session based cookies should expire once you sign-out of the application/ ADFS, post which the user may need to authenticate again.
SSO when accessing resources from over the Internet or an External network:
- When getting redirected to ADFS for authentication, our request hit the ADFS proxy (assuming you have the ADFS proxy configured, a workgroup server in DMZ network), which presents us a Form asking for user credentials.
- The default configuration on ADFS proxy is Form-Based Authentication, where the user is presented with a webpage asking for credentials. Since we use SSL to connect to ADFS proxy and passing credentials, the communication with the server is secure and encrypted. This authentication request with credential is later passed to the ADFS server over a SSL session, for getting the user authenticated.
- The reason why we stick to form based authentication when going via the proxy is because it just requires the SSL port 443 to be exposed. We cannot do Windows Integrated Authentication over the internet, because the ports and services required for it cannot be exposed to the internet.
- Apart from this, when accessing a resource from over the internet (using a home computer or public computer), using the logged in credentials does not help because you may not be logged in with domain credentials. Hence you may get prompted for credentials.
Another alternative to the form-based authentication is the TLS (certificate based authentication) , where the user certificate which represents the user credentials need to be present on the client workstation.
- This configuration cannot be selectively done for a set of user but need to be set as the default authentication method on ADFS proxy.
- The challenge here is that a user will only get authenticated via ADFS when he has the correct certificate, else access denied. So you have to deploy certificates to all users who access the close service via the internet.
- In this scenario too, if the client machine has multiple certificates in the user store, the user will be prompted to choose a certificate.
When outside the corpnet network, the user can choose to VPN in to the corpnet or use DirectAccess to connect to corpnet and then access ADFS as if they are connected to Intranet.
At times you may see ADFS repeatedly prompting for credentials, this could be related to “Extended protection” that is enabled for Windows Authentication for the ADFS/LS application. In IIS when Extended Protection for Windows Authentication is enabled, authentication requests are bound to both the Service Principal Names (SPN) of the server to which the client tries to connect and to the outer Transport Layer Security (TLS) channel over which Integrated Windows Authentication happens. Extended protection enhances the existing Windows Authentication functionality to mitigate authentication relay or "man in the middle" attacks. Certain browsers/fiddler cannot work with “Extended protection”, it would throw repeated prompts followed by access denied. Disabling “Extended protection” helps is such scenario.
Browser Issues with Extended Protection for Authentication
https://technet.microsoft.com/en-us/library/hh852537.aspx
More references:
Below some references to related to SSO in Office 365 environment with help of ADFS 2.0
Office 365 Single Sign-On with AD FS 2.0 whitepaper
https://www.microsoft.com/en-us/download/details.aspx?id=28971
A federated user is prompted unexpectedly to enter their credentials when they access an Office 365 resource
https://support.microsoft.com/kb/2535227
A federated user is repeatedly prompted for credentials when he or she connects to the AD FS 2.0 service endpoint during Office 365 sign-in
https://support.microsoft.com/kb/2461628
Regards
Abizer
Comments
Anonymous
January 01, 2003
The comment has been removedAnonymous
May 14, 2013
Hi Abizer, Thank you for the post. I would like to know how to use ADFS for SharePoint 2013. Requirement being A single URL for SharePoint Web Application where users can access both internally (within the organization) and over the internet with just email address & password. (organization email address)Anonymous
October 08, 2013
Abizer, In reading your blog, I am not clear if a user closes their browser, is their a way around having to put in the users credentials each time without utilizing a Remember Me "Cookie". Is this even possible? We have setup SSO with IWA, but it seems the Token Expires on each browser shut down and subsequent access to the application. Thanks for you consideration.Anonymous
November 21, 2013
What kind of hardware requirement do we need to set up ADFS in an organization? We are trying to implement SSO for our internal users to internal web apps and other public facing apps. Any feedback would be helpfulAnonymous
November 27, 2013
Hi Abizer Thanks for the article. I have a quick question. I have an ADFS server and federated domains. There is a publicly available Sharepoint site, where users come in and provide a domain login credentials that belong to one domain. The complexity is that there are users who come from outside organizations to login to the site and use the domain credentials. The account they use to login is from the same AD. However the external users will be using machines that are home/office systems, i.e, they will be workgroup machines or domain joined machines from domains that are not part of the federation. How can I implement a SSO solution for this? Should I use a forms based authentication or use a redirect for the external user to get redirected to the ADFS proxy? Please help!!! Any documentation will be equally appreciated. Regards, DipanAnonymous
January 27, 2014
Hi, in the case of sharepoint, and IWA, there are no ports to open apart from 443 right?As the authentication will occur in the ADFS proxy, afaik.Anonymous
March 03, 2014
I second Sunny's question!Anonymous
June 01, 2015
I absolutely love your blog and find nearly all of your post’s to be precisely what I’m looking for.
http://staygreenacademy.com/sharepoint-certification-training/">SharePoint 2013 Certification Training OnlineAnonymous
July 09, 2015
If when using Fiddler to trace requests and responses to ADFS you keep getting prompted for credentialsAnonymous
September 29, 2015
We have a SharePoint 2010 extranet where users authenticate using AD FS 2.0 and SAML. Works great, except when users open a Word document in SharePoint, they are prompted again for credentials when MS Word 2010 loads. Is there a way to have their session credentials passed to Word so a second login is not required?