Machine not requesting kerberos ticket for Sharepoint site (IE, Chrome, Edge), Firefox gets ticket RRS feed

  • Question

  • We have something very strange going on with one of our brand new images for a laptop that is issued in the company. We have narrowed it down to the specific computer (and image), as there is nothing wrong with getting kerberos tickets on any other machines (other than this specific image).

    This specific machine is getting a kerberos ticket for our on-prem Exchange webmail (OWA). However, when going to our Sharepoint site, when doing a klist, there is no ticket at all.
    To make sure it was not the user, we had them log in using a different computer and it does retrieve their kerberos ticket. I logged into the broken machine as myself, and I also do not get a kerberos ticket.

    It doesn't make sense why the machine will get the webmail OWA kerberos ticket for our on-prem Exchange server in Chrome, IE, Edge, but not for Sharepoint.

    We've also tried resetting all IE Internet Options settings to the default. We've compared the Local Intranet settings, made sure that our domain is in the Allowed Sites for our Local Intranet. Using Edge, Chrome, or IE, the 400 auth login box pops up.

    In Firefox if we add our domain to the trustedURIs, it does get a kerberos ticket, but that ticket only seems to work in Firefox only. Using IE, Chrome, or Edge, still comes up with the 400 auth login box prompt.

    We've tried using Fiddler and Wireshark to look at the requests, and not seeing any going to our domain controller to grab the ticket when using IE, Edge, or Chrome.

    Is there something else that could be preventing this?
    Wednesday, February 28, 2018 8:26 PM

All replies

  • There are couple of things you can do, both are harmless :)

    1. Flush DNS on problematic PC's

    2. Purge Klist

    Then try to trace like you did with Fiddler if authentication is kerberos and not defaulting to NTLM. From WFE you can also verify under windows log, security authentication is kerberos. As far as I know Firefox behave really weird when it comes to this scenario.

    Hope this helps 

    Wednesday, February 28, 2018 8:46 PM
  • Thanks Asfaw!

    We have flushed DNS and purged the Klist, only to get same result. I think we have another meeting coming up soon to look at it.

    It's just strange that it's that specific machine. Very strange that Firefox will request and receive a ticket. Even more strange that IE, Edge, Chrome won't request ticket at all.

    Thursday, March 1, 2018 5:50 PM
  • We may have found out what the issue was, but we'll need to find a working machine and compare it to some of the newer machines.

    In Internet Options under Trusted Sites and in Custom Settings, at the very bottom under User Authentication the option "Automatic logon only in Intranet zone" was checked.

    If we click the option below, "Automatic logon with current user name and password" then we can log into the Sharepoint site without the NTLM authentication popup box. 

    I am not sure if this is normal behavior though, it does fix it.

    Friday, March 2, 2018 2:52 PM
  • That setting will allow users to automatically logon not only to "Intranet" but also to "Internet". It has it's own security concern. Kerberos always fascinates me :) Most secure but got lot of challenge. 

    How's your site setup? does it have like "", some folks are saying due to "dot" presence Ie or chrome treat the site as "Internet" and that was the reason you get authentication challenge. 

    Friday, March 2, 2018 4:58 PM
  • Yeah, it is very strange. I had to get a new computer yesterday, and the new computer is doing exactly the same. I went and looked at my old computer and the "Trusted Sites" authentication is also set to "Automatic Logon Only in Intranet Zone", but it works. It's very confusing.

    But you are correct it is set up that way:

    Friday, March 2, 2018 5:45 PM
  • Another few check points

    1. Short Url need to resolve, i.e. https://sharepointchannel function normally. Test if users experience same issues. 

    2. Verify in central admin under AAM setting your site listed as intranet 

    3. SPN need to be configured for both https://sharepointchannel and

    Hope this helps

    Friday, March 2, 2018 6:12 PM
  • The SPN only needs to be configured for the hostname or FQDN in use. This is counter to the typical advise given for SQL Server; with HTTP SPNs, just the exact SPN is fine. That is, if you're listening on, all you need is HTTP/ as an SPN.

    Trevor Seward

    Office Servers and Services MVP

    Author, Deploying SharePoint 2016

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Sunday, March 4, 2018 4:04 AM
  • Good to know. I used to configure HTTP SPN for both FQDN and short. 
    Monday, March 5, 2018 4:59 PM
  • :) Jrmoat, you said you've done a wireshark trace. Have you done this from the client and SharePoint server at the same time? Do you see any Kerb traffic between the two?

    Trevor Seward

    Office Servers and Services MVP

    Author, Deploying SharePoint 2016

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Monday, March 5, 2018 5:06 PM
  • Interesting! Thanks, good information above. Wireshark trace only done from client side. Sounds like the SharePoint Server side needs to be done simultaneously...

    From what I remember, no request kerb traffic on client side. It doesn't seem like it would go back to the DC and grab a ticket.

    • Edited by jrmoat Thursday, March 8, 2018 8:54 PM
    Thursday, March 8, 2018 8:35 PM
  • Hi jrmoat,

    If the post helps you, you can mark it as answer.

    Have a nice day!

    Best regards,

    Grace Wang

    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Wednesday, March 14, 2018 3:48 AM
  • Thank you, Grace! It is helpful, however, since Wireshark shows that there are isn't kerberos ticket traffic, the machine is definitely not going out and requesting a ticket at all from the domain controller. I'm not sure why a machine would not go out to request a kerb ticket, unless it defaults to the other authentication method and never tries to do kerberos.

    • Edited by jrmoat Tuesday, March 20, 2018 6:05 PM
    Tuesday, March 20, 2018 6:04 PM