机器未请求Sharepoint网站(IE,Chrome,Edge)的kerberos票证,Firefox则获得了票证 [英] Machine not requesting kerberos ticket for Sharepoint site (IE, Chrome, Edge), Firefox gets ticket

查看:75
本文介绍了机器未请求Sharepoint网站(IE,Chrome,Edge)的kerberos票证,Firefox则获得了票证的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在公司发行的笔记本电脑的全新图像中,我们发生了一件非常奇怪的事情.我们将其范围缩小到了特定的计算机(和图像),因为在任何其他计算机上获取kerberos票都没有错 (此特定图片除外).

这台特定的机器正在为我们的本地Exchange Webmail(OWA)获取一张kerberos票.但是,当访问我们的Sharepoint网站时,进行klist操作时,根本没有票证.
为了确保它不是用户,我们让他们使用另一台计算机登录,并且确实获取了他们的kerberos票证.我以我本人的身份登录了故障机器,也没有得到人字票.

这台机器为什么无法在Chrome,IE,Edge上为我们的本地Exchange服务器获得Webmail OWA kerberos票,却没有为Sharepoint获得Webmail OWA票,这是没有道理的.
我们还尝试将所有IE Internet选项设置重置为默认值.我们已经比较了本地Intranet设置,确保我们的域在本地Intranet的允许的站点"中.使用Edge,Chrome或IE,会弹出400个身份验证登录框.

在Firefox中,如果将域添加到TrustedURIs中,则确实会获得kerberos票证,但该票证似乎仅在Firefox中有效.使用IE,Chrome或Edge仍会显示400身份验证登录框提示.

我们尝试使用Fiddler和Wireshark来查看请求,而在使用IE,Edge或Chrome时,没有看到任何去我们的域控制器抢票的人.

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?

推荐答案

您可以做几件事,但都无害:)

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

1.在有问题的PC上刷新DNS

1. Flush DNS on problematic PC's

2.清除Klist

2. Purge Klist

然后,如果身份验证是kerberos并且未默认为NTLM,则尝试像使用Fiddler一样进行跟踪.从WFE,您还可以在Windows日志下验证安全认证是否为kerberos.据我所知,Firefox在此方面的行为确实很奇怪 场景.

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.

希望这会有所帮助


这篇关于机器未请求Sharepoint网站(IE,Chrome,Edge)的kerberos票证,Firefox则获得了票证的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆