Saturday, July 19, 2008

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.

Thursday, July 17, 2008

Integrated Windows Authentication and SharePoint

According to Wikipedia, Integrated Windows Authentication (which even MS sometimes calls "Windows Integrated Authentication") "refers to the SPNEGO, Kerberos, and NTLMSSP authentication protocols with respect to SSPI functionality..." However, Wikipedia goes on to say "The term is used more commonly for the automatically authenticated connections between Microsoft Internet Information Services and Internet Explorer."

<http://en.wikipedia.org/wiki/Integrated_Windows_Authentication>

The "automatically authenticated" connections use the workstation login credential. This means that the workstation login must use an AD domain that is trusted by the server. The chief advantage is that every application which needs a connection to the server can use the same credential – single signon heaven, if you are using Windows, IE, Office, and SharePoint (there's a pattern here… <g>)

In SharePoint terms, in the Central Administration site, for each web application you can select authentication providers. If you select the "Windows" authentication provider, then under "IIS Authentication" you can select "Integrated Windows Authentication" and/or "Basic Authentication". If you select "Integrated", you can then choose "Kerberos" or "NTLM", but not both.

MS says "If Active Directory is installed on a domain controller running Windows 2000 Server or Windows Server 2003, and the client browser supports the Kerberos v5 authentication protocol, Kerberos v5 authentication is used; otherwise, NTLM authentication is used." I don't know if that works in a SharePoint setting.

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/523ae943-5e6a-4200-9103-9808baa00157.mspx?mfr=true

Via testing, I have determined that the current versions of Safari (both on Mac and on Windows) support NTLM, but do not support the automatic login feature which is often called Integrated Windows Authentication. A site that is set (via SharePoint Central Admin or via IIS Manager) to use only "Integrated Windows Authentication" can be accessed via a login prompt from Safari 3.x (or, for that matter, Mozilla browsers later than November 2003). However, only Internet Explorer automatically sends the desktop login credential to the server (as far as I know).

Note that the "login prompt for every Office doc" is not an issue for browsers other than IE, because other browsers do not establish their own authenticated connection to SharePoint. They just download Office docs, then pass the file path of the temporary file to the Office app. This method does not require an authentication for the download (the browser is already authenticated), but it does require that if the file is modified, the new version must be saved, then uploaded manually.

Be aware that NTLM login problems have been reported where Safari is used with the Mac OS X 10.5 ("Leopard") system and an authenticating proxy server (such as ISA) is involved:

http://discussions.apple.com/message.jspa?messageID=6102379

-- Joshua

MySites, Anonymous Access, and Lockdown Mode

Problem

It is sometimes desirable to have anonymous access to parts of a MySite site. The usual facilities for setting anonymous access are available, but they don't seem to work for all elements of the site. While the Default (My Home) page may not have any meaning for anonymous users, and the MyProfile not much, there are occasions when Shared Documents or another doclib might need to be accessed anonymously.

We have found that setting the site to allow anonymous access to the "Entire Web", and setting the library to inherit from its parent (or not to inherit, but to allow anonymous access), enables users to access .doc, .pdf., and other files, but not pages (.aspx). This means that (for example) web part pages, document libarary lists, and other useful sites are disabled for anonymous access, and the access can't be turned on, even by the site owner.

Tentative Diagnosis

In SharePoint, anonymous users are associated with the permission level "Limited Access". The default settings for limited access are intended for team sites. MOSS has a security provision called "lockdown mode" which is intended to improve security for publishing sites. The MS document "Plan security for an external anonymous access environment (Office SharePoint Server)" <http://technet.microsoft.com/en-us/library/cc263468.aspx> contains a description of lockdown mode:

Lockdown mode is a feature that you can use to secure published sites. When lockdown mode is turned on, fine-grain permissions for the limited access permission level are reduced.


Lockdown mode appears to be activated by default in the "Publishing Site" template, and perhaps by the "Publishing" features. The page linked above shows the following two commands for lockdown mode:

The following table lists the Stsadm commands related to using lockdown mode.

Action Command
Turn on lockdown mode for a site collection
stsadm -o activatefeature -url <site collection url> -filename ViewFormPagesLockDown\feature.xml
Turn off lockdown mode for a site collection
stsadm -o deactivatefeature -url <site collection url> -filename ViewFormPagesLockDown\feature.xml

I believe we need to check to see if the lockdown feature is enabled on MySites, and what we need to do to deactivate it across the board.

-- Joshua