Sign up for Office 365
Learn more about Office 365
I have customer who is only interested in Sharepoint aspect of Office 365 that they want to access through IE8 using SingleSignon.
I have ADFS deployed with a public certificate for SingleSignon. DirSync is complete and I have enabled the users. Lets say TestUser1@<MyDomain>.Com.
I login to a domain joined computer on-premisis using the domain account TestUser1 credentials.
When I browse to sharepoint site on 365 from IE8 - <onmicrosoft name>.SharePoint.Com -
I get the following prompts:
1. Prompt from Microsoft Online Service for user name.
2. I click on TestUser1@<MyDomain>.Com and it gives me a link to my ADFS Server.
3. When I click on ADFS link - the ADFS server prompts me for a login screen and I have to reenter my credentials.
Thats when I get access to the sharepoint site. This is happening at every login.
Kind of defeats the purpose of single signon. Any idea on how to resolve this?
Thanks for the feedback.
1 out of 1 people found this post helpful.
This is annoying. I was reading this thread:
While I had forms based auth on. I removed "Negotiate" from the windows authentication scheme. I retried, it failed. I put it back. I disabled forms based authentication (because it shouldn't be on)
Now, it's working. Visually, this is out of the box. However, I am very suspicious that removing and re-adding negotiate to the windows authentication scheme might have triggered something.
Are you meaning there need twice credentials when you try to access SharePoint Online in a Single Sign On environment? If so, please take the following steps for troubleshooting this issue:
Also ensure that your ADFS URL (e.g. https://sts.mydomain.com) is part of your intranet zone in IE. You will need it to be in that for AD FS 2.0 to not prompt your for credentials and use kerberos to login. Also note that this is only a feature of IE.
Have you deployed a ADFS proxy or tweaked with the web.config file?
If you look in this file under c:\inetpub\adfs\ls\web.config you will find:
<add name="Integrated" page="auth/integrated/" />
<add name="Forms" page="FormsSignIn.aspx" />
<add name="TlsClient" page="auth/sslclient/" />
<add name="Basic" page="auth/basic/" />
Changing the order of authentication mechanisms above will control what ADFS uses.
Now IWA is primary and Forms secondary.
If I remember correctly the ADFS Proxy installs with Forms first.
How are things going? Is everything working properly now?
I do not wish to hijack this thread, but I am suffering from the same issues. I have deployed a federation server, and proxy.
I pointed my external DNS to the proxy. This seems to work okay, when I login, I get a form, but it works.
Now, internally, DNS is pointed to the federation server. When i login, I am prompted (pop up) for username and password.
I have made MOS trusted, and my domain is local intranet.
This does not happen in FF, only in IE. So, I am sure it is just some kind of a configuration setting, but it has stumped me so far.
Likewise, Lync will not log me in, for what I assume is the same reason.
Is this the right approach?
This is because you don't have IE settings enabled for your ADFS URL to be refferred to as an INTRANET zone. Could you ensure that the URL for your ADFS server (e.g. https://sts.contoso.com) is in your INTRANET zone and try again?
Only with this will IE allow you to release your windows credentials automatically. If not, you will get the NTLM prompt.
Could you try and reply?
My entire local domain *.domain.com is assigned to the intranet zone.
The issue may occur if there is something configured incorrectly with your internal Federation Server. Please try to fix it according to the article below:
I did look at the article. It points out a few things:
There does not appear to be any events logged when this occurs. The last part of the article discusses enabling tracing logs, and the command given is so far off, I don't know even know what to do with it:
Click Start, click Run, type wevutil.exe AD FS 2.0 Tracing/Debug /l:5, and then press ENTER.
The command is wevtutil.exe, and AD is not a command for it. (The expected first argument)
I am going to continue researching the error above! Thanks for the help!
I removed Forms-based authentication on the federation server. It should not be abled:
"Challenge-based and login redirect-based authentication cannot be used simultaneously"
I don't understand why it would suggest a resolution that conflicts with the authentication requirements.
So, I am back to the original issue and troubleshooting!
Look in the eventlog (security) on the ADFS server and DC for login attempts by the user you are using. If there are problems using Kerberos i have had problems logging into ADFS using the Negotiate function of IIS.
I am glad to hear that the issue has been resolved. Thanks for your step by step update in the forum. It is really a good behavior and this is so others who have the same problem could clearly understand what you have done.
If you have any other questions, would you please open a new thread to ask?
So I did a reinstall and set up ADFS as a farm with a dedicated domain user account for the application pool.
I ran into the same problem that you are describing here....I would be prompted for authentication again and again from the ADFS server.
This problem was because of incorrect Service Principal Name on the service account.
My adfs server is named adfsserver.domain.com, but I have published it under the name connect.domain.com (ADFS URL). So I deployed a CNAME in my DNS pointing connect.domain.com to adfsserver.domain.com.
The clients are connecting to connect.domain.com...so the correct SPN to register on the service account for the ADFS application pool is HTTP/adfsserver.domain.com
Correcting this made Kerberos work and I was no longer prompted for credentials.
Also if it's still not working after all this, you most likely have duplicate SPNs registered on HTTP/adfsserver.domain.com. Just use setspn -X (only on w2k8) and a printout of duplicates are given.
Also note there are some disagreements with using CNAMEs; for backward comparability use A-records instead. The SPN to register would in this scenario be connect.domain.com instead of adfsserver.domain.com. The A-record to create is connect.domain.com pointing to the IP-address of adfsserver.domain.com
PS! Always remember to restart the ADFS service after changes to SPN are done, it is not enough to stop/start IIS application pool.
Hope this helps someone else ;)
I try and shy away from CNAME as there have been issues with IE in the past; with CNAME and Kerberos where IE follows the CNAME rather than the intended Kerberos SPN.
Just thought you should know.