Wednesday, August 05, 2009

Getting rid of excessive authentication prompts in SharePoint

This article pertains to WSS 3.0 and MOSS 2007 flavors of SharePoint.

There are two common issues in SharePoint involving excessive authentications:

A. Being forced to authenticate multiple times when you first connect to the portal, and

B. Being forced to authenticate when you open an Office document from the portal.

The first is a problem that can have multiple causes and requires some troubleshooting on your part, but can generally be fixed.

The second is expected behavior as of this writing, but there are potential ways to get around it to it is less annoying.

A. Excessive authentication when connecting to a portal

If you are unexpectedly or continually forced to enter your credentials (even though you have told the browser to save your password):

1. If you are logged into a server and are using the node name in the URL, try adding the node name to your list of Intranet nodes in IE: Tools --> Internet Options --> Security --> Local Intranet --> Sites --> Advanced

Note: Not having the node in your list of intranet nodes can also cause obscure problems such as the Site Actions menu not working.

2. Check to be sure the portal site is in the trusted sites list in the browser.

3. Be sure the browser is set to bypass local addresses for the proxy server

4. Set the access level for trusted sites to allow automatic login with current username and password

5. Check Control Panel - User Accounts - Advanced - Manage Passwords - to see if there are any cached passwords that are relevant to the portal. Delete these so you can start over with a new one since these will override.

The Microsoft whitepaper on troubleshooting the SharePoint Explorer view (SPSEVTSHOOT) may also have relevant information in some cases:

There are also a couple of Windows 2003 bugs that could possibly be related:

1. DCPROMO does not retain permissions on some IIS folders

2. "You receive a server error ..."


B. Being forced to authenticate when opening an Office document from the portal

This is expected behavior due to Office documents opening locally for write access in a separate process from the browser. There is a workaround. You can
Hover over the item --> Select the drop down --> Send To --> Download A Copy to read the document, which allows you to open a local copy of the document, avoiding the extra sign-in, but this is a little awkward for the user.

If you aren't satisfied with that workaround, there's a hack that might do the trick for you. It involves changing the default behavior that SharePoint uses when you click on a document library link. You change the common javascript used by all SharePoint sites to open documents so that they just download a copy of the document for reading, rather than trying to directly open the document for editing. This avoids the authentication.


There is a block of code in that article that you can insert into the CORE.JS file, without making any other changes to CORE.JS. Be sure to backup your CORE.JS file before making these changes! Do not include the [code:js] and [/code] tags themselves.

Four notes on this fix:

1. When you apply the hack, you have to close down your browser, open a new instance, and CTRL-Refresh (CTRL-F5) to test.

2. This does not work for attachment documents to lists, only for Office documents which are items in document libaries.

3. This hack has the side effect of forcing authentication on document libraries that are configured for anonymous access, rather than letting them open anonymously.

4. Even after applying this hack, you can still edit documents directly from SharePoint by using: Hover Over Item --> Select dropdown --> "Edit in Microsoft X"

No comments:

Post a Comment