首先,我们有一个基于WSS 3.0的Intranet站点,该站点位于 DOMAIN_A.LOCAL 中的服务器上,并设置为使用集成Windows身份验证根据 DOMAIN_A.LOCAL 的Active Directory用户帐户对用户进行身份验证。
此设置适用于使用 DOMAIN_A.LOCAL 中的AD帐户登录Windows的用户,但当用户尝试从记录的PC访问该网站时使用来自其他域的AD帐户(即 DOMAIN_B.LOCAL )进入Windows时会出现以下问题:
用户必须手动输入其凭据 DOMAIN_A \ UserName ,而不仅仅是 UserName ,因为否则,Internet Explorer会自动插入 DOMAIN_B ,导致身份验证失败。
登录后,如果用户执行的操作需要浏览器将其身份验证传递到客户端应用程序,例如单击文档库中的Microsoft Office文档以打开它进行编辑,似乎无效的凭据(可能是 DOMAIN_B )会自动传递,从而迫使用户手动输入 DOMAIN_A 凭据试。
我的问题是:
使用集成Windows身份验证时是否有任何方法可以实现“默认域”行为(如使用基本明文身份验证时可以这样做),以便 DOMAIN_B 在用户名之前没有输入域名, DOMAIN_A 会自动为他们插入?
当然,我意识到这种部署可能存在致命缺陷,因此我也愿意接受不同实施的建议。
总之,主要问题源于两个不同类型的用户需要访问一个SharePoint站点上的相同内容。 DOMAIN_A 中的用户都有自己的全职工作站,他们自己登录Windows。遗憾的是, DOMAIN_B 中的用户必须使用在SharePoint中没有权限的通用“kiosk”类型帐户登录的共享计算机 - 因此需要 DOMAIN_B 用户在访问SharePoint中的给定页面时必须按需提供其凭据。我希望为 DOMAIN_A 的“静态”用户保留集成Windows身份验证的便利性,同时最大限度地减少“kiosk”用户在 DOMAIN_B 必须忍受。
答案 0 :(得分:4)
DOMAIN_A.LOCAL 必须信任 DOMAIN_B.LOCAL ,否则来自 DOMAIN_B.LOCAL 的用户将接收凭据提示,因为他们的 DOMAIN_B .LOCAL 帐户在 DOMAIN_A.LOCAL 中未知。
鉴于 DOMAIN_B.LOCAL 适用于kisok用户,您可能不希望信任此域。
您需要将Web应用程序扩展到新区域,并实现基于表单的身份验证,或者使用Windows身份验证和反向代理(如ISA服务器)。
答案 1 :(得分:2)
我正在互联网上搜索具有多个域的SharePoint用户帐户,并且遇到了一个名为Microsoft Front End Identity Manager的有趣工具。你听说过吗?
所以......如果您使用多林部署,其中用户帐户分布在两个或多个林中。当两个组织合并并需要从两个组织访问域时,通常会出现这种情况。您可以使用用户对象中的可分辨名称(ms-ds-Source-Object-DN)属性在用户帐户之间创建关联。在此关联中,一个帐户被视为主帐户,其他帐户被视为主帐户的备用帐户。有一个名为Microsoft Front End Identity Manager的工具可在用户帐户对象之间创建此关系。 Microsoft前端Identity Manager的一个功能是SharePoint服务器可以维护用于标识配置文件的备用帐户的列表。当您使用任一帐户查找用户的配置文件时,SharePoint服务器将返回主帐户配置文件示例(域\用户名)。
答案 2 :(得分:0)
可能不是您想听到的内容,但您可能希望采用基于表单的身份验证。
答案 3 :(得分:0)
不幸的是,如果您想保留Microsoft Office集成(这是您想要的),您将不得不坚持使用Windows身份验证。使用表单身份验证将删除您似乎希望保留的大多数功能,有更多信息here。
理想情况下,您希望使用Jason提到的建议,这将是某种反向代理。但是,如果您还没有类似ISA服务器的东西,可能会有成本影响,所以实际上DOMAIN_B可能最好学会在用户名之前输入DOMAIN_B \。