我们开发了一个自定义编译的 .net 4.0 dll 库，该库部署在标准 IIS 服务器上。该库由供应商创建的应用程序 Spotfire Web Player 使用，该应用程序在 IIS 服务器上自己的应用程序池中运行。该插件连接到另一个运行 tomcat 的服务器，以通过 Web 请求检索数据。为了发出这个请求，插件使用协商安全性生成一个身份验证令牌，将其转换为 base64 字符串，并传递给其他服务器以方便通过身份验证。在 IIS 的应用程序级别，Spotfire Web Player 应用程序被配置为使用 Windows 身份验证，进一步在 Windows 身份验证下的提供程序中，我们指定了协商：Kerberos 是唯一的身份验证方法，并且在高级设置中禁用内核模式身份验证（删除 NTLM 时需要）。这样做是为了克服我们认为可能是问题的 NTLM 双跳限制。应用程序池是标准的 .net 4.0 集成管道池，在系统 NetworkService 帐户下运行。
这里有几个场景向我们展示了安全问题或 IIS 配置干扰了正确的身份验证方法。
故障场景（双跳）
状态
• 服务器按上述方式运行，没有远程/交互式登录用户。
操作
• 远程笔记本电脑上的用户打开 Internet Explorer 浏览器并尝试打开将使用插件的文档。
结果
• 身份验证失败结果。
功能场景（单跳）
状态
• 服务器运行如上所述，管理员通过远程桌面登录
操作
• 管理员在服务器会话中打开 Internet Explorer 并继续打开将使用插件的文档
结果
• 身份验证成功。管理员凭据已成功传递到 Zema 服务器并经过身份验证。
功能场景（双跳）
状态
• 服务器如上所述运行，管理员通过远程桌面登录，并且管理员已成功打开使用插件并成功通过身份验证的文档（通过远程桌面中的 IE）。
操作
• 任何其他标准用户，从他们的笔记本电脑，在 chrome 或 IE 中，尝试打开将使用插件的文档
结果
• 所有用户都能够通过身份验证。仅在首先在服务器本身上打开文档之后。
功能场景（单跳）
状态
• 与上述 IIS 服务器不同，此插件也可用于在用户本地笔记本电脑上运行的客户端 .net 应用程序。IIS 使用与此桌面应用程序（Spotfire 分析软件）所使用的完全相同的 DLL 库。
操作
• 任何用户在使用插件的笔记本电脑上打开一个文档
结果
• 在这种情况下，用户笔记本电脑运行插件，生成身份验证令牌，并将其直接发送到 Zema 服务器。IIS 服务器根本不在图中。这种情况总是会导致成功的身份验证。
谢谢！