SharePoint Authentication and Auto-Signon

The following is an email summarizing my investigation of issues around SharePoint logins and client integration. We are currently using Basic Authentication so that all clients can authenticate, but we would also like to have the benefits of Internet Explorer auto-login and single-signon via Integrated Windows Authentication. It turns out, you can't have both…

After an extensive (maybe too extensive) investigation, I have concluded that if the SharePoint server is configured to accept auto-signon with Internet Explorer, IE will require that the domain be specified by the user if the browser cannot use or is not configured for auto-signon. In short, we have to choose between requiring "domain\" on SharePoint logins, and using the client integration features with Windows clients, including transparent download/upload of Office documents.

On the first request to a server, IE attempts to access a website anonymously. On our SharePoint server, since anonymous access is not enabled, the server responds with an "Unauthorized" result code. When both NTLM and Basic authentication are enabled on the server side, the "Unauthorized" response includes two "WWW-Authenticate" headers: NTLM and Basic.

IE prefers NTLM and will always use it if the server offers it; if NTLM does not succeed, IE will not fail over to Basic.. If auto-signon is not enabled in the browser (that is, if the site is not determined to be in the "local intranet" security zone due to browser configuration), or if the client has not been bound to the domain, then IE puts up a username/password dialog box. The legend in this box says "connecting to <sitename>" -- this is a constant in IE. The fields in the box are labeled "User name" and "Password", and there is a "remember my password" checkbox, but there is no separate "Domain" field. Domain must be specified as a prefix to the username (delimited by "\"), but there is no way of telling the user this.

If the user enters a username and password, but no domain, authentication fails, because IE fails to use the domain suggested by the server; instead it prefers to use the server name as a domain. Microsoft claims this is by design; I'm not sure why yet.

When authentication fails, Internet Explorer re-prompts with the username/password dialog box; this time, it inserts the hostname as the domain prefix. Of course, the user has no local account on the server, so this can never work. If the user knows enough to replace the domain prefix with "AD\", then authentication can succeed.

Interestingly, Firefox will do both auto-login (if the host is white-listed in the browser config) and no-domain-specified login; for the latter, FF simply uses the domain suggested by the server ("AD"). Why Microsoft doesn't do the same bewilders me.

In short, we are still in the same place that we were when Diane first did this investigation:

1. If we enable auto-signon by enabling NTLM on SharePoint sites, users on Windows machines bound to the domain and with thehost properly whitelisted will have auto-signon, whether using IE or Firefox. However, users who do not meet these requirements will need to use the "AD\" prefix (at least for SharePoint sites; the prefix will cause login to fail on (e.g.) Unified Signon. Making matters worse, there is no way to warn users about the prefix requirement during the login process.
   
2. If we do not enable NTLM, we will have the current situation of no auto-logins, and have multiple logins for SharePoint sites for all the too-familiar reasons.