SharePoint Authentication (WSS) across multiple domains

Question

First, a small background: we have a WSS 3.0-based intranet site hosted on a server in DOMAIN_A.LOCAL and configured to use Windows Integrated Authentication to authenticate users from Active Directory users with DOMAIN_A.LOCAL accounts .

This setting is great for users who are logged into Windows using the AD account from DOMAIN_A.LOCAL , but when users try to access the site from a PC connected to Windows using the AD account from in another domain (i.e. DOMAIN_B.LOCAL ) the following problems occur:

• The user must manually enter their credentials as DOMAIN_A \ username , not just username , because otherwise Internet Explorer automatically inserts DOMAIN_B and authentication fails.

• After logging in, if the user does something that requires the browser to pass its authentication through the client application, for example, by clicking on a Microsoft Office document in the document library to open it for editing, that invalid credentials (presumably DOMAIN_B ) are transferred automatically , which forces the user to manually enter their DOMAIN_A credentials again.

My question is this:

Is there a way to implement the default behavior when using integrated Windows authentication (as is done when using basic text authentication) so that if a user in DOMAIN_B doesn’t work, enter the domain before their username, is DOMAIN_A automatically inserted for them?

Of course, I understand that this deployment can be deadly wrong, so I am also open to suggestions for another implementation.

Thus, the main problem is related to two different types of users who need to access the same content on the same SharePoint site. Users from DOMAIN_A have their own jobs, where they log into Windows as themselves. Users at DOMAIN_B , unfortunately, will have to use shared computers that are logged in using shared kiosk accounts that do not have permissions in SharePoint — therefore, requiring DOMAIN_B users to provide their credentials on request when accessing this page in SharePoint. I would like to maintain the convenience of integrated Windows authentication for “static” DOMAIN_A users, while minimizing the amount of manual authentication that 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 be prompted for credentials because their DOMAIN_B.LOCAL account is unknown in 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 expand the web application in a new zone and either perform forms-based authentication or use Windows authentication using a reverse proxy server, such as an ISA server.

Answer 2

I searched the web for SharePoint user accounts with multiple domains and came across an interesting tool called Microsoft Front End Identity Manager. Have you heard about this?

So ... If you are using a multi-forest deployment in which user accounts are distributed between two or more forests. This is often observed when two organizations are combined and need access to domains from both organizations. You can use the distinguished name attribute (ms-ds-Source-Object-DN) in a user object to create a relationship between user accounts. In this regard, one account is considered the main account, and the rest - an alternative to the main account. There is a tool called Microsoft Front End Identity Manager to create this relationship between user account objects. One of the features of Microsoft Front End Identity Manager is that the SharePoint server can maintain a list of alternative accounts through which the profile is identified. When you use an account to search for a user profile, the SharePoint server returns an example profile of the primary account (domain \ username).

Answer 3

Probably not what you want to hear, but you can resort to forms-based authentication.

Answer 4

Unfortunately, if you want to keep Microsoft Office integration (this is what you think), you will have to stick with Windows authentication. Using Forms Authentication will remove most of the features that you seem to want to keep; there is more information here .

Ideally, you want to use the sentence Jason mentioned that would be some kind of reverse proxy. However, it will probably be costly if you don’t already have something like an ISA server, so it’s actually best to have DOMAIN_B learn how to enter DOMAIN_B \ in front of its username.