[thelist] asp.net NTLM authentication fails on postback?

Ken Schaefer Ken at adOpenStatic.com
Wed Jun 8 08:41:27 CDT 2005


: -----Original Message-----
: From: thelist-bounces at lists.evolt.org [mailto:thelist-
: bounces at lists.evolt.org] On Behalf Of Scott Dexter
: Subject: RE: [thelist] asp.net NTLM authentication fails on postback?
: 
: 
: >
: > b) What do you mean "NTLM is turned on"? Do you mean "Integrated
: 
: Integrated Windows Auth is turned on;
:     <authentication mode="Windows" /> in the web.config

This, by itself, doesn't enable any sort of authentication at all. This just
means that the user needs to present valid Window credentials in order to
access the page. The type of authentication mechanism used (NTLM, Kerberos,
Basic, Digest etc) is determined by what is set in the IIS Metabase. You can
enable these various authentication mechanisms via the IIS Manager.

Hence, I am asking what you've actually enabled. Before you said you have
NTLM enabled. In order to only have NTLM enabled, you have to edit the
metabase (e.g. using IIS ADSI Provider, or using the IIS WMI Provider). Most
people generally don't do that. Now you say you have IWA enabled. What
exactly do you have enabled?

Again, to be clear: Integrated Windows Authentication does not automatically
mean NTLM. IWA, by default, encompasses both NTLM *and* Kerberos
authentication. Secondly, setting that mode="" value in web.config by itself
does not enable Integrated Windows Authentication. IWA (or some alternate
HTTP based authentication mechanism, such as Basic, Digest etc) needs to be
enabled via the IIS metabase.
 
: >
: > c) What you say "authentication fails", what do you mean exactly?
: 
: The user is prompted with the login challenge message box, and after
: three tries IIS fails the login, user gets a 403

Is this an IIS 6 box? Can you please post the corresponding log file entries?
That will give us the HTTP substatus codes which help us determine why the
user is being denied access.

If you check out:
www.adopenstatic.com/faq/IISRequestProcessing.aspx
you can see that there's a fair number of reasons why you can get up with a
403

 
: > d) What are the corresponding website logfile entries? Can you post
: > those please?
: 
: don't think I have access to those --will find out, who knows if the
: site is even logging)
: 
: I'm slowly thinking it's an Active Directory issue, as I've witnessed
: someone operate the page successfully.

>From the information presented, I don't think that's a conclusion you can
draw. There seems to be a fair amount of confusion here already about what is
actually enabled and being used. Let's no confuse it by dragging in something
else.


: Trying to convince the AD
: "people" that this is the case is proving to be an uphill battle.
: Gotta love large IT shops :/

I'm certainly not surprised. I've administered reasonably large Active
Directories in the past. If this was the only information presented, I would
be sceptical that this was an AD issue, given that there are plenty of other
pieces of information/AD diag tools that would give a competent AD admin
clues that something was up with AD. Most large shops, in my experience, tend
to have all this stuff automated.

Cheers
Ken

--
IIS Stuff: www.adOpenStatic.com/cs/blogs/ken/


More information about the thelist mailing list