如何解决asp.net core 2.1的集成身份验证问题
对使用Visual Studio 2017发布发布到IIS的asp.net core 2.1.x应用程序的页面请求,返回HTTP错误401.2-未经授权。 IIS服务器应用程序配置为仅使用集成身份验证。 IIS Manager Window Snippet
在代码段中,默认网站/ OrderTrackingService是通过Visual Studio调试创建和配置的应用程序。开发门户/订单跟踪是通过Visual Studio中的发布配置文件发布的同一应用程序。
据我所知,IIS中的Web应用程序配置是相同的。 当我在调试器下运行应用程序时,使用IIS或IIS Express,传入的请求具有授权标头
No Proxy-Authorization Header is present.
Authorization Header (Negotiate) appears to contain a Kerberos ticket:
60 81 84 06 06 2B 06 01 05 05 02 A0 7A 30 78 A0 `..+..... z0x
30 30 2E 06 0A 2B 06 01 04 01 82 37 02 02 0A 06 00...+....7....
09 2A 86 48 82 F7 12 01 02 02 06 09 2A 86 48 86 .*H÷......*H
F7 12 01 02 02 06 0A 2B 06 01 04 01 82 37 02 02 ÷......+....7..
...
当我直接从IIS运行应用程序(由publish和IIS设置配置)时,传入的请求没有授权标头
No Authorization Header is present.
有人可以告诉我如何确定为什么在一种情况下出现标头而在另一种情况下丢失标头吗?
更新: 我还有一些其他信息,可能有助于跟踪问题。当通过Visual Studio调试对IIS设置的Web应用程序发出请求时,会出现一系列HTTP请求/响应,其中提供了auth标头并建立了用户身份。
-请求/响应
GET http://.../ordertrackingservice HTTP/1.1
Host: ...
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: .AspNet.Consent=yes
HTTP/1.1 401 Unauthorized
Cache-Control: private
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/10.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
Date: Tue, 02 Oct 2018 16:32:36 GMT
Content-Length: 6138
Proxy-Support: Session-Based-Authentication
** -请求/响应 **
GET http://.../ordertrackingservice HTTP/1.1
Host: ...
Connection: keep-alive
Cache-Control: max-age=0
授权:协商YIGEBgYrB。...
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: .AspNet.Consent=yes
HTTP/1.1 401 Unauthorized
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
WWW认证:协商oYIBUTCCAU2gAwoBAaEMBgorBgE ...
Date: Tue, 02 Oct 2018 16:32:36 GMT
Content-Length: 341
Proxy-Support: Session-Based-Authentication
** -请求/响应 **
GET http://.../ordertrackingservice HTTP/1.1
Host: ...
Connection: keep-alive
Cache-Control: max-age=0
Authorization: Negotiate oXcwdaADCgEBoloEWE5UTE1TU1...
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: .AspNet.Consent=yes
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Vary: Accept-Encoding
Server: Kestrel
Persistent-Auth: true
X-Powered-By: ASP.NET
WWW-Authenticate: Negotiate oRswGaADCgEAoxIEEAEAAAAVmumr4Z49ZwAAAAA=
Date: Tue, 02 Oct 2018 16:32:36 GMT
Content-Length: 6884
在向Visual Studio发布工具创建的网站提出请求时,不会进行协商。仅有一个请求/响应
GET http://...:8081/ordertracking HTTP/1.1
Host: ...:8081
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: .AspNet.Consent=yes
HTTP/1.1 401 Unauthorized
Cache-Control: private
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/10.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
Date: Tue, 02 Oct 2018 17:00:10 GMT
Content-Length: 5955
Proxy-Support: Session-Based-Authentication
据我所知,关于配置的唯一不同之处在于,已发布的网站已绑定到端口8081。两种情况下都运行完全相同的代码,因此这一定是某种配置问题。
给出: 在工作情况下,初始响应来自IIS,第二响应来自Microsoft-HTTPAPI / 2.0,第三响应来自Kestrel。
后续问题: 中间服务器是ASP.Net核心模块的一部分吗? 是否有可能缺少某种阻止其接收切换的配置设置? (例如仅在端口80上监听)
答案 0 :(得分:0)
我遇到的问题是由阻止客户端对主机进行NTLM身份验证的组策略引起的,而不是在组策略白名单中。我不确定为什么不使用Kerberos身份验证,但是将主机添加到白名单后,身份验证协商才能继续进行。