跨多个域的SharePoint（WSS）身份验证

首先，有一点背景：我们有一个基于WSS 3.0的intranet站点，该站点托管在域\本地的服务器上，并设置为使用集成Windows身份验证根据域\本地的Active Directory用户帐户对用户进行身份验证

此设置适用于从域A.LOCAL使用广告帐户登录Windows的用户，但当用户尝试从使用其他域（即域B.LOCAL）的广告帐户登录Windows的PC访问站点时，会出现以下问题：

用户必须以域A\UserName的身份手动输入其凭据，而不仅仅是用户名，否则，Internet Explorer会自动插入域B，并导致身份验证失败

登录后，如果用户需要浏览器将其身份验证传递到客户端应用程序，例如单击文档库中的Microsoft Office文档以打开文档进行编辑，则会自动传递无效凭据（可能是域B），从而迫使用户再次手动输入其域\u A凭据

我的问题是：

在使用集成Windows身份验证时，是否有任何方法实现“默认域”类型的行为（使用基本明文身份验证时可以这样做），以便如果域B上的用户未在其用户名之前输入域，则会自动为其插入域a

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

---

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

可能不是您想听的，但您可能需要使用基于表单的身份验证。

域A.LOCAL必须信任域B.LOCAL，否则域B.LOCAL的用户将收到凭据提示，因为他们的域B.LOCAL帐户在域A.LOCAL中未知

鉴于DOMAIN_B.LOCAL是为kisok用户提供的，您可能不想信任此域

---

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

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

---

理想情况下，您希望使用Jason提到的建议，即某种反向代理。但是，如果您还没有像ISA server这样的产品，可能会产生成本影响，因此，在现实中，对于域用户来说，最好先学会在用户名之前键入域。

我在internet上搜索具有多个域的SharePoint用户帐户，发现了一个有趣的工具，名为Microsoft前端身份管理器。你听说过吗

---

所以…如果您使用多林部署，其中用户帐户分布在两个或多个林中。当两个组织合并并需要从两个组织访问域时，通常会出现这种情况。可以使用用户对象中的可分辨名称（ms ds源对象DN）属性在用户帐户之间创建关联。在此关联中，一个帐户被视为主帐户，其他帐户是主帐户的替代帐户。有一个名为Microsoft前端标识管理器的工具可以在用户帐户对象之间创建这种关系。Microsoft前端标识管理器的一个功能是SharePoint server可以维护一个备用帐户列表，通过该列表来标识配置文件。当您使用任一帐户查找用户的配置文件时，SharePoint server将返回主帐户配置文件示例（域\用户名）

是的，可能会这样。当然，折衷的办法是工作流对域用户来说不太方便，但至少每个人都可以使用。您仍然可以使用FBA获得许多（大多数？）Office集成功能。这里有一些警告，比如你需要登录FBA，让它记住你是谁（存储cookie），以供Office应用程序使用。@Kirk-事实上，当我去查看它检查一些事情时，我意识到我没有正确解释它。关于FBA，你当然是对的，只是从WA切换到FBA会关闭客户端集成，之后可以再打开。我无法通过信任域B解决问题的另一个原因是这些帐户在SharePoint中没有任何权限。DOMAIN_B帐户只是标识kiosk工作站的通用登录，而不是单个用户。当您建议将应用程序扩展到一个新区域时，您的意思是可以让相同的内容使用不同的身份验证吗