Sharepoint 2016 - different authentication behavior on Win10 vs. Windows 8.1
Hi experts.
Given: 2 sharepoint systems (test and production), both https and kerberos authentication active. SQL 2016, Windows Server 2016. Single sign on works when editing existing documents on both systems in all browsers (Edge/Chrome/IE11/FFox)
However, when creating a new document directly in the library (->file ->new document), win10 asks for authentication on any machine with any user and browser (and on both sharepoint systems). After authenticating, creation works, but that step is annoying.
And on win8.1 systems, it does not ask for authentication, no matter what user or machine or browser. We have no idea why, since there are no settings especially for win10.
What does win10 do differently?
Given: 2 sharepoint systems (test and production), both https and kerberos authentication active. SQL 2016, Windows Server 2016. Single sign on works when editing existing documents on both systems in all browsers (Edge/Chrome/IE11/FFox)
However, when creating a new document directly in the library (->file ->new document), win10 asks for authentication on any machine with any user and browser (and on both sharepoint systems). After authenticating, creation works, but that step is annoying.
And on win8.1 systems, it does not ask for authentication, no matter what user or machine or browser. We have no idea why, since there are no settings especially for win10.
What does win10 do differently?
ASKER
Hi.
"Does this happen *every* time a user clicks "new document" or just the first time?" - just the 1st time.
"Is the URL of the site using an FQDN?" - yes. But the site is added to trusted sites and for those, current credentials (sso) should be used
"Office Online Server" - not being used.
"I'd check the Credential Manager on the user's computer, as this is where the cached credentials are stored." - no credentials are stored.
"Kerberos - I'd recheck your configuration" - is setup alright. You can see the kerberos tickets being issued and also, if you test with chrome on Linux and disable kerberos ("negotiate") authentication using the registry, you cannot authenticate, becausechrome on Linux ONLY knows kerberos and not NTLM. Conclusion: kerberos is being used.
"fiddler" - will try.
"ULSViewer" - already tried but could not make out the problem. Might retry.
"Does this happen *every* time a user clicks "new document" or just the first time?" - just the 1st time.
"Is the URL of the site using an FQDN?" - yes. But the site is added to trusted sites and for those, current credentials (sso) should be used
"Office Online Server" - not being used.
"I'd check the Credential Manager on the user's computer, as this is where the cached credentials are stored." - no credentials are stored.
"Kerberos - I'd recheck your configuration" - is setup alright. You can see the kerberos tickets being issued and also, if you test with chrome on Linux and disable kerberos ("negotiate") authentication using the registry, you cannot authenticate, becausechrome on Linux ONLY knows kerberos and not NTLM. Conclusion: kerberos is being used.
"fiddler" - will try.
"ULSViewer" - already tried but could not make out the problem. Might retry.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Also, McKnife, didn't you have an issue with some of your workstations having a custom registry setting that interfered with dragging and dropping to a document library? You said it had been deployed to all workstations to force a compatibility mode for an old website. Could that also be at play here?
ASKER
Sso is working just the same with trusted and intranet, at least here.
Same behavior for any browser.
Office version is the same on 8.1 and 10: 2010. Turning off kerberos will be tried tomorrow.
Thanks so far. My simple guess is still: Bug in 10, works on 8.1.
Same behavior for any browser.
Office version is the same on 8.1 and 10: 2010. Turning off kerberos will be tried tomorrow.
Thanks so far. My simple guess is still: Bug in 10, works on 8.1.
ASKER
About the regkey: No, it's already deleted.
ASKER
It's office 2010!
Office 2010 (word2010 in this case) behaves differently on win8.1 and win10, while word 2016 behaves alright on both OS'.
I will surrender I guess and vote to upgrade to o2016 sooner than we had planned. There are other strange problems with O2010 and sharepoint that don't exist with O2016.
I will close this before I could dive into the suggestions.
Office 2010 (word2010 in this case) behaves differently on win8.1 and win10, while word 2016 behaves alright on both OS'.
I will surrender I guess and vote to upgrade to o2016 sooner than we had planned. There are other strange problems with O2010 and sharepoint that don't exist with O2016.
I will close this before I could dive into the suggestions.
ASKER
Thank you. Your guess "I would guess that the Office app--not the browser--is where the user is getting the login prompt, since the app needs its own session with the SharePoint site. This behavior might also be different depending on which version of Office you are running" was correct. I will _not_ wonder why but simply file it under "microsoft". Since we planned to move to 2016 pretty soon, we could also do it this spring.
My pleasure! :D
Is the URL of the site using an FQDN? FDQN sites are treated as Internet sites by Internet Explorer, unless you add them to the Local Intranet Zone. Then the users' Windows login credentials are automatically passed to IIS. I don't know that Chrome or Firefox are able to do this by default. I think Chrome has a hidden setting that emulates this behavior but it's not enabled by default. Anyway it's something to test, if the URL is in the Local Intranet zone, does the user still get a login prompt?
Note that if you're using Office Online Server for in-browser document creation/editing, that traffic is being sent to another server (where OOS is installed). Normally this doesn't require the user to provide any credentials because it's a server-server connection. However, if you're dealing with Excel (e.g. Data-connected spreadsheets or PowerPivot), then that's a whole new can of worms that involves constrained Kerberos delegation and/or human sacrifice to get it working. I have an SP 2016 project underway with OOS and I haven't quite gotten PowerPivot/Kerberos working yet. My users are not getting login prompts, though.
So, some things to check. I would start out by using a tool called Fiddler to monitor client/server HTTP traffic. Here you can examine headers and determine the negotiation process when a user clicks "New" in a document library. Typically they see a login prompt whenever an HTTP 401 error occurs. You can look at the headers and might see what the problem is. You could also use NetMon or WireShark to examine packets.
You can also check ULS logs, using ULSViewer in ULS mode (plugged in to the live events as they happpen). Reproduce the problem and then pause the ULS log. See if you find any events regarding authentication. You may need to turn up the verbosity to see more events.
Kerberos is a tricky thing to get working right, and if this is your first time using it, I'd recheck your configuration. I haven't played with Kerberos for a few years (although for one project I set it up completely for a SharePoint 2010 business intelligence solution). As I said, I am still in the process of setting up Kerberos for my new SP 2016 farm, because it's not working quite right.
I don't know why there would be a difference between a Windows 8.1 client and a Windows 10 client. I'd check the Credential Manager on the user's computer, as this is where the cached credentials are stored.