4

首先，一些背景知识：我们有一个基于 WSS 3.0 的 Intranet 站点，它托管在DOMAIN_A.LOCAL中的服务器上，并设置为使用集成 Windows 身份验证来针对DOMAIN_A.LOCAL的 Active Directory 用户帐户对用户进行身份验证。

此设置适用于使用DOMAIN_A.LOCAL的 AD 帐户登录 Windows 的用户，但是当用户尝试从使用不同域（即DOMAIN_B.LOCAL）的AD 帐户登录 Windows 的 PC 访问该站点时，出现以下问题：

  1. 用户必须手动将其凭据输入为DOMAIN_A\UserName而不仅仅是UserName，否则 Internet Explorer 会自动插入DOMAIN_B并导致身份验证失败。

  2. 登录后，如果用户执行需要浏览器将其身份验证传递给客户端应用程序的操作，例如单击文档库中的 Microsoft Office 文档以将其打开以进行编辑，则显示无效凭据（大概DOMAIN_B ) 被自动传递，从而迫使用户再次手动输入他们的DOMAIN_A凭据。

那么我的问题是这样的：

有没有办法在使用集成 Windows 身份验证时实现“默认域”类型的行为（使用基本明文身份验证时可以这样做），以便如果DOMAIN_B上的用户没有在其用户名之前输入域，则DOMAIN_A是为他们自动插入？

当然，我意识到这种部署可能存在致命缺陷，因此我也愿意接受不同实施的建议。

总之，主要问题源于两种不同类型的用户需要访问一个 SharePoint 网站上的相同内容。DOMAIN_A中的用户都有自己的全职工作站，他们在其中以自己的身份登录 Windows。不幸的是， DOMAIN_B中的用户必须使用共享计算机，这些计算机使用在 SharePoint 中没有权限的通用“信息亭”类型帐户登录——因此要求DOMAIN_B用户在访问 SharePoint 中的给定页面时必须按需提供其凭据。我想为DOMAIN_A的“静态”用户保留集成 Windows 身份验证的便利性，同时最大限度地减少“信息亭”用户的手动身份验证量DOMAIN_B必须忍受。

4

4 回答 4

4

DOMAIN_A.LOCAL必须信任DOMAIN_B.LOCAL，否则来自DOMAIN_B.LOCAL的用户将收到凭据提示，因为他们的DOMAIN_B.LOCAL帐户在DOMAIN_A.LOCAL中是未知的。

鉴于DOMAIN_B.LOCAL适用于 kisok 用户，您可能不想信任此域。

您需要将 Web 应用程序扩展到一个新区域并实施基于表单的身份验证，或者使用带有反向代理（如 ISA 服务器）的 Windows 身份验证。

于 2009-04-21T16:32:20.213 回答
2

我在 Internet 上搜索具有多个域的 SharePoint 用户帐户，并遇到了一个名为 Microsoft Front End Identity Manager 的有趣工具。你听说过吗？

所以……如果您使用多林部署，其中用户帐户分布在两个或更多林中。当两个组织合并并需要访问两个组织的域时，通常会出现这种情况。您可以使用用户对象中的可分辨名称 (ms-ds-Source-Object-DN) 属性来创建用户帐户之间的关联。在此关联中，一个帐户被视为主帐户，其他帐户是主帐户的备用帐户。有一个名为 Microsoft Front End Identity Manager 的工具可以在用户帐户对象之间创建这种关系。Microsoft Front End Identity Manager 的一项功能是 SharePoint 服务器可以维护一个备用帐户列表，通过这些帐户识别配置文件。当您使用任一帐户查找用户的个人资料时，

于 2011-01-20T21:31:30.910 回答
0

可能不是您想听到的，但您可能想诉诸基于表单的身份验证。

于 2009-04-20T11:51:31.473 回答
0

不幸的是，如果您想保留 Microsoft Office 集成（这似乎是您想要的），您将不得不坚持使用 Windows 身份验证。使用表单身份验证将删除您似乎热衷于保留的大部分功能，这里有更多信息。

理想情况下，您想使用 Jason 提到的建议，这将是某种反向代理。但是，如果您还没有像 ISA 服务器这样的东西，可能会产生成本影响，因此实际上 DOMAIN_B 最好学会在他们的用户名之前输入 DOMAIN_B\。

于 2009-04-21T16:50:44.320 回答