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

Question

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 (ie DOMAIN_B.LOCAL ) the following problems occur:

1. 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.

2. 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.

Answer 1

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.

Answer 2

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).

Answer 3

可能不是您想听到的内容，但您可能希望采用基于表单的身份验证。

Answer 4

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.