views:

4054

answers:

3

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:

  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.

A: 

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

Kirk Liemohn
Yes, it may come to that. The tradeoff of course would be that the workflow would be less convenient for the DOMAIN_A users, but then at least everything should basically work for everybody.
Tim Lara
+3  A: 

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

shufler
The other reason I can't solve the problem by trusting *DOMAIN_B* is that those accounts don't have any permissions in SharePoint. The *DOMAIN_B* accounts are just generic logins that identify the kiosk workstation, but not the individual users.When you suggest extending the application into a new zone, do you mean that it is possible to have the same content use different authentication methods via separate zones? If so, that may be just what I need...
Tim Lara
Yes, that is exactly what I mean. Here's the technet article about planning zones, and how to extend and publish with ISA: http://technet.microsoft.com/en-us/library/cc288609.aspx
shufler
Thanks, Jason -- This is just what I needed. I'm testing this config right now.
Tim Lara
A: 

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.

Joe Swan
You can still get many (most?) of the Office integration features with FBA. There are some caveats, like you need to sign in with FBA and have it remember who you are (store the cookie) to be use by Office apps.
Kirk Liemohn
@Kirk - Actually when I went to look at it to check things I realised I hadn't explained it correctly. You're of course right about FBA, it's just the switch to FBA from WA turns off the client integration, which can be turned back on afterwards.
Joe Swan