Some users get IIS 500 errors when logging onto Sharepoint Team Site

I'm running a Windows Sharepoint Services (v2) Team site under Windows 2003 Server (standard), using IIS6 and MSSQL 2000.

I can access the site fine from my laptop as can my work collegues.  It also works from my home PC, in IE5, 5.5 and 6 + FireFox 1.0.

However, people browsing from two separate locked down corporate networks always get IIS 500 error pages when they try to login to the site.  The username/password used in all cases is the same.

I'm looking for some pointers on where I should start looking for the cause of this problem.

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

I presume from what you are saying that they get the username/password prompt, but when they input input it, they get the error.  This and the fact that you are able to access the site fine from other locations suggests that the problem is here: "people browsing from two separate locked down corporate networks always get IIS 500 error pages".  Something in the security config of these networks (ie. firewall) is restricting the kind of access that is allowed.  The first question - is this something that is within your control to change?
mr_davidlaingAuthor Commented:

I agree, its something to do with the coporate networks; be it a firewall, a proxy or something else.

And in answer to your question - no, I have absolutely no control over those networks settings.

I'm at a loss as to where to start looking.

It must be something to do with the Authentication settings.  IIS is using Windows Integrated Authentication (NTLM); and the website usernames are part of a different domain.

I can't figure why this is causing an IIS6 500 error - at the worst I would expect an authentication error of some kind.
This is a difficult one.  With Sharepoint Services, there's not much you can change on your end - the required elements and apps are, well . . . required.  Since it doesn't appear to be an authentication problem, it makes sense that you're not getting an authentication error, but I'm not entirely sure why you're getting a 500 error instead.  Perhaps the server isn't getting something it needs from the client machine due to the network restrictions, so the app fails.  Of course, this is speculation.

Perhaps someone else will have some insight into this element of the problem.  If so, it would be helpful in determining what changes could be made to allow proper access.  However, if you have no control over these networks, the info might be moot.
Introducing Cloud Class® training courses

Tech changes fast. You can learn faster. That’s why we’re bringing professional training courses to Experts Exchange. With a subscription, you can access all the Cloud Class® courses to expand your education, prep for certifications, and get top-notch instructions.

What does event viewer say? What do the IIS logs for that web say? What is the full 500 error? Any IP restrictions in IIS? Firewall?
Try getting the users with the 500 errors to turn off HTTP friendly errors
(in IE this is via Tools-->Internet Options-->Advanced-->Untick "Show Friendly HTTP Error message")
You might get a bit more info out of their browsers this way.

If your problem users are in a different domain, try enabling basic authentication as well as integrated to see if it'll let them through.

If you're running your site on port 80, this shouldn't be a proxy issue unless they're trying to author the site or use the administration pages.

Make sure logging is turned on for your site, particularly the extended properties:
User Name (cs-username), Protocol Status (cs-status), Win32 Status (cs-win32-status).

Get your problem users to try accessing the site then go back to check the logs.  This will tell you:
- whether they're hitting your site at all
- what username they're trying to access your site with
- where the 500 error is cropping up and if you're lucky maybe an ado error that might explain it
- win32 status code (to decipher drop to cmd prompt on server and type> net helpmsg ##   where ## is the status code).
mr_davidlaingAuthor Commented:
Alimu - thanks for the detailed feedback!

I've just come back from the clients, after enabling the extra logging properties suggested.

Client is using IE6 SP1, on Windows 2000 Professional.

Here are the files from the server logs when Windows Authentication is used:

2004-11-16 10:54:01 GET /_vti_bin/owssvr.dll - 80 - Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.0) - 401 2 2148074254 1912 330 421
2004-11-16 10:54:03 GET /_vti_bin/owssvr.dll - 80 - Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.0) - 500 0 2148074242 335 396 140

The client gets the error 500 screen.

I've been playing with the authentication types in IIS, and discovered the following:

Enabling just Digest authentication gives the same error 500.
Enabling both Windows Auth & Basic also gives error 500.
Enabling just Basic works!  Hurrah!

So, I've found an (insecure) solution that will work for now.  However, I'd love to know why this error occurs.  

I also wonder why enabling Windows Auth + Basic doesn't work - surely when it discovers Windows Auth fails it will "fall back" down to Basic auth?
A possible cause is that the clients proxy server does not support NT Authentication. I have come accross the very same thing in the past.
mr_davidlaingAuthor Commented:

I've just installed a fresh Win 2000 Virtual Machine (which comes with IE5).

Interestingly, I get exactly the same error when accessing the site from that PC - so it isn't a firewall issue, nor is it a lock-down issue.  Its something to do with Windows 2000 (in its default install state).

Turning off the friendly HTTP error messages reveals the following error message:

"The function requested is not supported"

Does that shed any light?
The first line of logs you show is a 401, access denied, with a Win32 error of SEC_E_NO_CREDENTIALS
This would be normal for a first request (browser will send through anonymous request first).
It should be followed by a request with a status code of 200 accompanied with a domain and userid.

The second line of logs shows a 500, internal server error, with a win32 error of SEC_E_UNSUPPORTED_FUNCTION
This error is generated by the server extensions.

Are your problem users located and logged into the same domain as your server (i.e. the server's computer account domain not the domain you put in for basic authentication)?
Do they go through another server (eg: proxy) to get to this one?  If they do then integrated authentication won't work because it can't pass authentication username & password the 2 server hops to get to the server.  You need to use basic in this situation.
Digest only works if you have reversible encryption configured on your domain accounts.  This adds overhead and there are a few other problems with digest auth so it's not commonly used.
btw - the 500 error could simply be cropping up because the server extensions can't establish your identity so fixing one problem may resolve the other...
mr_davidlaingAuthor Commented:

Let me see if I can answer all your questions.

[1] No - they are part of a different domain (or in the case of my test Win2k machine, not part of any domain)
[2] My test Win2k machine doesn't go through a proxy
[3] Digest doesn't work because I have disabled reversible encryption of passwords according to MS Security Lockdown guide.
[4] Basic authentication works

It seems to me that the error is caused (as you say) by FP server extensions.  When using Integrated Auth, these throw a "The function requested is not supported" error when you try to access the page using IE5/6 on Win2k.

Any idea how I would go about finding which "function requested is not supported?"


Integrated authentication pulls the credentials of the currently logged on user and authenticates them against the server's domain and any domains it trusts.   If authentication fails, a logon box will popup. Credentials must be entered in this box in the format:

If your users are in a different domain, you need to setup a trust so that at a minimum the server's domain TRUSTS the user's domain.  If this trust is not in place, integrated authentication will fail.

If you turn off integrated authentication do you still get the "function requested is not supported" error?
If the error disappears, as indicated in my last post, your error may be a flow-on effect of your authentication issues... i.e. Frontpage is erroring because it can't authenticate the user properly.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
mr_davidlaingAuthor Commented:
Thanks for all the help alimu,

Integrated authentication only fails for Win2k clients - it still works for WinXP clients even if they are on a different domain, and even if they don't login using the domain\uname syntax (just using uname).

Still, given that basic authentication works; I'd go with your assumption that it is FP ext that are throwing the error because it can't authenticate the user properly.
ok - if you want to solve the win2k vs xp problem start looking at the security event logs on the client and the domain controllers to see if any of your problems marry up with errors like "session could not be established" or similar.
The mode each domain runs in can play a part also.  Are all your domains in the same forest? are they win2k / win2k3, etc.

I usually start trying to resolve these issues by clearing out browser cache and restarting browser, then move onto getting problem user to try a "known working" machine, recreation of user's profile, recreation of computer account in domain, etc.  The best thing you can do is start looking for errors that show up in the user's logs / domain controller logs and see if it sheds any light.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft IIS Web Server

From novice to tech pro — start learning today.

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.