Sign up for Office 365
Learn more about Office 365
I'm having a problem with my ADFS implementation :
When I attempt to connect to Office 365 (through portal.microsoftonline.com) using a federated user the browser keeps on prompting for my credentials even though I've correctly filled in the fields.
I don't have any error message in my Event Viewer
Thanks for your help !
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:
https://portal.microsoftonline.com/download/default.aspx (Sign In Assistant download and setup)
http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff637585.aspx (Sign In Assistant download only)
You can also see: http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff652539.aspx for setup a full list of the setup instructions for ADFS.)
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.
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\..
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...
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.
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)
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...
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.
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 :)
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?
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 !
Could you mention the key you changed, and maybe an article, or clues that brought you to that change?
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.
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:
Ross Adams MSFT
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.