具有多个活动目录或 Windows 域的 Jespa ntlm 身份验证
我正在使用 Jespa 进行透明 ntlm 登录。我希望能够对多个 Windows 域中的用户进行身份验证。我让它在一个域上工作。我如何添加另一个？
谢谢
I'm using Jespa to do transparent ntlm sign on. I want to be able to authenticate the users in multiple windows domains. I have it working with one domain. How do I add another?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我向 ioplex 支持询问了这个问题。他们给了我很好的答案。这里是：
“只有链中的第一个元素可以执行 SSO，因为一旦 HttpSecurityService 使用第一个域的信息向浏览器发起挑战，浏览器就无法为不同的域重新启动。至少不能在同一个请求中。理想情况下，它会如果浏览器在初始 NTLM 令牌中提交了它自己的域的名称，那就太好了，但不幸的是，
我们实际上经常遇到这个问题，我们认为处理这个问题的最佳方法是创建一个自定义过滤器。创建多个实例HttpSecurityService - 每个域都有一个并行的网络掩码列表，可用于通过远程 IP 地址将客户端与 HttpSecurityService 的正确实例进行匹配，或者您可以使用任何您想要的方法（例如浏览器签名）来识别客户端。或者您可以使用 cookie 来识别理想的域，但在这种情况下，用户必须执行某些操作才能获取 cookie（例如手动登录一次），您明白我的意思吗？
请注意，如果 AD 域具有信任，则 SSO 应该仅适用于一个 HttpSecurityService 实例。仅当域没有信任关系时，才需要上述解决方案。”
I asked this question to ioplex support. They gave me a good answer. Here it is:
"Only the first element in the chain can do SSO because once the HttpSecurityService challenges the browser with information for the first domain, the browser cannot start over for a different domain. At least not in the same request. Ideally it would be great if the browser submitted the name of it's own domain in the initial NTLM token. But unfortunately it simply does not.
We actually get this question quite a bit. The best way to handle this in our opinion is to create a custom Filter that creates multiple instances of the HttpSecurityService - one for each domain. Then you have a parallel list of network masks that can be used to match clients by remote IP address to the correct instance of the HttpSecurityService. Or you could identify clients using any method you want such as broswer signature. Or you could use a cookie to identify the ideal domain but in this case the user would have to do something to get the cookie (like login manually once). Do you understand what I mean?
Note that if the AD domains have trusts, SSO should work fine with only the one HttpSecurityService instance. The solution described above is only necessary if the domains do not have trust relationships."