Iis 为什么WinINET在使用Windows身份验证时响应身份验证请求时从使用Kerberos改为使用NTLM？_Iis_Kerberos_Ntlm_Loadrunner_Wininet

Iis 为什么WinINET在使用Windows身份验证时响应身份验证请求时从使用Kerberos改为使用NTLM？

iis

Iis 为什么WinINET在使用Windows身份验证时响应身份验证请求时从使用Kerberos改为使用NTLM？,iis,kerberos,ntlm,loadrunner,wininet,Iis,Kerberos,Ntlm,Loadrunner,Wininet,我们目前正在使用Loadrunner 11.52对IIS8.5（在Windows 2012R2上）中托管的Sharepoint环境进行负载测试。我们正在使用基于WinINET的重播机制，因为在尝试使用LR套接字实现时存在SSL问题站点的身份验证设置为允许Windows身份验证。这些用户都是唯一的Active Directory用户我们有一个问题，在启动50个用户后，由于用户无法进行身份验证，用户开始失败我们使用Fiddler捕获了成功（前50个用户）身份验证和不成功（前50个用户之后的用户

我们目前正在使用Loadrunner 11.52对IIS8.5（在Windows 2012R2上）中托管的Sharepoint环境进行负载测试。我们正在使用基于WinINET的重播机制，因为在尝试使用LR套接字实现时存在SSL问题

站点的身份验证设置为允许Windows身份验证。这些用户都是唯一的Active Directory用户

我们有一个问题，在启动50个用户后，由于用户无法进行身份验证，用户开始失败

我们使用Fiddler捕获了成功（前50个用户）身份验证和不成功（前50个用户之后的用户）身份验证

在最初加载网页时，服务器返回一个401，其中包含预期的身份验证头：

请求：

GET https://myserver/Pages/default.aspx HTTP/1.1
Cookie: WSS_FullScreenMode=false
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT)
Accept-Encoding: gzip, deflate
Accept: */*
Host: myserver
Connection: Keep-Alive
Cache-Control: no-cache

答复：

HTTP/1.1 401 Unauthorized
Content-Type: text/plain; charset=utf-8
Server: Microsoft-IIS/8.5
SPRequestGuid: ad71f69c-0b10-d049-46c6-1f0b1f7bd574
request-id: ad71f69c-0b10-d049-46c6-1f0b1f7bd574
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 2
SPIisLatency: 0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4667
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Thu, 26 Mar 2015 07:13:44 GMT
Content-Length: 16
Proxy-Support: Session-Based-Authentication

401 UNAUTHORIZED

HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Content-Type: text/html; charset=utf-8
Expires: Wed, 11 Mar 2015 07:13:44 GMT
Last-Modified: Thu, 26 Mar 2015 07:13:44 GMT
Vary: Accept-Encoding
Server: Microsoft-IIS/8.5
X-SharePointHealthScore: 0
X-AspNet-Version: 4.0.30319
SPRequestGuid: ad71f69c-db17-d049-46c6-15c51828a26e
request-id: ad71f69c-db17-d049-46c6-15c51828a26e
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 40
SPIisLatency: 0
WWW-Authenticate: Negotiate oYGzMIGwoAMKAQChCw...<long auth token>...=
Persistent-Auth: true
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4667
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Thu, 26 Mar 2015 07:13:44 GMT
Content-Length: 80492


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html dir="ltr" lang="en-US">
<head><meta name="GENERATOR" content="Microsoft SharePoint" /><
...

然后，WinINET会适当地处理此问题，并返回一个Kerberos身份验证令牌，服务器接受该令牌：

GET https://myserver/Pages/default.aspx HTTP/1.1
Cookie: WSS_FullScreenMode=false
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT)
Accept-Encoding: gzip, deflate
Accept: */*
Host: myserver
Connection: Keep-Alive
Cache-Control: no-cache
Authorization: Negotiate YIISMQYGKwYBBQUCoIISJTCCEiGgMDAuB...<long-auth-token-string>...=

响应（与以前成功的用户相同）：

然后，客户端发送身份验证请求：

GET https://myserver/Pages/default.aspx HTTP/1.1
Cookie: WSS_FullScreenMode=false
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT)
Accept-Encoding: gzip, deflate
Accept: */*
Host: myserver
Connection: Keep-Alive
Cache-Control: no-cache
Authorization: Negotiate TlRMTVNTUAABAAA...<short NTLM auth token>...==

此时，WinINET似乎放弃了，并将401传递给LoadRunner，然后LoadRunner会让用户失败

前50名用户继续正常工作。我们还可以通过IE手动加载另一个用户，而这50个用户仍在运行。我们也可以等待一段时间，最终我们可以启动更多的用户

因此，这里似乎有两个问题：

为什么在启动了50个用户之后，WinINET会更改为使用NTLM auth而不是Kerberos

为什么服务器拒绝NTLM身份验证如果您有任何关于可能导致这种情况的想法，以及/或者我如何进一步调查，我们将不胜感激。我的怀疑是，可能是某种Active Directory限制在50个用户经过身份验证后的一段时间内阻止了Kerberos的工作，但是我不知道如何证明/反驳这一点

谢谢

我知道这是很久以前发布的，但这可能是你的广告服务器的问题吗？可能WinINET在联系AD获取Kerberos票证时遇到问题，因此它无法返回到NTLM。您曾经解决过这个问题吗？是的，它与此类似-确实有一些限制（广告团队从未解释到底是什么）导致Kerberos失败。NTLM auth不允许访问请求，只是401次失败

HTTP/1.1 401 Unauthorized
Content-Type: text/plain; charset=utf-8
Server: Microsoft-IIS/8.5
SPRequestGuid: 6a71f69c-6b4f-d049-46c6-1e90257415f1
request-id: 6a71f69c-6b4f-d049-46c6-1e90257415f1
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 1
SPIisLatency: 0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4667
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Thu, 26 Mar 2015 07:09:10 GMT
Content-Length: 16
Proxy-Support: Session-Based-Authentication

401 UNAUTHORIZED

GET https://myserver/Pages/default.aspx HTTP/1.1
Cookie: WSS_FullScreenMode=false
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT)
Accept-Encoding: gzip, deflate
Accept: */*
Host: myserver
Connection: Keep-Alive
Cache-Control: no-cache
Authorization: Negotiate TlRMTVNTUAABAAA...<short NTLM auth token>...==

HTTP/1.1 401 Unauthorized
Server: Microsoft-IIS/8.5
WWW-Authenticate: Negotiate TlRMTVNTUAACAAAACAAIADgAAAAVgonicMgf76hzy7QAAAAAAAAAAL4AvgBAAA...<long NTLM auth token>=
SPRequestGuid: 6a71f69c-cb6b-d049-46c6-14cbc16d1ea9
request-id: 6a71f69c-cb6b-d049-46c6-14cbc16d1ea9
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 1
SPIisLatency: 0
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4667
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Thu, 26 Mar 2015 07:09:10 GMT
Content-Length: 0
Proxy-Support: Session-Based-Authentication

GET https://myserver/Pages/default.aspx HTTP/1.1
Cookie: WSS_FullScreenMode=false
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT)
Accept-Encoding: gzip, deflate
Accept: */*
Host: myserver
Connection: Keep-Alive
Cache-Control: no-cache
Authorization: Negotiate TlRMTVNTUAADAAAAGAAYAKIAAACEAYQBu...<much longer NTLM token>...=

HTTP/1.1 401 Unauthorized
Server: Microsoft-IIS/8.5
SPRequestGuid: 6a71f69c-cb6b-d049-46c6-18ce53703ae9
request-id: 6a71f69c-cb6b-d049-46c6-18ce53703ae9
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 236
SPIisLatency: 0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4667
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Thu, 26 Mar 2015 07:09:10 GMT
Content-Length: 0
Proxy-Support: Session-Based-Authentication