在工作站 A 和 B 上使用相同凭据进行模拟授权失败

发布于 2024-07-18 21:00:14 字数 1191 浏览 2 评论 0原文

案例 1. 当我从自己的 PC 上浏览一个名为 JOHNXP 的小测试站点时(例如 http://localhost/WebClient ) ,我的 .aspx 页面调用我的 ASMX Web 服务来获取我的凭据并将其传递到同一域中另一台计算机 (SERVERTRIM) 上的另一个 Web 服务。 我可以看到我的请求在 SERVERTRIM 计算机上生成了带有我的凭据的安全日志条目。

案例 2. 我移动到同一域中的另一台 PC,并使用我在个人桌面上使用的相同凭据登录。 当我浏览上面相同的测试网站时(这次是 http://johnxp/WebClient ),我得到了这个渗透回来到我的 .aspx 页面:

System.Web.Services.Protocols.SoapException:服务器无法处理请求。 ---> System.Net.WebException: 请求失败,HTTP 状态为 401: 未经授权

查看 SERVERTRIM 上的安全日志,我注意到情况 2 中的访问导致了匿名登录,这似乎可以解释 401/未经授权。

当我的 WS 在不同的服务器上调用供应商的 Web 服务时,我试图让我的 Web 服务使用登录的 DOMAIN 用户的凭据。

我的 ASMX Web 服务在我的桌面上运行(IIS 5.1 WinXP Pro - 计算机名称为 JOHNXP)。 我在涉及的每台服务器中都启用了未选中的匿名功能,并且在我的场景中涉及的每个 web.config 中都有此功能:

供应商 Web 服务在 SERVERTRIM(Win 2003 Server)上运行,它也是 ASMX 并使用 WSE 3.0。

Wireshark 和 Netmon 现在对我来说看起来太强大了。 我认为“远程”服务器(SERVERTRIM)上的不同结果登录是足够的“证据”。 上面的所有机器都在同一个域中,但如果可能的话,我想将“远程”Web 服务保留在 SERVERTRIM 上,并将中间 Web 服务保留在同一域中的不同服务器上。 这种情况是否要求我必须深入研究“委托”? 当在域中的另一台计算机上发起 Web 请求时,监控为什么相同的凭据会导致匿名登录的最简单工具是什么?

Case 1. When I browse a little test site from my own PC called JOHNXP (e.g. http://localhost/WebClient ), my .aspx page invokes my ASMX webservice picks up my credentials and passes them across to another webservice on ANOTHER machine (SERVERTRIM) in the same domain. I can see my request resulting in a Security Log entry on the SERVERTRIM machine with my credentials.

Case 2. I move to another PC in the same domain and logon with the same credentials I used back at my personal desktop. When I browse the same test site above (this time as http://johnxp/WebClient ), I get this percolated back to my .aspx page:

System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> System.Net.WebException: The request failed with HTTP status 401: Unauthorized

Looking at the Security Log on SERVERTRIM, I note that the access in case 2 resulted in an ANONYMOUS LOGON which seems to explain the 401 / Unauthorized.

I'm trying to get my webservice to use the credentials of the logged in DOMAIN user when my WS calls a vendor's webservice on a different server.

My ASMX webservice runs on my desktop (IIS 5.1 WinXP Pro - machine name is JOHNXP). I have Enable anonymous UNCHECKED in every server involved and I have this in every web.config involved in my scenario:

The vendor webservice runs on SERVERTRIM (Win 2003 Server) and it is also ASMX and uses WSE 3.0.

Wireshark and Netmon look too formidable as tools for me right now. I am figuring the different resulting LOGONs on the "remote" server (SERVERTRIM) are sufficient "evidence". All machines above are in the same domain but I want to keep the "remote" webservice on SERVERTRIM and my intermediate webservice on a different server in the same domain if possible. Does this scenario demand that I have to dig into "delegation"? What would be the easiest tool to monitor why the same credentials result in an ANONYMOUS LOGON when the web request is initiated on another machine in the domain?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

送你一个梦 2024-07-25 21:00:14

我对身份验证的了解有点模糊,但如果我正确理解了您的描述:

  • 在第一种情况下,您正在浏览到 localhost,它模拟调用者,然后调用另一台计算机上的 Web 服务。 模拟是在与客户端相同的计算机上完成的。 我相信在这种情况下,模拟应用程序不需要位于受信任委派的计算机上(因为它已经与客户端是同一台计算机)。

  • 在第二种情况下,您正在浏览到一台不同电脑,该电脑在呼叫第三台电脑时试图冒充呼叫者。 在这种情况下,中间的 PC 需要被信任进行委派(如果它是开发工作站,则可能不会如此)。

My knowledge of authentication is a bit hazy, but if I understood your description correctly:

  • in the first case, you're browsing to localhost, which is impersonating the caller, then calling a web service on a different machine. The impersonation is being done on the same machine as the client. I believe in this case, the impersonating application doesn't need to be on a machine that is trusted for delegation (because it's already the same machine as the client).

  • in the second case, you're browsing to a different PC, which is attempting to impersonate the caller when calling a third PC. In this case, the PC in the middle would need to be trusted for delegation (which it presumably won't be if it's a development workstation).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文