IIS Configuration is preventing remote Intranet logins. Why?

We host an Intranet via IIS 6.0, which many staff (all in developing countries) must access.  Of the 25 or so countries, approximately half are having difficulties logging into the Intranet.  The problem could be the local ISPs themselves, which often have restrictive or relatively uninformed policies in place.  However the problem could be my IIS config as well.  

A few points:

- Anonymous Access is disabled.  Authentication is via Integrated Windows Authentication (against AD), which is working fine for most of us;

- Users often get to the login screen and are able to enter credentials.  The errors begin after that, and they are denied access.

- I had a conversation with an ISP in Mozambique re this.  They said our server was configured for "session-based" access, not "user-based", and thus the credentials/communications would not pass successfully thru the ISP's servers.  (They were unwilling to tweak their system for us.)

- Today an error message forwarded to me from Nigeria said something to the effect: You do not have permission to view this page using the credentials that you suppliied because yuour Web browser is sending a WWW-Authenticate header field that the Web server is not configured to accept.

The Question: I'm open to broad advice about this problem in general, but mainly want to know if there is an IIS config on my end (or other security related steps) that can make for successful access from our field offices?

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.

You are using Integrated Windows Authentication and authentication does not work through a firewall via a proxy, unless used over a PPTP connection.

Integrated Windows authentication is the best authentication scheme in an intranet environment where users have Windows domain accounts, especially when using Kerberos.

You may want to enable Basic authentication in conjunction with NTLM or Kerberos for the sites that are not working. For more information, see Enabling and Configuring Authentication in the IIS Documentation (http://www.microsoft.com/windows2000/en/server/iis/htm/core/iiauths.htm?id=76).

Do you have VPN access to your site? If so, make the sites having problems either SSL or IPsec VPN in and see if they are having the same problem when they connect to your intranet portal.  They won't.

If you comment on how the working and non-working sites are connected to your network and connect to the intranet portal, that may shed more light on the total issue.

For example, if you ran a private frame worldwide, MPLS, or meshed IPSec VPN then you can auth using Integrated Windows Authentication.
ricplaisanceAuthor Commented:
Phil -

Thanks for the reply.  I hadn't responded to this point for I had been circulating your thoughts for comment.  I have learned that our cisco infrastructure will make testing - and maybe setting up - a vpn solution relatively simple, and in a trip to Tanzania shortly I plan to test it from that end.

I am also pondering the move to basic authentication for the near term, until we can get a real network set up.

I'm not familiar with the notion of the "private frame", and so will be looking into that shortly.  Sounds like high overhead.  True?  Our sites often have very weak connectivity, which is part of the problem.

I'd like to keep the question open for just a few more days until I can finish up my reading.

"I'm not familiar with the notion of the "private frame", and so will be looking into that shortly.  Sounds like high overhead.  True?  Our sites often have very weak connectivity, which is part of the problem."

Yes, private frame relay networks are expensive, this is why after 1996 (when IPSec VPNs were ratified and product began shipping) many companies built meshed VPN networks using the Internet to connect each site. You end up paying for 1 Internet connection and IPSec VPNs tied remote facilities to head quarters.

In 2002, some companies started to see the benefits and cost savings for MPLS networks. Swicthing to MPLS is expensive, so many companies stayed with their working meshed IPSec VPN architecture.
Basic authentication will adderss your needs, but password synchronization is another topic.

This is why products like Oblix, ClearTrust, and Netegrity became an umbrella on top of Web-based application authentication.  Vendors like MTech P-Synch offer additional password synchronization functionality.

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
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
OS Security

From novice to tech pro — start learning today.