Partager via

Unwanted Authentication Prompts

  • Article

I’m often bumping into customers who complain they are getting “Too many authentication prompts” when using SharePoint. So, I thought it would be useful to throw together a quick post outlining some of the common causes I have found, along with an explanation and possible solutions:

1) You are using “Basic Authentication” and you are getting an authentication prompt when you access a Team or Portal site.

In this case you will indeed get an authentication prompt, this is because you are using “Basic Authentication” and this is “By Design” behaviour.

While on the topic of “Basic Authentication” it’s important to point out that this form of authentication is not ideal from a security perspective. Why? Because usernames and passwords are sent across the wire in plain text, making it very easy for anyone to read them as they zap from the client to the server. Typically, to protect this information, SSL would be implemented, ensuring all communication between the browser and web server is encrypted. Unfortunately, with SharePoint up until “Service Pack 2”, this has not always been as easy as it sounds. Let me explain:

  • With SSL enabled you cannot use host headers. This is because the IIS server cannot access the encrypted request to determine the correct destination. (UPDATE: It seems there has been some new functionality introduced with Windows 2003 SP1 to support this. It looks a bit fiddly, and I haven’t tried it, anyone out there care to comment?)
  • With SharePoint (pre-SP2) you were not able to use a “Static IP” addresses (the famous 830342) to differentiate one IIS web site from another. (Note: We now support Static IP addresses in SP2)
  • While you could still use Ports to differentiate between IIS web sites, this leads to a very unfriendly URL.

This all meant, that to use SharePoint with Basic Authentication and SSL, you were restricted to just one SharePoint Extended Web Site per physical server. This caused lots of people all sorts of grief, especially those looking at Extranet scenarios. So, the bottom line is this, if you are using Basic Authentication, then expect an authentication popup box and make sure you upgrade to SharePoint SP2 so you can improve your sites security by enabling SSL.

2) You are using “Basic Authentication”, you access the site, receive and authentication pop-up and authenticate successfully, you then browse to a document library and try to open a document, at which point you are greeted by another authentication prompt.

In this case you get the second authentication prompt because you are using “Basic Authentication”, this is “By Design” behaviour. The reason behind it gets pretty technical, in short, the reason goes something like this:

  • When you first open the site, you are using Internet Explorer, and you establish a trusted session with SharePoint by authenticating.
  • When you navigate around the site you are continuing to use that trusted session.
  • When you go to open a document from a team site, you are actually requesting that Word open the document from the SharePoint Server
  • At this point word needs to establish its own, separate, trusted session with the SharePoint server, and you are therefore requested to perform another authentication.

I have to agree this is pretty painful, especially when you are looking at creating an extranet site, something which will often require you to use “Basic Authentication”. I know this has been flagged up internally on a couple of occasions, however the work involved to overcome it has proved to be beyond the scope of what we are able to do with the current product releases. Remember it’s touching Office, Internet Explorer and IIS here.

3) You have enabled NTLM authentication and are trying to browse to a SharePoint site while logged in directly to the SharePoint Server (as in via the console or a remote desktop session).

In this case you will get an authentication prompt because Windows 2003 server ships with Internet Explorer in an “Advanced Security Configuration” mode. This mode prevents the browser from sending NTLM credentials to any site that is not “Trusted”. To overcome this issue you should add your SharePoint site to internet explorers “Trusted Sites” zone. This problem is continually catching people out during demos.

4) You have enabled NTLM authentication, you have permission to access a site, however every time you try to access it you are presented with an Authentication Prompt and potentially even denied access.

These problems really stump people, and getting to the bottom of them can take some time. Often you will have users that could happily access the site yesterday, but then unable to today.

a) A resource on the team site is coming from another team site, document library or location, that has:

  • A different authentication method, for example coming from a site with only “Basic Authentication”
  • That you do not have permissions to access, for example another WSS site to which you dont have permissions

The classic example here is the administrator of one site (Site A), adding an image web part that consumes an image stored in a second site (Site B) site. It all works fine for the administrator, who has access to both sites (Site A and Site B), but other users are suddenly unable to access the team site because while they have access to the first (Site A), they may not to the second (Site B).

b) A web part on the team site is using parts of the object model that have restricted permissions. The classic example here is a web part that attempts to find all the roles for a site user. Such an operation is restricted to site administrators only, and when a user who is not an administrator tries to access a team with such a web part on it, they will get an authentication box.

Sometimes even impersonation is not enough to overcome this, see the below for further reading:
Approach using AppDomains - https://www.bluedoglimited.com/SharePointThoughts/Log/DisplayLog.aspx?ID=7 
Approach using COM+ - https://radio.weblogs.com/0126624/2004/05/16.html

c) When applying a new brand to a portal or team site via modified site definitions it’s often necessary to add additional images. I have come across a situation where some of the images copied across have had NTFS permissions applied incorrectly, restricting them to Administrators only. IIS, and therefore SharePoint, will always respect the underlying filesystem permissions, therefore any users who do not have file level permissions to read the image will be presented with an authentication box when trying to access a site using that image.

Now, I suspect there are a couple more examples out there (especially with the dreaded “Explorer View”, but I’m leaving those for another post), these are just the most common ones I have seen, keen to hear about your experiences.

Comments

  • Anonymous
    February 16, 2006
    Great post!  I get the same question/complaint alot as well.

  • Anonymous
    February 16, 2006
    I managed to implement multiple SSL enabled sites on my IIS server by using different ports for the SSL connection and having all traffic to the server go via an ISA server.  The ISA server performs bridging between the the port 443 used by the browser and the one on the IIS server.

  • Anonymous
    February 16, 2006
    Hi Amarshall, did you do this with SharePoint Extended Web Sites?

    The problem you will often hit with this sort of approach and SharePoint is that the Web Pages SharePoint sends back to the browser are created based on the URL that was used to access SharePoint.

    So if I undertsand correctly, and unless you are also doing some sort of URL mapping, in this case the URL being sent to SharePoint by ISA is different to the one the client sent to ISA. This is going to mean links in the SharePoint page sent back to the client are wrong...Perhaps I need to blog this...

    Anyway, let me know, keen to hear, I do suspect some smart ISA work can overcome this restriction.  

  • Anonymous
    February 17, 2006
    PingBack from http://weeklyfeast.wordpress.com/2006/02/17/revisiting-the-weekly-feast/

  • Anonymous
    February 20, 2006
    Cool post. Best summary I've seen so far.

    Cheers,
    Andre

  • Anonymous
    January 21, 2009
    PingBack from http://www.keyongtech.com/1996323-multiple-authentication-windows

  • Anonymous
    June 15, 2009
    PingBack from http://einternetmarketingtools.info/story.php?id=21589