跨多个域的 SharePoint (WSS) 身份验证
首先，介绍一点背景知识：我们有一个基于 WSS 3.0 的 Intranet 站点，该站点托管在 DOMAIN_A.LOCAL 中的服务器上，并设置为使用集成 Windows 身份验证来对用户进行身份验证针对 DOMAIN_A.LOCAL 的 Active Directory 用户帐户。
此设置对于使用 DOMAIN_A.LOCAL 的 AD 帐户登录 Windows 的用户来说效果很好，但当用户尝试从使用以下方式登录 Windows 的 PC 访问该网站时：来自不同域（即 DOMAIN_B.LOCAL）的 AD 帐户会出现以下问题：
用户必须手动输入其 DOMAIN_A 凭据\UserName 而不仅仅是 UserName，否则 Internet Explorer 会自动插入 DOMAIN_B并导致身份验证失败。
登录后，如果用户执行的操作需要浏览器将其身份验证传递给客户端应用程序，例如单击文档库中的 Microsoft Office 文档以将其打开进行编辑，则该操作将显示为无效凭据（大概是 DOMAIN_B）会自动传递，从而迫使用户再次手动输入其 DOMAIN_A 凭据。< /p>
我的问题是：
在使用集成 Windows 身份验证时，是否有任何方法可以实现“默认域”类型的行为（就像使用基本明文身份验证时可以完成的那样），以便 上的用户DOMAIN_B 未在用户名前输入域，会自动为他们插入 DOMAIN_A 吗？
当然，我意识到这种部署可能存在致命缺陷，因此我也愿意接受不同实现的建议。
总之，主要问题源于两种不同类型的用户需要访问一个 SharePoint 网站上的相同内容。 DOMAIN_A 中的用户都有自己的全职工作站，他们可以在其中以自己的身份登录 Windows。 遗憾的是，DOMAIN_B 中的用户必须使用使用在 SharePoint 中没有权限的通用“信息亭”类型帐户登录的共享计算机 - 因此要求 >DOMAIN_B 用户在访问 SharePoint 中的给定页面时必须按需提供凭据。 我希望为 DOMAIN_A 的“静态”用户保留集成 Windows 身份验证的便利性，同时最大限度地减少 DOMAIN_A 中的“信息亭”用户的手动身份验证量>DOMAIN_B 必须忍受。
First, a little background: We have an intranet site based on WSS 3.0 that is hosted on a server in DOMAIN_A.LOCAL and set up to use Integrated Windows Authentication to authenticate users against Active Directory user accounts of DOMAIN_A.LOCAL.
This setup works just fine for users who are logged into Windows using an AD account from DOMAIN_A.LOCAL, but when users try to access the site from a PC logged into Windows using an AD account from a different domain (i.e. DOMAIN_B.LOCAL) the following problems occur:
The user must manually enter their credentials as DOMAIN_A\UserName rather than just UserName because otherwise, Internet Explorer automatically inserts DOMAIN_B and causes authentication to fail.
Once logged in, if the user does something that requires the browser to pass their authentication through to a client app, such as clicking on a Microsoft Office document in a document library in order to open it for editing, it appears that invalid credentials (presumably DOMAIN_B) are passed automatically, thus forcing the user to manually enter their DOMAIN_A credentials again.
My question, then is this:
Is there any way to implement a "default domain" type of behavior when using Integrated Windows Authentication (as can be done when using Basic clear text authentication) so that if a user on DOMAIN_B does not enter a domain before their user name, DOMAIN_A is inserted automatically for them?
Of course, I realize this deployment may be fatally flawed, so I am also open to suggestions for a different implementation.
In summary, the main problem stems from two different kinds of users needing to access the same content on one SharePoint site. The users in DOMAIN_A all have their own full-time workstations where they log into Windows as themselves. The users in DOMAIN_B unfortunately have to use shared computers that are logged on using generic "kiosk" type accounts that have no permissions in SharePoint -- thus the requirement that the DOMAIN_B users must provide their credentials on demand when accessing a given page in SharePoint. I would like to preserve the convenience of the Integrated Windows Authentication for the "static" users of DOMAIN_A while minimizing the amount of manual authentication that the "kiosk" users in DOMAIN_B have to endure.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
DOMAIN_A.LOCAL 必须信任 DOMAIN_B.LOCAL，否则来自 DOMAIN_B.LOCAL 的用户将收到凭据提示，因为他们的 DOMAIN_B.LOCAL< /em> 帐户在 DOMAIN_A.LOCAL 内未知。
鉴于 DOMAIN_B.LOCAL 适用于 kisok 用户，您可能不想信任该域。
您需要将 Web 应用程序扩展到新区域，并实施基于表单的身份验证，或者将 Windows 身份验证与反向代理（例如 ISA 服务器）结合使用。
DOMAIN_A.LOCAL must trust DOMAIN_B.LOCAL, otherwise users from DOMAIN_B.LOCAL will receivie a credential prompt since their DOMAIN_B.LOCAL account is unknown within DOMAIN_A.LOCAL.
Given that DOMAIN_B.LOCAL is for kisok users, you probably do not want to trust this domain.
You will need to extend the web application into a new zone and either implement forms based authentication, or use Windows Authentication with a reverse proxy such as ISA server.
我在互联网上搜索具有多个域的 SharePoint 用户帐户，并发现了一个名为 Microsoft Front End Identity Manager 的有趣工具。 你听说过吗？
所以...如果您使用多林部署，其中用户帐户分布在两个或多个林中。 当两个组织合并并需要访问两个组织的域时，经常会出现这种情况。 您可以使用用户对象中的专有名称 (ms-ds-Source-Object-DN) 属性来创建用户帐户之间的关联。 在此关联中，一个帐户被视为主帐户，其他帐户是主帐户的备用帐户。 有一个名为 Microsoft Front End Identity Manager 的工具可以在用户帐户对象之间创建这种关系。 Microsoft 前端身份管理器的一项功能是 SharePoint 服务器可以维护用于识别配置文件的备用帐户列表。 当您使用任一帐户查找用户的配置文件时，SharePoint 服务器将返回主帐户配置文件示例（域\用户名）。
I was searching the internet for SharePoint user accounts with multiple domains and came across an interesting tool called Microsoft Front End Identity Manager. Have you heard of it?
So… If your using a multi forest deployment where user accounts are distributed across two or more forests. This is often seen when two organizations merge and need to access domains from both organizations. You can use the distinguished name (ms-ds-Source-Object-DN) attribute in the user object to create an association between the user accounts. In this association one account is considered the primary account and the others are the alternates of the primary account. There is a tool called Microsoft Front End Identity Manager to create this relationship between user account objects. One feature of Microsoft Front End Identity Manager is that SharePoint server can maintain a list of alternate accounts by which the profile is identified. When you use either account to find the profile of a user, SharePoint server returns the primary account profile example (domain\username).
可能不是您想听到的，但您可能想诉诸基于表单的身份验证。
Probably not what you want to hear, but you may want to resort to forms based authentication.
不幸的是，如果您想保留 Microsoft Office 集成（这似乎是您想要的），您将必须坚持使用 Windows 身份验证。 使用表单身份验证将删除您似乎热衷于保留的大部分功能，有更多信息 这里。
理想情况下，您希望使用 Jason 提到的建议，这将是某种反向代理。 然而，如果您还没有 ISA 服务器之类的东西，可能会产生成本影响，因此实际上 DOMAIN_B 最好学会在用户名之前键入 DOMAIN_B\。
Unfortunately if you want to retain the Microsoft Office integration (which is what it seems you want), you will have to stick with Windows Authentication. Using Forms Authentication will remove most of the features you seem keen to preserve, there is more information here.
Ideally you want to use the suggestion that Jason mentioned, which would be some sort of reverse proxy. However there would probably be a cost implication if you don't already have something like ISA server, so in reality it's probably best for the DOMAIN_B's to learn to type DOMAIN_B\ before their username.