集成 Windows 身份验证
我们在使用 IIS 进行集成 Windows 身份验证时遇到了一些非常奇怪的问题，我不确定是否可以看到某种模式。
我们有一个名为 Fred 的 DNS-Cname 记录。 我们有一个 IIS 网站，并将 Fred 设置为主机标头。 当我连接到此站点时，系统会提示我进行凭据质询。 我希望我的凭证能够通过。 如果我输入我的凭据，我就会被授予访问权限。
然后，我创建一个名为 Betty 的本地主机条目，并将主机文件指向与 Fred 相同的 IP 地址，并将主机标头更改为 Betty。 任何地方都没有关联的 CName 记录。 当我访问 Betty 时，我会自动进行身份验证，一切都很好。
如果我尝试绕过 CName 记录并在本地主机文件中创建一个名为 Fred 的条目，并将主机标头更改回 Fred。 我仍然收到身份验证质询。
据我所知，它有两个问题。 此 CName 记录如何影响这里的解析，或者它是否是一个转移注意力的内容。 其次，这个挑战发生了什么？ 我们在其他地方也有类似的症状，我们担心我们的身份验证令牌在某处被破坏。 有人可以演练身份验证发生的顺序，即哪些数据包发送到哪些机器。 有什么方法可以追踪这个吗？ （我在想 WireShark 或类似的东西）。 如何证明我的身份验证令牌已通过且有效？
We're experiencing some really strange problems with Integrated Windows Authentication with IIS and I'm not sure if I can see a pattern or not.
We have a DNS-Cname record called Fred. We have an IIS website with Fred set as the host header. When I connect to this site I get prompted with a credential challenge. I would expect my credentials to have been passed through. If I enter my credentials I am granted access.
I then create a local host entry called Betty and point the host file to the same IP address as Fred and change the host header to Betty. There is no associated CName record anywhere. When I access Betty I am authenticated automatically and everything is fine.
If I attempt to bypass the CName record and create an entry in the local host file called Fred and change back the host header to Fred. I still receive an authentication challenge.
As I see it have two questions. How is this CName record affecting the resolution here or is it a red herring. Secondly what is happening with this challenge? We have similar symptoms elsewhere and our concern is that our authentication token is getting blatted somewhere. Could someone walkthrough the order in with Authentication occurs i.e. what packets are sent to what machines. Is there a way I can trace this? (I'm thinking WireShark or something similar). How can I prove my authentication token is getting passed and is valid?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
出现身份验证框的原因很简单：Internet Explorer 仅在认为主机位于“本地 Intranet”区域（假定默认配置）时才发送您的凭据。 如果 IE 认为“本地”之外的主机要求 NTLM 凭据，则会出现一个身份验证框，您必须手动进行身份验证。
如果您希望自动发送您的凭据，请确保 IE 将其视为“本地 Intranet”。 检查状态栏最右侧的区域信息以查看当前活动的区域。
IE 会考虑多种因素来决定主机是否被视为“本地 Intranet”：
我怀疑您的主机“fred”不满足条件#2 到#4，但您的测试用例“Betty”却满足了。
名称解析的方式（CName 记录、A 记录、主机文件、其他）没有区别，因为名称解析的方法对于调用应用程序来说是不透明的。 IE 只需请求名称“XYZ”并获取 IP 地址即可。
不过，最近的配置更改可能需要您清除本地 DNS 缓存。 偶尔使用 ipconfig /flushdns 会有所帮助，或者您也可以停止 DNS 客户端服务一段时间。
所描述的内部逻辑应用于主机名，并且安全设置根据结果进行更改。
The reason for the authentication box is simple: Internet Explorer sends your credentials only if it thinks the host is in the "Local Intranet" zone (default configuration assumed). If a host outside what IE deems to be "local" asks for NTLM credentials, an authentication box will appear, and you have to authenticate manually.
If you want your credentials to be sent automatically, make sure IE thinks it in "Local Intranet". Check the zone info far right on the status bar to see the currently active zone.
IE takes into account multiple things in order to decide whether a host is to be considered as "Local Intranet":
My suspicion is that your host "fred" does not fulfill conditions #2 through #4, but your test case "Betty" somehow does.
What way the name was resolved (CName record, A record, hosts file, other) makes no difference, because the method of name resolution is opaque to the calling application. IE just asks for name "XYZ" and gets an IP address back.
Recent configuration changes can require you to clear the local DNS cache, though. An occasional
ipconfig /flushdnswould help here, alternatively you can stop the DNS Client service for a while.The described internal logic is applied to the host name and security settings change based on the outcome.
CName 会转移注意力。 对 Windows Auth 没有影响。
追踪它的最简单方法是使用 fiddler。 您应该看到您的请求后跟 401 响应（它包含服务器支持的身份验证），然后再次发送您的请求以及身份验证详细信息（或者系统会提示您，然后发送）
CName would be a red herring. Has no effect on Windows Auth or not.
The easiest way to trace it is with fiddler. You should see your request followed by a 401 response (it contains the authentication the server supports), then your request again is sent with the authentication details (or you are prompted and then it's sent)