Without much work this is not possible if the server and client computers aren't in the same domain.
In a domain environment, authenticating for Sharepoint access the process in the background works roughly like this:
- First you authenticate to domain controller
- Domain controller assigns you a ticket
- Web server checks your ticket
In non domain environment it is simply not trivial to configure such automatic authentication on a Serverside.
Workaround
You can configure automatic authentication on the client side by storing password in the browser or by configuring IE to authenticate with current user credentials.
Firefox:
When navigating to Sharepoint site new dialog box opens up, asking for credentials. After you supply the credentials, a "dialog-line" appears at the top of Firefox browsing area, asking if user wants to store password. By selecting OK, credentials get stored. Next time visiting a site user simply confirms autocompleted form with Username/password.
IE:
The approach mentioned for firefox didn't work for me. IE does offer to remember password, but even if you check this option, credentials don't get stored. (Maybe someone has solution for that).
The following is what does work: You add the site to Local Intranet Zone (Tools -> Internet options -> Security -> Local Intranet -> Sites -> Advanced). By default Security level is set up in the way that IE should attempt to authenticate you automatically using current user credentials. You can check that by clicking Custom level, then search for user authentication section. If either Automatic logon only in intranet zone or Automatic logon with current user name and password is selected, this shoud work.
Of course instead using Intranet zone you can add site in Trusted zone or somewhere else. Just make sure that Automatic logon with current user name and password options is selected.
This can happen if the Windows server (which runs IIS 6.0) and the Windows clients (using IE to access your website) are all part of a local network (LAN).
Also relevant is that you have the "Integrated Windows authentication" enabled as you need to use and validate the users from an AD domain.
Let's call the name of this AD domain ad_domain_name
.
In this scenario (LAN + integrated auth), the authentication process between Windows clients and server use AD domain security by design.
You can check if this is the case trying this (on Windows client):
- Close All IE windows
- Open IE
- Access your website and get the login box
- Into "username" field write :
ad_domain_name\username
- Into "password" file write the password of this user
This procedure should permit the login at the first try.
I have observerd this beavour many times and usually all this is regarded by Microsoft people as 'desired security feature' in case of local network. And usually was treated as a non-problem as the login procedure can be done anyways.
I do not know if there is an IIS (and/or Windows server) configuration that can avoid all this mess, but I'm as curious as you to know.
Best Answer
Well, typically when you have an IIS server on a DC there are all sorts of stuff that goes wrong:
What I would look at is that the IUSR account is infact the correct one, and not the domain one - you actually might not have an IUSR account since it would have been domain specific.
This link has some information regarding IIS on DC's, and this link talks about promoting a member server to a DC. Here are details on the IUSR and IWAM accounts, which will probably have to be recreated and re-linked in the metabase.