I'm in the process of moving new part of our intranet site from apache/php to asp.net, but one of the requirement is to authenticate users in LDAP. But the real challenge is that IIS doesn't support LDAP and there is no free/working ISAPI extension for this. Of course I can write HttpModule but this requires to disable all IIS authentication methods, and this disables debugging in Visual Studio.
How can I convince other developers to move to this platform wihout debugging. That was one of advantages I use to force the change in our team.

Im starting to hate IIS authentication support.

I wasn't aware of the NTLM authentication performance impact but one possibility would be to use Kerberos Authentication as opposed to NTLM. Generally speaking kerberos authentication is faster and "may" provide some cross platform authentication, although I can't personally speak to how compatible kerberos domain tickets generated from w2k3 AD are with *nix implementations but it might be a possibliity. Another advantage is that it supports authentication delegation which is very usefull for end-end validation in multi-tiered applications(if thats a requirement on your application). I'd be curious on people's experience with kerberos as I don't see it very often.

> Of course I can write HttpModule but this requires to disable all IIS authentication methods, and this disables debugging in Visual Studio.

Ah, right-- because Integrated is required for debugging. That's a tough one.. I'd be interested to hear what you actually end up doing.

> one possibility would be to use Kerberos Authentication as opposed to NTLM

Has anyone done this? I need to research that solution.

Why not compromise? Do the traditional login checks as if you were writing the logic yourself, and just cheat on the login page:

On every page, check for a specific cookie and if it does not exist (or has expired or is otherwise bad), redirect the browser to /ntlmLogin/[originalUrlHere], or save it in the session, whatever.

Pretend that the login page is the traditional sort - it would ask for a username/password/whatever, and if the user is authenticated it would send over the magic cookie and forward the user back to the original page.

So... why can't that login page (and only that login page) support NTLM authentication? Better yet, have a fallback so that if there's an authentication failure it just goes to a traditional username/password page rather than an "access denied" page (or not - your site, your requirements, but this would open up access possibilities for more obscure clients (or faux-clients)).

That way you have the massive NTLM overhead at most once, everything stays at least as secure as it would be in a traditionally secured site, and you've still achieved single-sign-on.

Or am I missing something?

Richard, you're right, that works. Actually, we've got that implemented in my current project, using the Application_AuthenticateRequest handler in Global.asax. Using Global.asax obviates the need for an HttpModule as "seer" suggested above.

One difference between what Richard suggested and what we have is that there is no login page -- the first request to any page in the app will force NTLM authentication. But then the response to that first request will set a FormsAuthentication cookie, which is used for all future requests. Works great in practice, and it's not too hard to code up.

One gotcha with this-- in IIS manager you have to make sure to enable both Windows Integrated Authentication and Anonymous Access (names from my imperfect memory...)

Brian, that's a great tip. We are using a variant of this technique -- eg, do the expensive auth once, and in doing so generate a ticket valid for the duration of the user's website visit.

You could use www.KeepAliveForever.com to keep your site alive. It is a free resource that seems to work really well.

I'll have to check out whether this solution can work for me as i seem to be having a similar problem. Thanks for the info!

Good article; for the sake of completeness, here's a Technical Artical of an implementation (with an installer that will install to the running website on IIS) that has a fallback mechanism where you can use a secondary authentication mechanism (Forms authentication) if NTLM is not available from the UA (because of firewalls, no domain account)

Mixing Forms and Windows Security in ASP.NET
https://msdn2.microsoft.com/en-us/library/ms972958.aspx

Hello!

I have a related issue you huys may know have to resolve.

There's a website using NTLM auth that we are trying to login to.

On a standard internet connection this is no problem. We put in the prompted for the username and password, we put them in and they are accepted.

If we try and do the same in the office, our windows/NTLM domain, it sometimes gives us access but most of the time tells us that access is denied!

I believe that this is due to the external webserver thinking that we are authenticating as mydomain\username instead of extwebsite\username.

Any thoughts whether this is correct?

Is there any work around for this?

At the moment we're using a proxy server but there has to be someway for the external webserver to just see us as authenticating as website\username. This is what it must be doing when at home on the internet(?).

Any advice would be very much appreciated!

Thanks!

Asher.

Asher:

Your issue is with IE security zones; the site is being detected as in the intranet zone, and so it automatically sends your current credentials (and thus, no prompt is shown).

You can fix that by adding the server to your Internet zone, or turning off the security setting for automatically sending credentials to intranet servers.