No one has responded to this discussion for at least a year, so this information may be out of date. If you're looking for information about this topic, please search for a more recent discussion or post a new question.

SSO Authentication failure - ADFS keeps on prompting for credentials

  • 20 Replies |
  • This post has 0 verified answers |
Answered (Not Verified) This question has suggested answer(s)

I'm having a problem with my ADFS implementation :

When I attempt to connect to Office 365 (through using a federated user the browser keeps on prompting for my credentials even though I've correctly filled in the fields.

  • I have installed ADFS on  my server and configured the trust
  • My IIS server is enabled, I have applied my certificate onto the default website, the binding has been set up correctly
  • I have installed on my 2nd server the dirsync tool, which works fine
  • My domain has been correctly federated through PowerShell
  • My DNS records are correct (expect for the Lync Online part)

I don't have any error message in my Event Viewer

Thanks for your help !

  • Post Points: 20
All Replies
  • Hello Jerome Couzy,

    I'm sorry to hear that you are having difficulty getting Identity Federation with ADFS setup for Single Sign On (SSO) with Office 365. Please use the Office 365 tab at the following tool to test SSO for your organization and update your post with the error you receive to help provide more information about the location of this failure:

    Once we have that information we will continue to troubleshoot this issue.


    (Please also make sure that you have the Office 365 sign in assistant installed from the following links: (Sign In Assistant download and setup) (Sign In Assistant download only)

    You can also see: for setup a full list of the setup instructions for ADFS.)

    • Top 150 Contributor
    • Post Points: 0
  • Hello Micah;

    I have been using this tool for a while, but for some reason it has stopped working a few days ago (no more than a week), whatever browser I use.

    I also confirm, I have installed the Sign in assistant before facing that issue.

    Thanks for your help !

    • Not Ranked
    • Post Points: 0
  • I have seen this two times myself..but only when my ADFS was not accesible from the outside.

    Can you please look into the IIS logs on the ADFS server and look for 401 (access denied from the source you are connecting from)..found at c:\inetpub\log\..\W3SVC\..

    • Not Ranked
    • Post Points: 0
  • Hi Lerun,

    You're right I actually have 401 error in my IIS log file. Here is the end of the file :


    Also, I have through a lot of different scenarios and it turned out that I'm getting the credentials prompt only chile trying to access the site from a non domain-joined computer, and on both my domain-joined servers, I don't even get this page...

    • Not Ranked
    • Post Points: 0
  • So I see a 401.2 error, this means that IE and IIS can not agree on the authentication scheme.

    So try this:

    in IIS go to the /adfs/ls node

    Go into Authentication (if this is IIS 7 or newer)

    Right click Windows Authentication (make sure this is enabled by default) and choose providers

    Remove all but NTLM

    Restart IIS and rescycle the ADFS app pool

    Try to connect again...and see if you are still getting 401.2 errors in the log.

    • Not Ranked
    • Post Points: 0
  • Hi Jerome,

    Is the URL of the AD FS server in the local Intranet zone or in the Trusted Sites zone with automatically logon using username/password set? As Lerun said you could go the NTLM route but I'd stick with the default SPNEGO/Negotiate authentication in IIS. This is there so that the browser can negotiate authentication with IIS, doing Kerberos first and then downgrade authentication to NTLM should the need arise. For domain-joined machines (if the URL of the AD FS instance is in the Local Intranet Zone) then Web SSO should work when accessing O365 from the corporate LAN. If you're connecting with a non-domain joined machine then the challenge/response prompt from the browser kicks in as it reverts to NTLM. Downgrading to NTLM just means that you have a consistent experience with an older less secure protocol :-)






    Infrastructure / PKI / Access Management (Blog)

    • Top 500 Contributor
    • Post Points: 0
  • I would advice the same, the NTLM test was just to get a working baseline.

    You could have some Kerberos challenges.

    I found that if you are connecting from outside your local net, and using no ADFS proxy I would hit a 401.2 scenario.

    This with the ADFS server in the local intranet zone of IE.

    This would somehow break negotiation with IIS, and just using NTLM would make it work again.

    For clients in the local net Negotation was working as expected with Kerberos.

    So for me Negotiation would fail if the client needed to fallback to NTLM, and me non the wiser.

    Just wanted to make sure you where not in the same situation, as you also are not using a ADFS proxy.

    If this was not so I would go with what Mylo is advising...

    • Not Ranked
    • Post Points: 0
  • Hello Jerome,

    Also, if you're still having trouble after the troubleshooting steps provided above, try opening a new service request with our Support team, as we can delve deeper through a service request and should be able to help if everything else doesn't work.

    • Top 50 Contributor
    • Male
    • Post Points: 0
    Suggested by
  • Sorry I didn't get back to you, I hadn't seen the notifications. Thanks a lot for your time !

    I should have been more accurate in my first post : the prompt problem appears with browsers other than IE (in this case both  Firefox and Chrome). When I use IE, I'm not prompted for my credentials. Thus, yes I have added the URL in the intranet zone. I will upload a screenshot of the error I get while using IE, although it's probably useless as the error code seems very standard.

    Changing the providers didn't changed a thing, the behaviour remains the same.

    Again, thank you :)

    • Not Ranked
    • Post Points: 0
  • Ah..yes

    Only IE supports SSO, you get the expected behavior from the other browsers.

    What happens if you remove the site from from IE Intranet zone and enter the correct credentials when prompted?

    • Not Ranked
    • Post Points: 0
  • Problem (almost) solved !

    Apparently the ADFS server (which was as well the AD server, that's probably my biggest mistake) was unable to request the AD therefore authentication was always unsuccessful . Had to change a key in the registry and it now works like a charm !

    Just have to figure out how to turn Chrome able to negotiate using NTLM.

    Thanks guys for your help !

    • Not Ranked
    • Post Points: 0
  • Could you mention the key you changed, and maybe an article, or clues that brought you to that change?

    • Not Ranked
    • Post Points: 0
  • Please take a look at this section of the Plan for and deploy documentation around Extended protection.  This is likely the cause of the problem.

    Utilize Extended Protection for Authentication


    If your computers have Extended Protection for Authentication, and you use Firefox, Chrome, or Safari, you may not be able to sign in to Office 365 using Integrated Windows authentication from within the corporate network. If this situation occurs, your users might receive logon prompts on a regular basis. This is due to the default configuration (on Windows 7 and patched client operating systems) for AD FS 2.0 and Extended Protection for Authentication.

    Until Firefox, Chrome, and Safari support Extended Protection for Authentication, the recommended option is for all clients accessing Office 365 services to install and use Windows Internet Explorer 8. Iyou want to use single sign-on for Office 365 with Firefox, Chrome, or Safari, there are two other solutions to consider. However, there may be security concerns in taking either of these approaches. For more information, see Microsoft Security Advisory: Extended protection for authentication. The solutions include:

    • Uninstalling the Extended Protection for Authentication patches from your computer.
    • Changing the Extended Protection for Authentication setting on the AD FS 2.0 server. For more information, see Configuring Advanced Options for AD FS 2.0.
    • Reconfiguring the authentication settings for the AD FS 2.0 webpage on each federation server from Integrated Windows authentication to using Forms Based Authentication.



    Ross Adams MSFT


    • Not Ranked
    • Post Points: 0
    Suggested by
  • Ah, forgot about that one :(

    You can also turn it off under the adfs/ls node in IIS. Right click Windows Authentication under Authentication and choose Advanced Settings. Turn off Extended Protection.... 

    Good you got it sorted.

    • Not Ranked
    • Post Points: 0
Page 1 of 2 (21 items) 1|2|