Sharepoint Security - Excessive Demands for Login

I've just put a link button on a Sharepoint form to a file held in Sharepoint virtual file system, and when you click the link, you get asked to login (fair enough I suppose, although it is in the same site and you are alreadly logged in so it would be nice not to have this), but then you get asked over and over to login, you click Cancel on the login, and you get the file???
I get the same result on different PCs in different parts of the world.
Silas2Asked:
Who is Participating?
 
rdcproCommented:
I think it depends on how they have their network set up.  The only way to be sure the site will authenticate is if it's in the local intranet zone.  The IP address complicates things because I don't think there's any way for it to be automatically part of the intranet zone.  You might try investigating AAM (alternate access mappings) in order to use a URL that might be considered part of the intranet zone.  However, that would mean DNS changes on their end (If you can't add the site to the local intranet zone, it's unlikely you can modify the HOSTS file to add the IP address mapping.
For their production use, it's not a problem, because you can set a group policy in their domain that will be in the local intranet zone; they probably already have something like this in place.
If they use Firefox internally, you might run into this problem again.  Firefox doesn't read the wininet local intranet settings, but it does have a setting called network.automatic-ntlm-auth.trusted-uris which is used for the same thing. Firefox isn't fully supported on SharePoint anyway yet.
Regards,
Mike Sharp
0
 
mccarthybriCommented:
see if you put that url to that file as a trusted site in ie and or make sure you have the ie security settings to authenticate using current user name and password.  
0
 
rdcproCommented:
This can happen for a number of reasons.  The best bet to troubleshoot this is to run Fiddler (it's an HTTP debugging proxy) and monitor the requests and responses.  You'll probably see exactly what's causing the 401.  
http://www.fiddler2.com/fiddler2/version.asp
One possibility might be if you're using fully qualified domain names on the site, but your link only points to the short name.  Like:
Site:   https://problemSite.mycompany.com
Link:  https://problemSite/shared documents/Document.docx
Now, if you implement a redirect mechanism, you could possibly cancel the 401 challenge, but then get redirected to the FQDN which you're already autheticated with.
In any case, get Fiddler2 installed, and you should see exactly what's causing this.  Post the sessions log if you don't see the problem.
Regards,
Mike Sharp
 
0
Cloud Class® Course: CompTIA Cloud+

The CompTIA Cloud+ Basic training course will teach you about cloud concepts and models, data storage, networking, and network infrastructure.

 
Silas2Author Commented:
Hope this Fiddler screenshot is sufficient - the last two request was when I did a "cancel" and the file got dished up.
FiddlerScreenShot.doc
0
 
Silas2Author Commented:
PS I did try to add the site (its in dev mode and just an IP address at the moment) to trusted sites, but it didn't seem to make any difference.
I am guessing the Trusted Sites refers to the host not the full URL - which will change with every doc which getst dished out.
0
 
rdcproCommented:
Something seems pretty messed up!  Check the document library, and make sure it inherits permissions, or if not, you are certain your user account has access to the library (it might not).
You're not using forms-based authentication, right?  
Also,  you can disable client integration between SharePoint and Office programs...if you've set the site up with FBA, this is disabled by default.  Even if you're using an AD account via HTTP Challenge, make sure client integration is enabled in Central Admin.
Using an IP address should be ok, but just for laughs, enter the IP address (including the HTTP) into your Local Intranet Zone (not just trusted sites).  You'll probably get a warning that this site is already in trusted sites, but to automatically log in with your domain credentials, it needs to be in the local intranet zone.
There are problems with Vista using a FQDN under some circumstances, and this might come into play here with an IP address.  Does this repro on different a OS?
Regards,
Mike Sharp
0
 
Silas2Author Commented:
Right and Right.
You are right about the Vista, I just tried it on XP, and no problems.
Also moving to the Local Intranet Zone fixed it on Vista.
Do you think that means it's an IP address issue from that? (It's just that my dem at the client will look a little crap if I'm using one of their PC's and I can't get to the IE security settings, but if I sound convincing about the IP...)
(i'm using Windows authentication)
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.